Question/improvement: is ICP really required?

[positron96]

Hi! Just wanted to ask - what is the reason to require RX pin to be ICP-enabled? As I understand it, the interrupt is only required to capture falling edge of start bit (then the timer is used to read bits), and that can be achieved with normal arduino interrupt on pins 2 and 3 and pin change interrupt which is supported by practically all pins of Arduino. I have not tried it with Loconet, but have successfully used 2 quadrature encoders (4 pins) connected to arduino's A0-A3 pins with pinchange interrupts.

[kiwi64ajs]

Hi Pavel

On 3/06/2020, at 8:34 PM, Pavel Melnikov notifications@github.com wrote: Hi! Just wanted to ask - what is the reason to require RX pin to be ICP-enabled? As I understand it, the interrupt is only required to capture falling edge of start bit (then the timer is used to read bits), and that can be achieved with normal arduino interrupt on pins 2 and 3 and pin change interrupt which is supported by practically all pins of Arduino. I have not tried it with Loconet, but have successfully used 2 quadrature encoders (4 pins) connected to arduino's A0-A3 pins with pinchange interrupts.

It was really just avoiding interrupt latency detecting the start-bit.

At the time the thing I liked about the ICP was that the hardware captured the 16-bit clock value on the LocoNet start-bit, which was independent of interrupt latency and then the soft UART just stepped-along the right 16-bit bit timing intervals and sampled the pin state to implement the UART.

Also as the AT Mega328 didn’t have a spare UART it seemed like a good choice at the time.

If I was to do it again from scratch I’d probably got for an option that used the hardware UART and maybe a pin change interrupt on the same pin to detect LocoNet Busy state.

The new ARM chips have an interesting UART collision sensing mechanism in hardware which I’m hoping to play with soon.

Also that’s why I started the LocoNet2 library that was a fresh start…

HTH

Alex Shepherd

[positron96]

Is interrupt latency important here? 16 kbps does not seem that fast for it to matter.

[devel-bobm]

Pavel wrote: "Is interrupt latency important here?"

Consistent latency plays a vital role in predictably finding the "center" of a LocoNet bit. If you stray too far from "center", you could end up using a "sample point" for a bit to be too close to the trailing-end of the bit-time. And that could result in sampling the following bit instead of the current bit. The net result could be "inconsistent bit sampling" and incorrect interpretation of LocoNet messages. Which could result in inappropriate issuing of the "BREAK" event due to incorrect checksum validation. Which would reduce (perhaps significantly) the effective available LocoNet bandwidth.

In my opinion, it would be a bad engineering choice to risk that kind of outcome.

Note that interrupt latency was a significant problem for the earliest predecessors of the MRRwA library for LocoNet. Such solutions were often based on Microchip PIC (and similar) microcontrollers, running at low clock frequencies. I recall designs where there were a total of about 50 available clock cycles per LocoNet bit. In such an environment, there really isn't any room for handling any interrupts OTHER than the "LocoNet Data Changed" interrupt.

Whether or not an Arduino can support other interrupts ongoing when the library is awiting for a new LocoNet message is a different question. Analysis of such a question depends on far too many variables. That is not a "rat-hole" I care to go down.

From the perspective of developing a generic library like the MRRwA LocoNet library, it is "safest" to assume the interrupt will be a high-priority interrupt and that other interrupt service routes must not hog all of the processor's cycles.

Regards, Billybob

[kiwi64ajs]

Yeah, it was all about getting consistent bit sampling latency and it was also an available resource on the ATMega328 that was capable of doing the job.

I also wanted to keep the INT/0/1 ports free for DCC decoder interfacing so there weren't many other choices.

Obviously using a hardware UART would be much better although with the AVR’s there isn’t a convenient way to detect a busy LocoNet so we’d probably need to use the UART + a Pin Change Interrupt to know when we’d started to receive a byte and to start the various back-off timing etc.

I not the new ARM processors have a collision sensing feature on their UARTs so I’m keen to experiment with them to see how they work.

Alex

On 8/06/2020, at 8:03 AM, Bob Milhaupt notifications@github.com wrote:

Pavel wrote: "Is interrupt latency important here?"

Consistent latency plays a vital role in predictably finding the "center" of a LocoNet bit. If you stray too far from "center", you could end up using a "sample point" for a bit to be too close to the trailing-end of the bit-time. And that could result in sampling the following bit instead of the current bit. The net result could be "inconsistent bit sampling" and incorrect interpretation of LocoNet messages. Which could result in inappropriate issuing of the "BREAK" event due to incorrect checksum validation. Which would reduce (perhaps significantly) the effective available LocoNet bandwidth.

In my opinion, it would be a bad engineering choice to risk that kind of outcome.

Note that interrupt latency was a significant problem for the earliest predecessors of the MRRwA library for LocoNet. Such solutions were often based on Microchip PIC (and similar) microcontrollers, running at low clock frequencies. I recall designs where there were a total of about 50 available clock cycles per LocoNet bit. In such an environment, there really isn't any room for handling any interrupts OTHER than the "LocoNet Data Changed" interrupt.

Whether or not an Arduino can support other interrupts ongoing when the library is awiting for a new LocoNet message is a different question. Analysis of such a question depends on far too many variables. That is not a "rat-hole" I care to go down.

From the perspective of developing a generic library like the MRRwA LocoNet library, it is "safest" to assume the interrupt will be a high-priority interrupt and that other interrupt service routes must not hog all of the processor's cycles.

Regards, Billybob

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mrrwa/LocoNet/issues/14#issuecomment-640271913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5Y53OW2HPCCPYU5ZVUCF3RVPW7XANCNFSM4NROJEPQ.

[positron96]

Thank you for your answers, guys! It's interesting that I am playing with LocoNet 2 library and ESP32 now, and have timing issues. Hope they will be solved with an oscilloscope.