Interfacing two Attinys by one pwm wire only. Is it a possible approach?

[Rimbaldo]

Hi!

I have one Attiny85 and an Attiny167 that are connected by a 4 pin one meter cable. The Attiny85 controls a sensor at one of the cable, and the Attiny167 controls the battery and other stuff at the other end of the cable. I have only one pin on the Attiny85 available and only one wire available in this 4 pin cable for communication (besides GND, which is one of the other wires in the cable) to connect each other.

The Attiny 85 pin is PB4, so it can output PWM signals.

I need to ocasionally send control signals to each other, and as I only have one wire available as input and output, for both sides, I though to overcome it in this way below. If you can, tell me if it's possible to be done.

These control signals won't be much, maybe 10 different commands between each other. Maybe even less. Some commands from the Battery-Attiny (BAttiny) to the Sensor-Attiny (SAttiny) and some the other way around. Also, super fast speeds between them is not a concern.

These commands I thought about being 10 different duty cycles, apart evenly from each other from 0-255, so to help to avoid noise and overlapping signals. For instance: the first is 0 PWM. The second is 25 PWM. And so on till 255 PWM.

Both MCUs will be powered up at the same time, at the same voltage (5V for now).

BAttiny starts with the GPIO Pin in an output state, and SAttiny with the GPIO pin set as Input. I can delay some milliseconds in Setup() so I can be sure that each MCU has the pin GPIO pin set correctly.

Then They'll keep sending a PWM idle signal (let's say: PWM (25)) back and forth, like this:

1. BAttiny as Output, sends a Pwm (25) to SAttiny as input, and after sending the signal, BAttiny changes the pinmode to INPUT.

2. After receiving a Pwm (25) signal, SAttiny changes it's PB4 pin to Output. It decodes the PWM signal received with pulsein().

3.If nothing is needed to be done, it sends back a Pwm (25) signal to BAttiny (which GPIO pin in now in INPUT mode). SAttiny changes the pin state to INPUT again.

4. Battiny (In input mode) receives the signal and changes it's pin state to output. It decodes the signal and sends back a pwm signal to SAttiny.

If the PWM signal received is another than Pwm (25), a function is performed in the received MCU.

And the back and forth pwm sending and receiving, and pinmode() changing continue forever.

I can time with millis() so this back and forth sending and receiving control signals happens only after X milliseconds.

So... is this doable? Feasible? Could I send and receive different "commands" between both MCUs with only one wire, by pwm, doing this way? Are there any problems by doing it this way?

Thanks for reading!

I

[Deva_Rishi]

PWM is not a data transfer protocol ! receiving the length of the duty cycle is near impossible.
Half duplex 2 way data transfer is of course always tricky.
Since both MCU's are performing all sorts of tasks a slow protocol like DALI might be OK, it doesn't use much resources, is self clocking and can be received through 'polling' interrupts are not even required.

A simpler method could be sending a long pulse, then send a series of short pulses, and finish with a long pulse, and count the pulses.

But personally i would go DALI but with 5v (not the 12v standard) but with the Opto-Couplers, although just a 1 K resistor inline will actually suffice to protect the pins from burning if they both are in OUTPUT at the same time.

[ZX80]

pulsein() maybe.

[hmeijdam]

Your concept looks ok to me.
I like how telemetry receivers in RC planes work with their sensors. The receiver (the master) polls one or more sensors (the slaves) and the slave sensor has to respond within a given timeframe. The slave will never send something without being requested, to avoid starting to send something at the same time. To assure that messages from the slave get heard in time, the master will poll the slave periodically, to ask if it has something to report.

With the few different commands and your low timing requirements, I would just count pulses in both master and slave and if no more pulses arrive within 10 milliseconds or so consider the pulstrain complete. Using a Pinchange ISR for that would make it respond fast and straightforward to implement.