SDCC ignorance
Posted by Adrian Bowyer
|
Re: SDCC ignorance July 02, 2007 05:01PM |
Adrian Bowyer wrote:
> I've got round the RAM limitation by the hacky (but kinda neat)
> strategy of putting my ring buffer in the (at the moment unused)
> EEPROM. This is slower than RAM, of course, but that doesn't matter
> for variables that are not being accessed in a tight loop. Also SDCC
> doesn't touch the EEPROM, so you have complete control over what you
> put in there and what you do with it. I just hope it can survive a
> lot of read-write cycles...
Gosh, that's a little scary. The EEPROM isn't really designed for that
kind of use
It is rated at 1,000,000 writes, so it might be okay. But it would
probably limit the life of a RepRap to printing perhaps a thousand parts
after which it may start to fail in weird and wonderful ways.
Is there a little space in one of the other banks? The biggest benefit
from the ring buffer is probably a buffer of size 2 (or an additional
buffer of size 1) and then diminishing returns. Presumably one entry in
the buffer is 5 bytes (does that sound right?). So just finding 5
additional bytes doesn't seem like too tall an order. It would be worth
looking at the map file to to see the actual register allocation. It
should provide some clues. If there's really nothing left, we can
probably adjust some other memory usage to free up that much. How big a
ring buffer are you hoping for?
>
> What I've done so far is to take these lines from
> [...]
> And so on.
>
> Can you see any reason why that shouldn't work? In particular, I'm
> not sure if it will handle the case when the first line has big delatX
> and small deltaY, and the second has the opposite, because in the
> first case the X controller generates the syncs, and in the second
> case it's the Y (if I understand it correctly), and I'm not sure if
> I'm doing enough to handle that transition.
Yeah, I think that's going to run into some problems for exactly that
reason. That's what I was talking about when I mentioned syncs too.
The PICs can either be in master or slave mode, where the master
generates the DDA pulse and the slave just moves in the right direction
when it gets a pulse. The master is always the one with the longest
delta. So if you start another line with the situation reversed you
also need to switch roles and the other one becomes the master.
My suggestion that I was going to run by the dev list first was to use
the second sync line to control the sync between lines. So SYNCA is
used to sync the individual steps within a line and SYNCB is used to
sync the lines themselves.
Each PIC would store in their ring buffer either the (speed, seek
position, deltay) *or* the fact they should be slave, along with the
sync mode which could perhaps be (0, seek_mode, 0) or something like
that in the same ring buffer for the sake of conserving memory. When a
master finishes its DDA process, it would strobe the SYNCB line and then
process the next action in the ring buffer, which would either cause it
to start a new DDA or become a slave. At the same time, the slave
seeing the SYNCB does the same thing, potentially becoming the master
and driving the next DDA.
The reason I didn't jump straight into doing this is [partly the fact I
didn't get around to it yet and] that I didn't want to use such a
precious resource as SYNCB without checking what people thought of it.
There's no other sync lines left after that, so we need to use it wisely.
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]
> I've got round the RAM limitation by the hacky (but kinda neat)
> strategy of putting my ring buffer in the (at the moment unused)
> EEPROM. This is slower than RAM, of course, but that doesn't matter
> for variables that are not being accessed in a tight loop. Also SDCC
> doesn't touch the EEPROM, so you have complete control over what you
> put in there and what you do with it. I just hope it can survive a
> lot of read-write cycles...
Gosh, that's a little scary. The EEPROM isn't really designed for that
kind of use
It is rated at 1,000,000 writes, so it might be okay. But it would
probably limit the life of a RepRap to printing perhaps a thousand parts
after which it may start to fail in weird and wonderful ways.
Is there a little space in one of the other banks? The biggest benefit
from the ring buffer is probably a buffer of size 2 (or an additional
buffer of size 1) and then diminishing returns. Presumably one entry in
the buffer is 5 bytes (does that sound right?). So just finding 5
additional bytes doesn't seem like too tall an order. It would be worth
looking at the map file to to see the actual register allocation. It
should provide some clues. If there's really nothing left, we can
probably adjust some other memory usage to free up that much. How big a
ring buffer are you hoping for?
>
> What I've done so far is to take these lines from
> [...]
> And so on.
>
> Can you see any reason why that shouldn't work? In particular, I'm
> not sure if it will handle the case when the first line has big delatX
> and small deltaY, and the second has the opposite, because in the
> first case the X controller generates the syncs, and in the second
> case it's the Y (if I understand it correctly), and I'm not sure if
> I'm doing enough to handle that transition.
Yeah, I think that's going to run into some problems for exactly that
reason. That's what I was talking about when I mentioned syncs too.
The PICs can either be in master or slave mode, where the master
generates the DDA pulse and the slave just moves in the right direction
when it gets a pulse. The master is always the one with the longest
delta. So if you start another line with the situation reversed you
also need to switch roles and the other one becomes the master.
My suggestion that I was going to run by the dev list first was to use
the second sync line to control the sync between lines. So SYNCA is
used to sync the individual steps within a line and SYNCB is used to
sync the lines themselves.
Each PIC would store in their ring buffer either the (speed, seek
position, deltay) *or* the fact they should be slave, along with the
sync mode which could perhaps be (0, seek_mode, 0) or something like
that in the same ring buffer for the sake of conserving memory. When a
master finishes its DDA process, it would strobe the SYNCB line and then
process the next action in the ring buffer, which would either cause it
to start a new DDA or become a slave. At the same time, the slave
seeing the SYNCB does the same thing, potentially becoming the master
and driving the next DDA.
The reason I didn't jump straight into doing this is [partly the fact I
didn't get around to it yet and] that I didn't want to use such a
precious resource as SYNCB without checking what people thought of it.
There's no other sync lines left after that, so we need to use it wisely.
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]
|
Re: SDCC ignorance July 03, 2007 07:57AM |
Simon McAuliffe wrote:
> Adrian Bowyer wrote:
>> I've got round the RAM limitation by the hacky (but kinda neat)
>> strategy of putting my ring buffer in the (at the moment unused)
>> EEPROM. This is slower than RAM, of course, but that doesn't matter
>...
> Gosh, that's a little scary. The EEPROM isn't really designed for that
> kind of use
>
> It is rated at 1,000,000 writes, so it might be okay. But it would
> probably limit the life of a RepRap to printing perhaps a thousand parts
> after which it may start to fail in weird and wonderful ways.
Yes - I thought that might be a problem, and Jonathan was rightly, if
politely, aghast at what I'd done when all I really needed to do was
reach for a PIC16F648a and use those extra 25 bytes...
I know that you were unhappy about the generated code bloat of later
SDCC versions than the one we're using. But we're not short of program
space. What do people feel about switching to the PIC16F648a and
keeping up-to-date with SDCC?
> The PICs can either be in master or slave mode, where the master
> generates the DDA pulse and the slave just moves in the right direction
> when it gets a pulse. The master is always the one with the longest
> delta. So if you start another line with the situation reversed you
> also need to switch roles and the other one becomes the master.
>
> My suggestion that I was going to run by the dev list first was to use
> the second sync line to control the sync between lines. So SYNCA is
> used to sync the individual steps within a line and SYNCB is used to
> sync the lines themselves.
>
> Each PIC would store in their ring buffer either the (speed, seek
> position, deltay) *or* the fact they should be slave, along with the
> sync mode which could perhaps be (0, seek_mode, 0) or something like
> that in the same ring buffer for the sake of conserving memory. When a
> master finishes its DDA process, it would strobe the SYNCB line and then
> process the next action in the ring buffer, which would either cause it
> to start a new DDA or become a slave. At the same time, the slave
> seeing the SYNCB does the same thing, potentially becoming the master
> and driving the next DDA.
>
> The reason I didn't jump straight into doing this is [partly the fact I
> didn't get around to it yet and] that I didn't want to use such a
> precious resource as SYNCB without checking what people thought of it.
> There's no other sync lines left after that, so we need to use it wisely.
I would like to be able to drive X, Y, and Z with a 3D DDA. I know we
don't do that at the moment, and the machine doesn't need it yet. But
it's so obviously elegant and symmetrical that we ought not to abandon
the potential to do it lightly.
But Ed is finding that the single biggest quality issue we have with
Darwin is the pause between the end of one XY line and the start of the
next, and I guess quality of what we need takes priority over symmetry
and elegance for their own sake.
--
Best wishes
Adrian
Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]
> Adrian Bowyer wrote:
>> I've got round the RAM limitation by the hacky (but kinda neat)
>> strategy of putting my ring buffer in the (at the moment unused)
>> EEPROM. This is slower than RAM, of course, but that doesn't matter
>...
> Gosh, that's a little scary. The EEPROM isn't really designed for that
> kind of use
>
> It is rated at 1,000,000 writes, so it might be okay. But it would
> probably limit the life of a RepRap to printing perhaps a thousand parts
> after which it may start to fail in weird and wonderful ways.
Yes - I thought that might be a problem, and Jonathan was rightly, if
politely, aghast at what I'd done when all I really needed to do was
reach for a PIC16F648a and use those extra 25 bytes...
I know that you were unhappy about the generated code bloat of later
SDCC versions than the one we're using. But we're not short of program
space. What do people feel about switching to the PIC16F648a and
keeping up-to-date with SDCC?
> The PICs can either be in master or slave mode, where the master
> generates the DDA pulse and the slave just moves in the right direction
> when it gets a pulse. The master is always the one with the longest
> delta. So if you start another line with the situation reversed you
> also need to switch roles and the other one becomes the master.
>
> My suggestion that I was going to run by the dev list first was to use
> the second sync line to control the sync between lines. So SYNCA is
> used to sync the individual steps within a line and SYNCB is used to
> sync the lines themselves.
>
> Each PIC would store in their ring buffer either the (speed, seek
> position, deltay) *or* the fact they should be slave, along with the
> sync mode which could perhaps be (0, seek_mode, 0) or something like
> that in the same ring buffer for the sake of conserving memory. When a
> master finishes its DDA process, it would strobe the SYNCB line and then
> process the next action in the ring buffer, which would either cause it
> to start a new DDA or become a slave. At the same time, the slave
> seeing the SYNCB does the same thing, potentially becoming the master
> and driving the next DDA.
>
> The reason I didn't jump straight into doing this is [partly the fact I
> didn't get around to it yet and] that I didn't want to use such a
> precious resource as SYNCB without checking what people thought of it.
> There's no other sync lines left after that, so we need to use it wisely.
I would like to be able to drive X, Y, and Z with a 3D DDA. I know we
don't do that at the moment, and the machine doesn't need it yet. But
it's so obviously elegant and symmetrical that we ought not to abandon
the potential to do it lightly.
But Ed is finding that the single biggest quality issue we have with
Darwin is the pause between the end of one XY line and the start of the
next, and I guess quality of what we need takes priority over symmetry
and elegance for their own sake.
--
Best wishes
Adrian
Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]
Sorry, only registered users may post in this forum.