Code reuse plus some details of esp32

[unref-ptr]

Hi @laith-dosinfection , I was re-reading my code from the lwIOLink project and wanted to mention some aspects that might be useful to take into account for this project with the esp32.

• As you are using the TIOL, sending and recieving data is controlled over the TX_EN pin. Remember to flush the uart to wait until the transmission is finished.
• Checksum. You can reuse the code from here or as a starting point as to not reinvent the wheel.
• checkout the initialization for the serial uart for esp32 . If I remember correctly timing is critical for the uart so I changed the TX,RX buffer to recieve each individual frame without waiting the TX,RX buffers to be full. Otherwise the IOLink device might lose communication due to the timing deadlines in Figure A.15 of the spec
• The TIOL will capture in the RX line not only the frames from the IOLink device but also the same frames from the Master. This means that when you send the IOLink Master frames you should flush the RX buffer. I am not sure if there is a better way but this is what I did.

[laith-dosinfection]

I am very concerned about timing in general for handling the framing of the data. I will attempt to get this to work somewhat robustly using more "basic" methods. I am not much of a C++ guy, your code is a great starting point. Worst case scenario we can implement some RTOS functions tasks/timers and possibly pin a UART port to a specific core and keep that core otherwise unburdened. However, the chip is clockable to 240MHz, I think the UART speeds even at COM3 would allow for a multitasking chip to still handle the UART port.

[unref-ptr]

The maximum response delay of an IO-Link master according to time tA (Figure A.15).

COM3 ~ 43 us COM2 ~ 260 us COM1 ~ 1 ms

Arduino Serial polling

For most MCUs even COM3 is doable. The real issue at hand is the Arduino API does not really have a way to process UART data in real time. The user is dependent on the Serial objects. Typically the Arduino cores (esp32,stm,etc) set the UART interrupt in the "low-level " part of the core to process the frames and save them in a queue. This queue can then be accessed in non real-time (i.e. polling) with the well-known methods read(),available().

If you cannot interrupt your application (i.e. code with lower priority that is not the IO-Link stack) to process an IO-Link device UART frame you are dependent that your application is not blocking the IO-Link stack to poll for incoming frames and reply within time tA.

Arduino delay blocks code

Another point is that IO-Link has Cycle-times with a resolution of 100 microseconds (i.e. 0.4 ms, 0.5 ms,0.6ms,etc). Nevertheless, the Arduino API only has delays in resolution of milliseconds or microseconds. The problem with microseconds is that the delayMicroseconds API is blocking by nature (at least in ESP32).

For the Wakeup generation you need to wait 80 microseconds. This in turn will block frame reception of other ports, which for COM3 is critical (max 43 us response time).

Takeaway

1) Arduino API is not advanced enough to support out of the box the IO-Link timing constraints.

• It requires an API for UART interrupts
• Does not have a Timer API 2) A compromise between Ports and cycle time resolution has to be made. As explained the more ports you have the more MSEQs have to be processed in parallel.

For point 1 you could develop an OSAL with an API for UART frame handling (instead of Serial) and Timer interrupts (instead of delay()) This is what RT-Labs did for their open-source IO-Link Master stack. If not you would have to define #ifdef preprocessor directives.

For point 2 its just a matter of testing the limitations of Arduino. I am sure that at least one port is doable with COM3, two ports with COM3 might be difficult due to the reasons above.

In general I think its possible to use the ESP32 but the Arduino API is quite poor. This could be improved as I mentioned with an OSAL.

[laith-dosinfection]

Agreed, once I complete the hardware design and can get some boards in for testing we should be able to determine some limits of the Arduino API library. An OSAL does sound like the most robust approach to hit as many ports as possible at the highest speeds possible, however, this is likely out of my depth for the time being. I think in the short term defining the bounds for the library using the Arduino API will be my first step. Assuming they are acceptable, we should be able to turn something live with these defined limits while also providing some guidelines possibly stack size, priority or pinning tasks to cores. I am not sure if I have 2 COM3 IO-link probes laying around, I might leverage your library to test this.

[unref-ptr]

Yes, an OSAL would take some time of work. In that case I would move to a more professional platform such as Zephyr OS which already supports multiple boards and drivers.

Good idea, testing it with the lwIOLink library. Just keep in mind that I poll the time to detect if the Master has sent a message in the accorded Cycle Time with micros. So it has some tolerance. In general the IO Link comm has a jitter for MSeqs of 1-10% so you will find that IO link devices are somewhat lenient on cycle time deadlines

[unref-ptr]

Oh btw sorry I think I got confused... the tA timing is critical for the IO-Link Device. The Master only has to reply on time for the cycle time.

During preoperate and startup the IO-Link Master can take all the time in the world to send the messages.

[laith-dosinfection]

This is not really an "Issue", I labelled this as documentation and will be closing the thread just for house keeping. Feel free to re-open if you want to approach the project management in a different fashion.