Adds port for Arduino stm32 core.

[balazsracz]

Creates a new port for the library to run on the stm32duino Arduino core. This is the "default" core available in the Arduino boards manager when the user searches for "stm32".
The port was built and tested on an STM32F303RE nucleo dev board. It uses the same resource layout as the previous stm32 port, i.e., input on PB14 and using the TMR2 timer resource. The input pin can be changed in ln_config.h (at compile time), but this was not tested. An arbitrary TX pin is supported (setting at run time).
Polarity selection of input and output is supported (at compile time).

[kiwi64ajs]

Hi Balazs, I’m wondering how you got on getting your node to work. Did you make it in time? Also, a few questions about the PR: 1) I’m a bit confused about what support EEPROM Storage your port may or may not provide. It looks like (from comments in the code) you’ve not provided any support for EEPROM or emulated EEPROM in FLASH. If this is true, using some library features like LNSV2 will not be possible. Is this correct? If yes, do you know if there is an EEPROM library-compatible FLASH-backed emulation library for the STM32 like there is for the ESP32? 2) Have you been able to test the other supported platforms to ensure we’ve not broken anything in adding support for the STM32F3? Regards Alex

…

On 23 May 2024, at 1:36 AM, Balazs Racz ***@***.***> wrote: Creates a new port for the library to run on the stm32duino Arduino core. This is the "default" core available in the Arduino boards manager when the user searches for "stm32". The port was built and tested on an STM32F303RE nucleo dev board. It uses the same resource layout as the previous stm32 port, i.e., input on PB14 and using the TMR2 timer resource. The input pin can be changed in ln_config.h (at compile time), but this was not tested. An arbitrary TX pin is supported (setting at run time). Polarity selection of input and output is supported (at compile time). You can view, comment on, or merge this pull request online at: #45 Commit Summary cd74721 <cd74721> Ports the library to the stm32duino arduino core. cc63bd6 <cc63bd6> Fixes timer overflow computations. a9ec2ff <a9ec2ff> Fix bug in loconet send routine. 1d0a63f <1d0a63f> Clean up comments. ef2f2fa <ef2f2fa> Update readme with new port. c2dd0ae <c2dd0ae> Delete unneeded defines. File Changes (6 files <https://github.com/mrrwa/LocoNet/pull/45/files>) M LocoNet.cpp <https://github.com/mrrwa/LocoNet/pull/45/files#diff-079e85beb4a00e07b41a8e68b26978092e10983db1b85822cd905d4076988cba> (12) M LocoNet.h <https://github.com/mrrwa/LocoNet/pull/45/files#diff-34a9bc6fbca74a7382edfd9362bd298a54485414c425d7448b515dac179d75d3> (4) M README.md <https://github.com/mrrwa/LocoNet/pull/45/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5> (2) M utility/ln_config.h <https://github.com/mrrwa/LocoNet/pull/45/files#diff-6866138c1825c5c1b0bdc36ce482d508b723549490072a8aea0802a111855b69> (24) M utility/ln_sw_uart.cpp <https://github.com/mrrwa/LocoNet/pull/45/files#diff-3673c6a4048bd6e6aeaad706fc1e7011e950479b449807068884dbd85230646f> (86) M utility/ln_sw_uart.h <https://github.com/mrrwa/LocoNet/pull/45/files#diff-e9763344d3972f150d3b414c0d0d9645011e36798a2f4e0b1db09689cb6f0a98> (26) Patch Links: https://github.com/mrrwa/LocoNet/pull/45.patch https://github.com/mrrwa/LocoNet/pull/45.diff — Reply to this email directly, view it on GitHub <#45>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5Y53NJCGU2F33KCJYHCFTZDSNNJAVCNFSM6AAAAABIDVPAOSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTANJWGMYDEMI>. You are receiving this because you are subscribed to this thread.

[balazsracz]

Hi Alex, Yes, I made it in time. Just. The device worked well during the entire weekend, and people had fun. I have observed no issues relating to stability or the loconet library in any form. I ended up not porting the application code that I pointed you to, but rather just writing my own code. The only issue I found was that the uhlenbrock message type doesn't work at all on any platform that's not an 8-bit microcontroller. There is an extra alignment byte added on a 32-bit compiler that just makes the entire struct not work. I had to write my own uhlenbrock message implementation. Re. EEPROM. The STM32 Arduino ecosystem does have an EEPROM class, but it has a really poor implementation that basically wears out flash very quickly. The STM32F1 has the same situation. I am a little unclear why the APIs around SV's and LNCV's are dependent on the EEPROM class (in my opinion these should be just callbacks), but since this was not important for my application, I just copied whatever the STM32F1 had. Re. other platforms. I have not tested anything. I have no hardware of any platform for DIY LocoNet (except this one) and there are no tests committed to the repository. There are also no instructions on what to test or how to execute tests. There are also no instructions on how to compile for different platforms. I could not even get the existing STM32F1 port to compile, as it has some dependencies that are not documented. thanks, Balazs

[kiwi64ajs]

Hi Balazs,

On 27 May 2024, at 12:56 AM, Balazs Racz ***@***.***> wrote: Hi Alex, Yes, I made it in time. Just. The device worked well during the entire weekend, and people had fun. I have observed no issues relating to stability or the loconet library in any form. I ended up not porting the application code that I pointed you to, but rather just writing my own code.

Excellent. What does the node do exactly? Is this something others would use or quite specific to a your situation?

The only issue I found was that the uhlenbrock message type doesn't work at all on any platform that's not an 8-bit microcontroller. There is an extra alignment byte added on a 32-bit compiler that just makes the entire struct not work. I had to write my own uhlenbrock message implementation.

Interesting… This will also affect the LocoNet2 library as the newer chips are mostly 32-bit. Is there any general solution to this? I think on some compilers, there is a #pragma PACK or some such directive to force structures to be byte aligned, but perhaps that only works on the AVR GCC. Is the behaviour predictable so you can pad/alter the structures so the fields are in the right place? I guess the structure is probably bigger than the array of LocoNet bytes, so there is no simple solution other than inserting blank bytes when you know you’ve got an Uhlenbrock message, so the values appear in the write struct fields.

Re. EEPROM. The STM32 Arduino ecosystem does have an EEPROM class, but it has a really poor implementation that basically wears out flash very quickly. The STM32F1 has the same situation. I am a little unclear why the APIs around SV's and LNCV's are dependent on the EEPROM class (in my opinion these should be just callbacks), but since this was not important for my application, I just copied whatever the STM32F1 had.

Yeah, on my LocoNet2 library, I considered adding a Storage Class that the developer can provide to allow maximum flexibility, including null implementations.

Re. other platforms. I have not tested anything. I have no hardware of any platform for DIY LocoNet (except this one) and there are no tests committed to the repository. There are also no instructions on what to test or how to execute tests. There are also no instructions on how to compile for different platforms. I could not even get the existing STM32F1 port to compile, as it has some dependencies that are not documented.

Ok. I’ll compile and run some of the examples on some AVR hardware to make sure that still works and nothing obvious is broken. That’s why I try to resist adding to this LocoNet library, as all the platform-specific stuff is entangled in conditional compilation. Alex