Firmware communication protocol : Streaming vs Packets

reinoud Wrote:
-------------------------------------------------------
> As for the Arduino Serial implementation, it has a
> major flaw. The main problem is that receiving
> sure is nicely done in interrupt and buffers etc,
> but _sending_ is done in a busy waiting loop! no
> buffering, no interrupt or whatsoever. If this
> could be fixed, then it would be great.

Yep. When I did my serial testing, I believe this was the reason I dropped bytes. I've already looked at Triffid_Hunters implementation, and he did it right, so that's the serial code I'll be using, rather than arduino standard.

He has recently made some great improvements, too (2^n ring buffers, etc.)

Yeah i just noticed! hmm.. this means patching up my serial.c thanks for the tip and thanks to Triffid for the serial tx buffer implementation!

you're welcome guys! make your projects awesome with it

quick heads up, adrian posted the latest gcode reference up on the wiki, and it specifies optional line numbers and checksums- so now we can consider each gcode to be a packet since it can now have a unique identifier and a checksum!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------

> quick heads up, adrian posted the latest gcode
> reference up on the wiki, and it specifies
> optional line numbers and checksums- so now we can
> consider each gcode to be a packet since it can
> now have a unique identifier and a checksum!

Yep. It's great he's done this, though there still can exist issues; as the checksum and line number is optional, it can be possible to lose the 'N' code or the '*' code, and then attempt to read the line as one that (optionally) did not include the line number info. The way around this would be to turn on a mode that would force them to be required. Also, on the discussion page, I've noted that including a length field and a stronger checksum (CRC) would make the chance of a false positive 0% (or at least, close enough that no one need concern themselves with the probability.) A single bit error on the 'N' code and '*' code can currently cause the entire line to be considered one of those lines where the fields were 'optionally left off'.

yep, so maybe a firmware option to require line numbers and checksums, maybe with M-codes to turn it on and off?

also, instead of "OK", maybe firmware should respond with line number, calculated checksum and OK/NOK, so host knows to resend or move on

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I have been dealing with delays of the arduino controller that pauses my reprap. The delays are from the processor halting everything but sending serial commands, then resuming where it left off. when sending serial data print does not utilize the internal 1 byte buffer (actually 2 bytes but 1 byte sending and one byte buffer), I am trying to implement in my code a serial. Write(str) and send one character over at a time, and loop and do other tasks until that amount of time has past for the buffer to empty then send another byte of data. The idea is to use the 1 byte tx buffer, and free up resources, so interrupts and other functions during xyz moves can go on without stopping. one way you can verify if the serial.print buffer is causing issues, is reduce the buffer in the config to 2 and adjust code appropriately in the fiveD_gcode_interpreter

Remove or remark the lines:

static cartesian_dda cdda2;
static cartesian_dda cdda3;


cdda[0] = &cdda2;
cdda[1] = &cdda3;

and change config buffer=2 instead of 4.

also change serial.print in process_gode to serial.println("ok\nok")

this causes 1 command to be processed, and the second command to be sent while 1st one is processing, but since the buffers are full, the serial.print is only sent right after the command is processed, and before the next move is processed or at full speed. meaning the ack statement that stops all the arduino functions only happens at near stop speed, when it will not cause a stall or missing steps.

I am implementing changes to incorporate a serial buffer for tx that allows hardware buffer and sends 1 byte at a time, at the appropriate rate from baud so that a small fraction of the time is used, and the arduino will not pause anymore...

also no work needs to be done to floating point operations if you can not be so precise about feedrate. there is a calculation in the code in cartesian_dda that states:
return round((distance*60000000.0) /(feedrate*(float)total_steps)

60 or any multiple of 60 to the power of ten does not divide well into many numbers. it requires extensive float calculations and randomly is slower to calculate these extra places of digits for different feedrates. for example 60/9 = 6.666666666666667

however changing the calculation to a more float friendly value of

return round((distance*59760000.0) /(feedrate*(float)total_steps)

provides numbers that are faster to process 5976/9 =664, for example

5976 is a number that divides into 3 and comes out with few digits past the decimal. The fewer points past the decimal the faster a float processes.

james villeneuve, sounds like you're running into two of the issues that prompted me to write my own firmware based on the reprap firmware. See link in my sig for details, including all-integer calculation and an interrupt-driven serial transmit buffer.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware