constraints in the serial communication

due to the problem, that simons new networking code needs to much memory so that it cannot be implemented in the current PIC's for Darwin, I decided to simplify the current code for the serial-communication to get a stable solution for Darwin.

I have changed the firmware during the weekend and it looks like I have now a stable version of the serial communication without the strange effects. But until now I have only tested the extruder-firmware. the stepmotor I will change next weekend.

To do so I had to make some assumptions/constraints explicit, which also silently exists inside the current communication between the host and the devices. I hope I have understand everything correct and the following constraints will hold with the current version of the host-software:
1. there exists two types of command-messages:
a) one type which do not expect an answer-message (e.g. for setting values in the devices)
b) one type which expects an answer-message (e.g. for getting information of the device)

2. there exists only communication between the host-software and the devices:
between the devices there exist no communication (only forwarding of messages).

3. the host-software plays the master, the devices are the slaves.
this means only the master sends a command-message, the device only respond (if necessary) with an answer-message.
the host-software waits for the acknowledge or answer-message with a timeout. if no message is received within the given timeout the message is resend.

for the devices it makes no sense to request an acknowledge, because in the current version the device is not waiting for an acknowledge.
thats not a problem, because if the master gets no answer he will have to ask again (is that also true with the CMD_NOTIFY code for the stepmotor?).

4. there should only exist one command-message at the same time in the ring! (is that true?, no parallel threads in the host-software are waiting for answers, or?)

5. interrupt-code in the firmware should not call sendMessage(), sendReply(), sendDataByte(), endMessage(), it could be mixed up with a sending message in the main-routine.
instead of sending the message, the interrupt-code should set a flag and the message should be send in the main-loop or somewhere else outside the interrupt. (maybe I find a better solution, but this will work with my current version).

6. if an error in the serial-communication occur I will send 16 bytes of zero to reset any buffer in the ring.

do someone see any problem with this changes?

andreas

I don't know enough to judge the changes, but I've got a somewhat related question: do you know how much memory we were using before and after your change? When I was doing some firmware tweaks a while back, I looked at the map file and it seemed like nothing was allocated in bank 1 (0xa0 to 0xef) at all, which should have left 80 bytes of room to grow. I could have been mis-reading the map file, but it just doesn't seem like there were enough variables scattered around to account for all 224 bytes of memory otherwise. What am I missing?

This is really Simon's area, not mine, but I think that andreas's list is correct.

If at all possible we should avoid making the system such that the PICs can't instigate a communication; that would be a serious constraint on the future.

The 16F648A code in the branch autoconf-firmware very nearly works (there's a bug in the stepper code that Jonathan and I are working on; the extruder is OK, I think). The 16F648A gives us 256 bytes of RAM as opposed to 224.

I'd like to reserve a bunch of those extra bytes (18?) for an input buffer to allow me to buffer up movements in the PICs; we have a problem with pauses in the movement of the machine between plotting line segments.

[Over the weekend I committed revisions to the extruder code in the trunk and in the branch autoconf-firmware that greatly improve the temperature readings.]

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

I think you are right (I have very less experience in assembler-programming), nothing is allocated in bank1.

for my changes I need 2 bytes of data-memory more. one is for an error-variable and the other is a register-variable. one byte could be saved, because the variabel nakCount is not used.

from the programm-memory I need 70 addresses more.

I will try to activate the unused bank1.

hi adrian,

it would be possible to implement that the devices can instigate a communication, if we can synchronise messages, but I think we need an extra buffer for this and we have to handle the acknowledge of messages and retry sending on the device side. I think this should be done with the new code from simon, maybe with a new pic, which is also in discussion for the next release.

andreas

I saw your changes for the temp-measurement, after my tests I will give you my feedback in the thread "Extruder _code_update?".

andreas Wrote:
> I will try to activate the unused bank1.

Sounds good. I was going to try doing that, but I didn't understand what all the 'banksel' fragments in the code were doing. I assume it's intended to work around some bugs in SDCC, maybe they're fixed in the current release? Strange that SDCC doesn't have any problem with using bank 2 though...

hi emf,

sdcc is also using bank1 if you add further variables, but then the perl-skript checkmap is complaining. I don't know if this is realy a problem. also with the 'banksel' fragments, I don't know if they are still necessary. I have some removed in the serial-code and it didn't change the behavior (from the assembler code they didn't look necessary).

andreas

That sounds promising. I started to mess around with the memory bank stuff a while back, but I gave up because I didn't have enough hardware built to really test any changes I made. I'll have to give it another try sometime.

it seems that sdcc in the version from 2005 can not use variables in bank1
it is using banksel for variables in bank0 and indirect adressing for the buffers in bank2.
and also the checkmap is necessary because it gives you warnings if static variables of the same source-files are in different banks.
it does not warn if an extern variable is used in bank1!
I had the problem, that an extern variable has been in bank1 and then the firmware didn't work anymore. it costs me several hours to find the reason.

but maybe we can use bank1 with assembler-code.

Ah, I had wondered why the arrays got thrown in bank 2. That makes perfect sense. I guess this means that (until we work around the problem with bank 1) stepping up to the PIC16F648 will allow us to create more/bigger arrays, but we're stuck with the same amount of regular variables.

I don't see why we couldn't use bank1 in assembler. It looks like the interrupt handler jumps to bank 0 on entry and restores the previous bank on exit.

Have you checked to see if the current SDCC has fixed any of this?

I didn't find out how sdcc distributes the variables do the different banks. if we find this out, we can place variables in bank1 and use BANKSEL statements before and after using them.

And yes, I am afraid the PIC16F648 doesn't help us more, but maybe the others have better results.

Do free more ram, we can also reduce the space in the arrays buffer and sendPacket to 8bytes instead of 16, because until now we don't have commands with a payload larger than 3 or 4 bytes (I have used commands with a payload of 7bytes do give me debugging information).

I have tried the current sdcc two months ago, it compiled but didn't link because of to less memory (if I remember right), but I don't know if to less ram or program-memory.

andreas Wrote:
-------------------------------------------------------
> I didn't find out how sdcc distributes the
> variables do the different banks.

I don't know if there's a way to assign them either. I think it delegates most of the job to the assembler/linker. Just from what I've seen recently, it looks like the linker fills up memory using variables from the libraries first, followed by the object files listed on the command line. It seems to fill up bank 2 first, then it fills bank 0 and then bank 1. It allocates the stack and other working variables in the shared region from 0x70-0x7f.

After seeing this, it might be pure coincidence that the arrays got placed in bank 2 -- They're in serial.lib, so they got allocated first. Whoever wrote this initially must have taken advantage of that.

> I have tried the current sdcc two months ago, it
> compiled but didn't link because of to less memory
> (if I remember right), but I don't know if to less
> ram or program-memory.

I just tried out the lastest SDCC snapshot and it seems to have improved. I created a single source file with enough byte-sized variables to span all the banks, then did a few assignments between variables in separate banks. The 2005 SDCC didn't generate any BANKSELs, so the code obviously wouldn't work. The latest snapshot generated a BANKSEL every time a new variable was accessed (including when both variables were in the same bank). This should give us access to all the memory, but it's going to introduce a significant amount of bloat since most of these BANKSELs will be unnecessary.

I'll give it a try on the real firmware tonight and see if it compiles.