Lack of pure Arduino support

[louisking-penmedtech]

We're trying to run this library on a Teensy 4.1 rather than the ESP32 and finding a lot of code written only for the former,

Is it possible to run this library on a different Arduino-supported hardware platform rather than the dev board mentioned?

[maarten-pennings]

The aospi library implements the data link layer. It tries to keep complexity low by focusing: implementing only MCU mode, only on ESP32S3, only with matching PCB wiring/components.

Once a hardware/software platform is selected, a choice has to be made how to transmit and receive telegrams. In case of the ESP32S3 on Arduino, we picked SPI for both. Transmission is relatively straightforward, Arduino comes with an SPI "master" library. Reception proved harder, Arduino does not come with a standard SPI "slave" library. Furthermore, OSP nodes do not provide a slave select signal towards the MCU, a signal which is required by the ESP SPI slave block. There are additional issues which require additional hardware.

Since the hardware support varies from MCU to MCU, since software support (for slaving) is missing in Arduino, and given the additional issues, we decided to focus on one solution, and isolate that in one library aospi. Other solutions require their own library.

All aolibs should work on any Arduino (which has enough memory and speed), except for aospi. Library aospi works with the hardware on the OSP32 board.

So you will need to write a library for the Teensy, using its SPI blocks (or is there something better?), solving the missing slave select, and the other issues, which likely means extra hardware around the Teensy.

[louisking-penmedtech]

@maarten-pennings thanks for getting back to me so quickly. Coincidentally we've followed what you've suggested - we've rewritten part of the aospitx example to work without the ESP-IDF - I'll post the results on here and any snags we run into.

[louisking-penmedtech]

If your connection setup looks like this, is the aospi_txrx example the only one that's appropriate?

I notice that the startup guide lists this as a bidirectional wiring schema but it's not clear whether the other examples will still function.

[maarten-pennings]

Hi @louisking-penmedtech, I'm not completely sure what you are asking.

With the sketched schematics you have a bidir wiring (assuming you add a terminator on the right hand side). There are no differences between bidir and loop wiring from a functional point of view: you can send any telegram, receive any response, irrespective of the bidir or loop wiring. There are of course differences in the timing of telegrams and their responses.

All examples should work. One disclaimer: if an example has a call to aoosp_send_initloop this must be changed to ...bidir, but the rest of the code in the example should work.

Second note, the schematics are abstract, in real life you need more; do you need a level-shifter, how do you solve the missing slave select signal, do you have any hardware for the RESET issue?

[maarten-pennings]

Hi @louisking-penmedtech , I just realized that your schematics does not show the OSP reception part.

It is posisble to send telegrams without having reception operational (ignoring response telegrams) but it would be limiting.

To receive response telegrams, you would typically have a harwdare block configured for SPI slaving. It could be a second block, next to the "SPI1 (Tx master)". This is what we did on the OSP32 board, using a separate SPI block in ESP32. Alternatively you could reuse the SPI1 block: it is always "listening" (receiving response telegrams) except when sending a telegram (time division role switching).

[louisking-penmedtech]

We used the single SPI master approach on an ESP32 dev board and the Teensy but neither worked, we'll try the split Master/slave approach shortly but I also think the setup needs refinement as there's too much capacitance.

[louisking-penmedtech]

Currently we get no response from the first SAID (an E373i) and nothing is 'passed on' to the bus behind it.

[louisking-penmedtech]

At first glance our initialisation looks good, when we add up the bits transmitted accounting for Manchester encoding we appear to be setting up correctly.

Just in case, does anything look off to you?

[maarten-pennings]

When I handdecode the manchester (01->1, 10->0) I get 1010 0000, 0000 0000, 0000 0000, 0010 0010, or in hex A0 00 00 22. When I graph that, I get

(env) OSP_aospi\python\telegram>run A0 00 00 22
          +---------------+---------------+---------------+---------------+
byteval   |      A0       |      00       |      00       |      22       |
byteix    |0 0 0 0 0 0 0 0|1 1 1 1 1 1 1 1|2 2 2 2 2 2 2 2|3 3 3 3 3 3 3 3|
bitix     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
bitval    |1 0 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 1 0 0 0 1 0|
          +-------+-------+-----------+---+-+-------------+---------------+
field     |preambl|      address      | psi |   command   |      crc      |
bin       | 1010  |    0000000000     | 000 |   0000000   |   00100010    |
hex       |  0xA  |       0x000       | 0x0 |    0x00     |   0x22 (ok)   |
meaning   |   -   |     broadcast     |  0  |    reset    |    34 (ok)    |
          +-------+-------------------+-----+-------------+---------------+
Done

which looks good: a reset telegram in broadcast, with correct CRC.

[maarten-pennings]

Hi @louisking-penmedtech , you write

Currently we get no response from the first SAID (an E373i) and nothing is 'passed on' to the bus behind it.

SAID is the nickname of the AS1163, E3731i is the typenumber of the component with nickname RGBI.
So what do you have as first component, a SAID or an RGBI? If you have an RGBI you indeed must use Manchester, it does not support the two-wire SPI that the SAID does.

Did you have a look at aospi_bringup, it shows how you can verify if a telegram is correctly received.

Thirdly, I assume you use a level shifter, since the Teensy is 3V3 and OSP is 5V0. How does the level shifter look like? Level shifters tent to have pull-ups, breaking the OSP SIO configuration, did you check the readme?