Software serial higher bitrates fail

[matthijskooijman]

When using the software serial support, using:

baud(2, 19200)
print #2, "abcd"

My USB TTL converter receives garbage. Running at 9600 works, but at higher speeds (I also tried 14400) it fails. When I raise the bitrate a bit (on the bitlash end), things start to work. Setting 20100 in bitlash and 19200 in my TTL adapter seems to work reliably.

This seems to suggest that the delay employed by the softwareserial is slightly too high (since a higher baudrate causes a lower delay). I guess the bittime calculation should account for more than 50 clockcycles overhead? 50 cycles of overhead seems a lot already, but I think that it's mainly the digitalWrite that takes a long time...

   bittime[pin] = (1000000/baud) - clockCyclesToMicroseconds(50); 

Note that I'm running on GCC 4.8, which might also cause differences in overhead...

[billroy]

Thanks for your observation. I wouldn’t be at all surprised if the time it takes for digitalWrite has changed since I timed those out on my scope.

-br

On Jan 29, 2014, at 9:09 AM, Matthijs Kooijman notifications@github.com wrote:

When using the software serial support, using:

baud(2, 19200) print #2, "abcd" My USB TTL converter receives garbage. Running at 9600 works, but at higher speeds (I also tried 14400) it fails. When I raise the bitrate a bit (on the bitlash end), things start to work. Setting 20100 in bitlash and 19200 in my TTL adapter seems to work reliably.

This seems to suggest that the delay employed by the softwareserial is slightly too high (since a higher baudrate causes a lower delay). I guess the bittime calculation should account for more than 50 clockcycles overhead? 50 cycles of overhead seems a lot already, but I think that it's mainly the digitalWrite that takes a long time...

bittime[pin] = (1000000/baud) - clockCyclesToMicroseconds(50); Note that I'm running on GCC 4.8, which might also cause differences in overhead...

— Reply to this email directly or view it on GitHub.

[matthijskooijman]

Yeah, likely. It's hard to do these things right unless you do handcoded ASM, but then you again lose the Arduino provided abstractions. Not a big deal though, I just wanted to report this now to prevent thinking later that the changes I'm working on broke this ;-p

[matthijskooijman]

Here's my work so far: https://github.com/Pinoccio/library-bitlash/commits/printstream

In addition to using the Print and Stream classes, also some (seemingly) old stuff is removed and I touched some other things I came across. The second to last commit (https://github.com/Pinoccio/library-bitlash/commit/e91dd2adc02ba13ae2e4a45fbf45157caabca95b) is the most important one.

Right now, there is still a considerable size increase, with the bitlashdemo example on the Mega2560, the program size goes from 17,922 to 18,592 and the memory size from 5,839 to 5,870. I'm still looking as to where this increase comes from exactly to see if some of it might be avoided.

I have tested this on Arduino 1.5.5+ (git master), haven't tried 1.0.x yet (but I didn't want to keep you waiting for that :-D).

[billroy]

I took a quick look. You’re certainly making fast work.

FYI, the Teensy and Avropendous defines will need to stay.

-br

On Jan 29, 2014, at 10:55 AM, Matthijs Kooijman notifications@github.com wrote:

Here's my work so far: https://github.com/Pinoccio/library-bitlash/commits/printstream

In addition to using the Print and Stream classes, also some (seemingly) old stuff is removed and I touched some other things I came across. The second to last commit (Pinoccio@e91dd2a) is the most important one.

Right now, there is still a considerable size increase, with the bitlashdemo example on the Mega2560, the program size goes from 17,922 to 18,592 and the memory size from 5,839 to 5,870. I'm still looking as to where this increase comes from exactly to see if some of it might be avoided.

I have tested this on Arduino 1.5.5+ (git master), haven't tried 1.0.x yet (but I didn't want to keep you waiting for that :-D).

— Reply to this email directly or view it on GitHub.

[matthijskooijman]

W00ps, these comments ended up in the wrong issue. I'll copy them over to the right one, feel free to delete them from here afterwards.