kiwi64ajs
commented
1 year ago Yes, absolutely!
I want to stop forcing more and more changes into that old codebase, as it's getting quite messy now with all the special cases in conditional compilations.
I’ve just pushed some more updates I did over the Christmas break to here: https://github.com/mrrwa/LocoNet2/tree/positron96-development https://github.com/mrrwa/LocoNet2/tree/positron96-development for the ESP32, which uses the UART for Rx and Tx and uses the special Rx Finite State Machine to sense if the LocoNet is busy or not and then it sends each byte and waits to receive it back and check it was the same as was sent to sense collisions.
I’ve not done much testing of the recent push, but the code from September 2022 worked quite well. However, it needed refactoring as the call-backs probably weren’t a good idea.
Have a look and see what you think. I would expect you to create another subclass from LocoNetStream as I’ve done for the ESP32.
I’d suggest you try hard to avoid doing all the bit-bashing we previously did and experiment with trying to get the “Bit 4 – RXSIF USART Receive Start Interrupt Flag” working to detect LocoNet activity, so you know it's busy or not so that when you go to Transmit using the USART, you can be more confident of not causing a collision but still have the benefit of using the hardware USART for LocoNet Rx and Tx.
If that doesn’t work, then maybe you can use a pin change interrupt on the Rx pin while it's also doing USART Rx (if that is allowed) to sense LocoNet active status. Failing that, maybe just use the Hardware INTx pin or the TCB Input Capture capability to sample the TCB counter when the LocoNet goes active and sends the startbit and then use the counter to anticipate when the byte should be received etc, to track the state of the LocoNet but still use the USART for Rx and Tx and don’t do all the bit bashing.
Hope that helps.
Regards
Alex Shepherd
m: +64-21-777764 e: @.***
On 24/01/2023, at 10:48 PM, meinarsson @.***> wrote:
I have started trying to port the Loconet library to Arduiono Nano Every. Right now it seems to me that there are enough differnces between the avr and avrmega ICPs so that it will require more changes than simply adding avrmega specific defines in ln_config.h , Would it make more sense to do this development in this library instead of the old codebase?
What is the ambitions for the two different Loconet libraries? Is the intention for Loconet2 to be the way forward and replace the old one?
— Reply to this email directly, view it on GitHub https://github.com/mrrwa/LocoNet2/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5Y53II5KRKMLHQXNERX53WT6QPNANCNFSM6AAAAAAUE3SD5U. You are receiving this because you are subscribed to this thread.
I have started trying to port the Loconet library to Arduiono Nano Every. Right now it seems to me that there are enough differnces between the avr and avrmega ICPs so that it will require more changes than simply adding avrmega specific defines in ln_config.h , Would it make more sense to do this development in this library instead of the old codebase?
What is the ambitions for the two different Loconet libraries? Is the intention for Loconet2 to be the way forward and replace the old one?