Kommunikation uC <-> uC via PIN

[Ronny G. (mogel)]

Moin,


ich habe eine ATTiny13 und eine Teensy (4.0 bzw. 4.1). Der Tiny sitzt 
auf einem extra Board und ist dort für das Ein-/Ausschalten des Boards 
zuständig (Selbsthaltung). Das Board enthält dann noch Spannungswandler 
für 5V, 3.3V, LED und Button, diversen Kleinkram.

Über den Button möchte ich auf dem Teensy verschiedene Modi auslösen 
(Pairing, Default-Werte, ...). Der Wechsel auf dem Tiny funktioniert 
über kurzes bzw. langes drücken das Buttons. Der dazu nötige Code 
funktioniert soweit.

Mein Problem ist eigentlich die Kommunikation zum Teensy. Dazu setze ich 
die Pins PB3, PB4 und PB5 (Fuse ist gesetzt). Diese gehen 1:1 ohne 
irgendwas an den Teensy und der reagiert an den Eingängen nicht.

Meine Vermutungen:

-> der Tiny wird mit 5V betrieben, an den Pins kommen 5V raus, ist für 
den Teensy am Eingang ggf. zu hoch

-> ich sollte evt. noch die Leitungen mit 1k zu GND verkuppeln, dachte 
eigentlich das im Tiny/Teensy das automatisch geregelt wird

-> den Tiny mit 3.3V betreiben

Was ist am sinnvollsten?



danke, mogel

[50c (Gast)]

Ronny G. schrieb:
> -> den Tiny mit 3.3V betreiben

ja, und Pullup-Widerstände

[Mario M. (thelonging)]

Ronny G. schrieb:
> Tiny wird mit 5V betrieben,

Ronny G. schrieb:
> Diese gehen 1:1 ohne irgendwas an den Teensy und der reagiert an den
> Eingängen nicht.

Eingänge des Teensy kaputt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ronny G. schrieb:
> Meine Vermutungen:
> -> der Tiny wird mit 5V betrieben, an den Pins kommen 5V raus
Mach aus Vermutungen Gewissheit und miss einfach mal nach.

> -> ich sollte evt. noch die Leitungen mit 1k zu GND verkuppeln,
Wie kann man sich das schaltungstechnisch vorstellen? Und was ist der 
Zweck der Aktion?

> dachte eigentlich
Denken strengt an und bringt oft Fehler. Ich lese deshalb einfach das 
Datenblatt. Evtl. steht da die Lösung und ich muss mich nicht 
anstrengen.

> das im Tiny/Teensy das automatisch geregelt wird
Wie würdest du denn so einen "Automatimus" steuern, wenn du der 
Teensy-Entwickler wärst?

> Was ist am sinnvollsten?
Sorge dafür, dass passende Pegel an den Pins anlegst. Wenn eine 
Möglichkeit ist, die beiden Teilnehmer entsprechend zu versorgen, dann 
nimm die.

Mario M. schrieb:
> Ronny G. schrieb:
>> Diese gehen 1:1 ohne irgendwas an den Teensy und der reagiert an den
>> Eingängen nicht.
> Eingänge des Teensy kaputt.
Ich würde da einfach mal nachmessen.

[Ronny G. (mogel)]

Moin,

der Tiny wird mit 3.3V versorgt und liefert an den Pins nun entsprechend 
3.3V. Da war also ein Fehler.

Nach einigen Tests und einem KSKB funktionieren die Pins aber mein Code 
nicht.

uint8_t Modeline::getModeline() {
    uint8_t mode0 = 1 - digitalRead(PIN_MODELINE_0);
    uint8_t mode1 = 1 - digitalRead(PIN_MODELINE_1);
    uint8_t mode2 = 1 - digitalRead(PIN_MODELINE_2);
    return (((mode2 << 8) + mode1) << 8) + mode0;
}

Wenn ich nötige Bits raus schiebe, dann kann das auch nix werden -.-

danke, mogel

[MaWin (Gast)]

Ronny G. schrieb:
> Mein Problem ist eigentlich die Kommunikation zum Teensy. Dazu setze ich
> die Pins PB3, PB4 und PB5 (Fuse ist gesetzt). Diese gehen 1:1 ohne
> irgendwas an den Teensy und der reagiert an den Eingängen nicht.

Üblich wäre eine serielle Schnittstelle, Rx/Tx oder SPI.

Und ein Pegelwandler.

Bei Rx/Tx reicht unidirektional, bei SPI muss er bidirektional sein.

https://www.amazon.de/Converter-Pegelwandler-BiDirektional-Raspberry-Mikrocontroller/dp/B07DKT9JXT/ref=asc_df_B07DKT9JXT/

Warum meinst du, ist deine nicht-funktionierende Lösung die mehr Pins 
belegt besser ?

[Stefan F. (Gast)]

Ronny G. schrieb:
> uint8_t
> return (((mode2 << 8) + mode1) << 8) + mode0;

Die schiebst die Bits viel zu weit. In einem 8 Bit Register darfst du 
insgesamt maximal 7x schieben.

Vielleicht ist es so verständlicher:

return 4*mode2 + 2*mode1 + 1*mode0;

[Ronny G. (mogel)]

MaWin schrieb:
> Warum meinst du, ist deine nicht-funktionierende Lösung die mehr Pins
> belegt besser ?

SPI belegt auch 3 Leitungen. Da ich aber mit den drei Leitungen wirklich 
nur die Information über den Modus-Wechsel rüber schicke, halte ich SPI 
für Overkill (mal abgesehen davon das der Tiny schon mit 75% voll ist).

void setModelines(PCUMODE mode) {
  // neuen Modus an Teensy melden
  chgLED(PIN_MODELINE0, (mode & (1 << 0)) != 0);
  chgLED(PIN_MODELINE1, (mode & (1 << 1)) != 0);
  chgLED(PIN_MODELINE2, (mode & (1 << 2)) != 0);
  // etwas Zeit verplempern
  cli();
  long_delay(1000);
  sei();
  // Modus zurück setzen
  clrLED(PIN_MODELINE0);
  clrLED(PIN_MODELINE1);
  clrLED(PIN_MODELINE2);
  pcuMode = PCUMODE_NORMAL;
}

Ich habe hier noch genug Kommunikation zwischen den beiden Teensy (via 
Bluetooth) und dann kommen noch Rechner bzw. Tablet (parallel, via 
Bluetooth).

Stefan ⛄ F. schrieb:
> return 4 * mode2 + 2 * mode1 + 1 * mode0;

Die Variante sollte ich mir vielleicht für reine Bit-Sachen angewöhnen. 
Meistens zeihe ich aus irgend welchen Arrays 32 Bit Zahlen und die 
schiebe ich wie in meinem Code zusammen. War also ein 
"Gewohnheits-Fehler", dazu kommt noch Betriebsblindheit (da ich eher 
selten mit reinen Bits arbeite).

hand, mogel