1
\$\begingroup\$

I have one Attiny85 and an Attiny167 that are connected by a 4 pin one meter cable. The Attiny85 controls a sensor at one end 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!

\$\endgroup\$
2
  • 3
    \$\begingroup\$ Yes, you can do slow speed bi-directional comms on a single wire. You don't even need PWM for that, other ways may be simpler and easier. Your question just focuses around the PWM idea as if it was the only solution. You have basically an XY problem, you want to do X but ask how to solve it with Y which may not be best. If you want to solve X, ask about X. \$\endgroup\$
    – Justme
    Commented Dec 11, 2022 at 14:26
  • 1
    \$\begingroup\$ en.wikipedia.org/wiki/1-Wire? \$\endgroup\$ Commented Dec 11, 2022 at 14:29

1 Answer 1

1
\$\begingroup\$

In general - yes you can. 3.3V (or 5.0V) logic should work reliably over 1 meter cable (provided that there is no significant interference from elsewhere (like motors).

On the physical side you can probably configure pins to be open-drain and enable pullups on both ends (or use external pullup resistors). The pullups are needed to have a stable level when idle.

On the protocol side you could use something even simpler than PWM. Imagine a 1ms low "sync pulse" followed by 1ms "idle" and then by 1-25 ms "message. On the receiving end you measure the sync pulse and wait for the "message" pulse. Even if the clocks are not perfectly stable you can still have good communication because the "sync" pulse defines the timings.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.