Hello embedded community,

I am working on an automotive project where the processing card is already fixed (Renesas Rcar H3 starter kit). It has many peripherals : CAN, USB, QSPI, Ethernet ...

However there isn't enough ones for my project, besides I need simple GPIO pins to control 4 LEDs, a DC motor and an alarm buzzer for my automotive application.

I tried exploring the QSPI but I cannot find any way to use it for all those actuators. Another option I found is to use an Ethernet to Serial adapter (see given link example) to make use of the ethernet and control the multiple elements I have in a simple serial com.

I am still not sure about the feasability so I cannot get the module unless it is certain, can anyone confirm and give more details about this. Any clues/advice would be welcomed.

Thanks and regards,

Lilia.

The most "Automotive" way would be to use CAN. You'll need some little interface modules with a CAN port and suitable IO.

These people sell them:

https://inomatic.de/en/products/can-bus-adapter-en...

No idea if they are any good - I've always made my own.

There are lots of suppliers of ready made CAN to something adapters.

MK

Hello MK,

Thanks for the answer, it goes in the same mindset as Ethernet to Serial. I will dig into it and get more details about how to do it.

Thankies.

Lilia

You can expand the number of SPI peripherals you can address by multiplexing the chip selects, rather than using one I/O pin for each chip select, but that will increase the hardware cost a bit. The company I used to work for used 4 I/O pins fed into decode circuitry at each peripheral to allow up to 15 SPI peripherals to be addressed (address 15 was reserved for I2C peripherals).

In general, it worked well, but we discovered that, because our hardware designer assigned those I/O pins for other purposes as well, there were occasional problems with SPI devices that didn't "play well with others." Specifically, the other uses of those lines would occasionally cause spurious transient chip select activations (activate and immediately deactivate), and some SPI peripherals don't qualify the incoming data with the state of their chip select line; whatever information is being transferred via the MOSI and SCLK lines was *always* being captured into the receive buffer, and that information would be used to update the state of the device upon *any* active-to-inactive transition of the chip select line.

The correct way of dealing with the situation would have been not to have other uses for the pins used to generate the SPI chip selects, but I suspect we'd have been ok if the decoding circuitry had held the SCLK signal inactive when the SPI peripheral wasn't selected.

Hello Steve,

Thanks for the valuable answer, in my case, I have one QSPI interface with 4 data lines, a Clk and one CS. I have already looked into controlling many slaves through different CS but as mentionned my board doesn't have any GPIO pins at all (It has CAN, USB, HDMI, QSPI, Ethernet, COM express pins, jtag, debug). 

If I understand correctly your suggestion, I would be adding a 3:8 decoder to control my 6 serial elements (4LEDs, motor, alarm), in other words I would only need 3 signals for conrolling 6 slaves instaead of 6 CS, but this would still require 2 other pins. This would be a great idea (correct me please if I am wrong) but I lack control pins.

I remain with the converters suggestion (CAN/Ethernet to serial) which seems feasible, but I keep yours in mind.

Many thanks,

Lilia.

That's pretty much how it works. You do need to have the extra I/O pins that you can use that way, though. If you really don't have any extra I/O pins, it might be possible to have your QSPI CS control an I/O expander chip, so that you would use a 3-step process:

1. Have the I/O expander chip set the desired "extended" CS to active.

2. Do the transaction for the peripheral.

3. Have the I/O expander set the extended CS lines to inactive.

This does require that you be able to perform a QSPI transaction without activating the built-in CS in step 2, or that you have some other way of preventing the I/O expander from responding to the transaction for the other peripherals.

The first hit of google search points straight to the corresponding page of Renesas web site. This page says: "There is also a 440-pin expansion port that enables use of all the peripheral pins of the R-Car SoC". I would guess that you can find much more than 4 GPIOs on this port.

Renesas requires an account to access the documents. I am not going to register there, sorry.

Hello VadimB,

Thanks for the guidance, effectively there is a COM Express interface with 440-pin (see attached figure). I am still documenting about it, at first sight it also needs an adapter to get serial pins however I am still not sure if it possible and if it is the easiest way to proceed.

COM Express Interface.png

Thanks and regards,

Lilia.