hannobraun
commented
8 years ago Hi, thanks for opening this issue.
I managed to get things working on Mac OS X (I hope to provide a PR with added notes for the platform in the future).
This is great. Such a pull request would be very welcome!
I am having trouble with the upload program, had to increase the serial port timeout and then still had an issue with a failing assertion in eefc.rs, I ended up using BOSSA to upload the .bin which is fine for now.
The upload program isn't of the highest quality, so I'm not surprised it's failing with some assertion. That said, it's been exceptionally reliable for my own use, as long as I'm using it for the exact use case I wrote it for.
Even though BOSSA is working for you, I have some suggestions, in case you want to try again:
- Are you using an Arduino Due? The program is written specifically for the SAM3X8E microcontroller, and anything else likely won't work.
- My Due is produced by the arduino.org people (as opposed to arduino.cc), although I don't think this makes a difference.
- Are you using the native USB port for the upload? That's the one closer to the reset button. The uploader is not working with the programming port (the one closer to the power jack), and I have made no effort to get that working so far.
I'd also appreciate it, if you could post the exact assertion output. Although I suspect that if none of my suggestions help, I won't be able to do anything to fix it.
I plan to clean up the uploader at some point (add better error messages), and also add support for more microcontrollers. It will be a while before I'll get to it though.
However the reason I'm opening this issue is b/c when I run sermon I am getting garbled output. I altered the blink program.rs to print * instead of the long output it was producing. On the receiving end however I get 'Z', I looked at an ASCII chart and see 'Z' - * = 48. So I changed the print to '+' (comes right after '*' in ASCII) and sure enough on the receiving end I now see '[' (48 after '+'). Do you have any idea why this would be?
I have an idea: Decimal 48 is the ASCII value for '0' (zero). If you want to convert the number 0 into the ASCII character '0', you can do so by adding 48. The same goes for other digits, of course. So while it's weird that the offset is there, the offset being 48 is much less weird than any other offset would be :smiley:
I see three possible causes:
- You made some changes to the code that would explain this.
- Your hardware or software is somehow different than mine, and this is somehow causing this.
- I've made some change that introduced this bug and didn't test the serial output properly since then.
While I wouldn't rule out 3 as a likely cause, I suspect it's 2. Specifically, I'm guessing that serial communication on OS X works differently than it does on Linux, but I don't know. I suggest you download a more proven application for serial communication and see what happens with that.
I'll test it again with my setup to try and rule out cause number 3. Probably on Monday.
nyx
I managed to get things working on Mac OS X (I hope to provide a PR with added notes for the platform in the future). I am having trouble with the upload program, had to increase the serial port timeout and then still had an issue with a failing assertion in
eefc.rs, I ended up usingBOSSAto upload the.binwhich is fine for now. However the reason I'm opening this issue is b/c when I runsermonI am getting garbled output. I altered theblinkprogram.rsto print * instead of the long output it was producing. On the receiving end however I get 'Z', I looked at anASCIIchart and see 'Z' - * = 48. So I changed the print to '+' (comes right after '*' inASCII) and sure enough on the receiving end I now see '[' (48 after '+'). Do you have any idea why this would be?