Connecting Raspi and Ardiuno gpio pins?

My bathroom illumination project is slowly progressing, but I trapped myself in its communication structure:
The Raspi uses an IR motion detector to, erm, detect motions. If he does, a pigpio interrupt fires and sets one gpio pin to high while at the same times it sends a 1 byte command over serial to the Arduino (meaning: make light!).
The Raspi pin is connected to a level shifter which switches on the background lighting of the LED display that shows current weather details and forecasts.
When the motion detector falls back to idle, the pin is set to Low and another byte code is sent via USB, this time “dim the lights”.

So far, everything is working nicely. But when new weather data has been received, the Raspi calculates a few color values and sends them to the Arduino again. This time on a thread and using 2–4 byte commands.
This is working most of the time, but it looks like it can happen that the one-byte light code is inserted by the interrupt code while sending, and so color values can be changed or the light stops working at all.

I want the light to react immediately, so I don’t want to employ the threaded send method that the color routines use.
I think the best would be to use a direct pin to pin-connection for the light: The Arduino could watch one pin and react to level changes, while there will be no interference with my data transmissions anymore.

But what connection type would be recommended? I thought about using another pin of my level shifter but maybe it isn’t necessary, but I am a bit concerned about connected both ground lines. Avoid reflow by a diode? Use an optocoupler? What would you recommend?

direct connexion will be enought
optocoupler is needed if you are dealing with mains voltages
here if you power the arduino and the raspberry with the same power supply, the ground is already connected
one gpio of the arduino to one gpio of the raspberry is ok.
if you need speed, use the arduino gpio as an interrupt for the arduino

Excellent! I had to play a bit with the PullUpDown settings, and now it’s working reliably and interrupt-driven.
Nice, thanks a lot, Jean-Yves!

you use pullup if you have multiples devices on the pin, that way one device can inform all other devices by pulling low the pin
if there is only one device to another, the pullup is not necessary.

In theory. But without using a pullUp on the Raspi pin, the level was not stable and I received a few repetitive change interrupts when there was only one. With the pullUp, it’s stable and only fires once for each real level change. Maybe the 3.3V level over the thin wire wasn’t sufficient on the Arduino pin?

strange… do you have a scope to monitor the signal on the pin ? should help to understand.

No. I collected some electronics tools and devices, but a scope is not part of them (yet) :wink:

:wink:
that’s software developpers doing electronics …
I’m an electronic engineer doing software development !

one Rigol MSO1054Z and you will better understand the inners of electronics…

wait, even the DS1054Z with 4 channels if enough to start.

Make sure you use a 3.3v arduino or a logic level converter. A common ground will be required too.

Thanks, all!
@Jean-Yves: I guess this would change a hobby into a semi-pro project: That’s more than I paid for all the Raspi stuff together. But I‘ll keep your proposal in mind if I should dive deeper into this stuff. (The second device for half of the price might speed things app, anyway :wink: )

@Derk: That is conflicting information to Jean-Yves’. I do not report back from the Ardu to the Raspi via GPIO. For this, I use the USB/Serial port. The 3,3V level seems to be enough to trigger the Ardu pin: I have that project running since yesterday and it didn’t fail. Do you have more information why this should be necessary?

Can you make the weather change the lights in the bathroom?

if one device is 3.3V and the other 5V (the arduino) then the logic high of the arduino is not the same as the Pi
so if the Pi outputs a logic high around 3v, this may be not enough to be interpreted as a high by the arduino 5v
a 3v3-5v level converter deals with that. it’s often simple as a transistor.
that transistor may be there with the pullup you mentionned mandatory ?

I hope I will!
It may sound silly, but I have a problem with getting out in time for appointments. I lose the sense of time when I prepare to leave, and when I arrive at the train station after a very fast walk, all my previous efforts in the bathroom to mask myself as a human are in vain.

While I like the Raspi mirror project that was presented here a lot, my mechanical talents aren’t that great (and I have no mirror I could mask this way). But I have a rotatable mirror rack where I initially planned to install a display driven by a Raspi, and that’s the core of the OpenWeather project I used for demonstration purposes too.

Then I realized that my cure for too long coding hours is taking long alkaline baths, and it would be great to have a relaxing illumination too. That’s where the WS2801 chains came into play, and they would fit perfectly behind the mirror rack, giving an indirect illumination.

And then I thought it would be great to use them for a fast weather information too. So the final idea is to have one side show a bar for the temperature (the current one at the top and giving a preview for the rest of the day towards the bottom), while the other side could show a color (or animated) bar for the weather conditions.

And at nighttime, I just want an undisturbing, non-blue automatic lighting so I can stay in slumber mode if I should need to see the restroom at nights.

Currently, the colors are making problems: they draw ok, but once I go into the main loop on the Arduino (looking for input an the USB port and responding to it mainly), the LEDs are somewhat dithered where there was a nice gradient before. I didn’t have that before I connected the pins, but it seems to be independent of it though.

[quote=275782:@Jean-Yves Pochez]if one device is 3.3V and the other 5V (the arduino) then the logic high of the arduino is not the same as the Pi so if the Pi outputs a logic high around 3v, this may be not enough to be interpreted as a high by the arduino 5v
a 3v3-5v level converter deals with that. it’s often simple as a transistor.
that transistor may be there with the pullup you mentionned mandatory ?[/quote]
Maybe I should really try the level shifter. I have one installed already but use only one pin (it drives the background illumination of the LCD display when the IR detector interrupt fires) and I used it for first color experiments with 5V RGB LEDs), so I’ll see if that changes anything.

Oh: And the final, final idea would be to send reminders from my Mac to the controlling Raspi to get a visual alarm when I should really leave.

That’s funny: I added the Ardu pin to the level shifter, and now the display lights up a second or so later, although both pins are set in two following code lines.
Anyway: Refreshing the LEDs, followed by a short delay, seems to handle the color problem with the main loop.

Because a picture shows more, even if it is a bad one when the cell phone camera cannot deal with the (extremely reduced) brightness of the LEDs:


To the right is the current time (will become the top), and to the left are 3 hr forecasts. Currently, it’s a bit more than 20°, that’s why its a slightly sunny yellow. Next 5 hrs or so will be around 18-19 degress = green, and then you would want some warmer clothing outside = blue.
This is much more colorful in reality …

Yes, one LED is a failure. I have to discuss with myself if I will live with that or take the strain of soldering more of those tiny pins into chain pieces …

And after some days of trying: I reverted back to a pure USB communication. The use of an Arduino interrupt for switching the lights on and off on the WS2801 caused problems with the interpolation timing of the LEDs – gradients were not smooth anymore. Instead they used a very small number of steps. Animations caused LEDs to change color while they were running.
FastLED says you are good to go with LEDs using 2 signal lines but in my case I cannot confirm this.
Once I went back to USB and removed the interrupt (and unnecessary acknowlegdes of the Arduino reporting back), the LEDs worked as intended again.

EDIT: Yes, Jean-Yves, I agree: A scope could have saved a lot of time in this case :wink:

it’s a timing problem.
usb is very slow, and interrupts are very fast.
if you slow down the process the thing works. so there is a wait to insert somewhere … but where ?
but if it’s ok for you with usb then keep it like that !

Yes. I figured out how to move the light on/off command up the communication queue in case there’s more transmissions going on which seems to work (impulsively beating the table).

If it shouldn’t work on a longer test, I guess the place to insert FastLED.shows and .delays would be my polling routine: I take the first byte of a transmission only if it’s available (of course), but in case it is a command byte that introduces a few more parameter bytes I go into a readBytes() routines which maybe isn’t interrupt-savvy.
I could change this probably by a if (Serial.datavailable …) individual poll. Currently I’m feeling lazy, and I have enough to do with trying to remember the C syntax each time I change something …

On the long run, I still have the hope that the pigpio library will make the Arduino unnecessary. On the other hand, FastLED is a really nice library and I wouldn’t want to compute all that stuff on my own, so take that as a very long run.

[quote=275780:@Ulrich Bogun]Thanks, all!
@Derk: That is conflicting information to Jean-Yves’. I do not report back from the Ardu to the Raspi via GPIO. For this, I use the USB/Serial port. The 3,3V level seems to be enough to trigger the Ardu pin: I have that project running since yesterday and it didn’t fail. Do you have more information why this should be necessary?[/quote]

Well for one, you might burn the Pi’s chips. Second the communication could give errors.
It’s better to have 3.3v - 3.3v or 5v - 5v both with common ground.