-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial write code slow, blocks on IO, does not use FIFO buffer in SAMD21g #2
Comments
the IndustruinoSAMx core seems to use a newer version of the ArduinoCore-samd so i assume you could use this version of SERCOM.cpp https://github.com/Industruino/IndustruinoSAMx/blob/industruino/cores/industruino/SERCOM.cpp |
Hi @tomtobback sorry to hijack this topic, but is there anything that prevents releasing a new version of SAMD21G board definitions, based on the Industruino/IndustruinoSAMx repo? |
Thanks Tom. That newer code looks FAR better.. going to test it out on my next build. Will let you know how it goes. |
Update. install instructions for the SAMx core are broken. They install this library instead. |
many thanks @ta2edchimp for your feedback, i agree we should work on a release of 1.0.2 SAMD board definitions based on the SAMx repo |
Hi Tom, Thanks. The instructions listed on the SAMX page are flawed. for the SAM21D, they install the 1.0.1 version not the SAMx one. I'm not concerned with the SAML since I'm not using one. I've tried manually installing it, but that's led to even more trouble and bugs in the Industruino codebase(SAMD and SAMx alike). also I'm trying to get this to work in PlatformIO on VSCode(which lacks a board def) I've tried to make one, but really its a tad beyond me - platformio/platform-atmelsam#27 |
Hi @cheetor5923 please try the following:
Using these steps, I was instantaneously able to successfully compile and run my sketches. As a side note: I also tried to get this to work in PlatformIO a whole while ago and while it worked good for the old 1286 board, I had (wrt to the linked pio issue) exactly the same problem with the modified bossac tool. |
thanks @ta2edchimp; i can't confirm the bossac details for now but the new version for SAMD is in the pipeline for September |
Hi all. have managed to get the SAMx brance into platformio without any problems (except for uploading over usb) compiling, uploading and debugging work perfectly (over Atmel ICE). I wrote a board def .json for the Industruino. |
Fix one bug, find another.... opening the USB VCP causes I2C to break.. lovley |
@tomtobback Arduino just told me that Industruino SAMD version 1.0.2 is available. Is that the before-mentioned new version? |
Thread on Arduino Forums - https://forum.arduino.cc/index.php?topic=630048.0
Hi All.
I have an industrial robot which has a control system based on FreeRTOS. One task has the duty
of talking Modbus RTU over one of the USARTs to an IO expander at a rather slow rate of 57600..
the problem is the way the board code handles writes to the USART.
SERCOM.cpp from https://github.com/Industruino/IndustruinoSAMD/blob/master/cores/industruino/SERCOM.cpp
This effectively blocks the transmitting task until the TX is complete, Makes no use of the SAMD21G's 16 byte FIFO buffer or the stream buffer for Serial.write() (at least I think it does). I end up having to wrap all my Serial.write() in a vTaskSuspendScheduler() to ensure the timing doesn't get screwed up. This wastes a massive load of processor cycles I could be using for other tasks. I don't like having some of the more critical threads blocking for sometimes more than 50ms.
Ideally I'd like to make use of the FIFO buffer offered in hardware, use an ISR to handle filling the hardware FIFO from a larger software one, meaning I don't need to wrap my modbus writes with a
scheduler disable, as the ISR can easily keep the timing good on a 48MHz RISC core.
IIRC Serial.write() is supposed to be non-blocking?...
What do you think? some of this core hardware level stuff is a bit beyond me. It strikes me that I could
copy/paste some code from the Arduino Due implementation since the hardware is very similar?. I've had a look at the Due UART code and it looks quite different.
The text was updated successfully, but these errors were encountered: