Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
Das werd ich sofort! prüfen. Danke.
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Laufen die abstürzenden auch tatsächlich mit 5V oder nur mit 3,3V?Alexander470815 hat geschrieben: ↑Mi 5. Okt 2022, 06:55 Auf denen die ich habe steht 328P drauf, sie identifiziert sich aber als 328PB.
6stk von dem einen Verkäufer laufen auch klaglos mit 16MHz und verrichten ihre Arbeit, die anderen 9stk aus anderer Quelle stürzen alle paar Sekunden ab. Der Programmcode zählt einfach nur variablen hoch und gibt diese auf der UART aus.
Von daher gehe ich von einem Hardware defekt aus.
- Alexander470815
- Beiträge: 2385
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
5V, da Arduino Nano Standard Board direkt mit 5V gespeist aus einem 7805.Weisskeinen hat geschrieben: ↑Do 6. Okt 2022, 14:11 Laufen die abstürzenden auch tatsächlich mit 5V oder nur mit 3,3V?
Zusätzliche Abblockkondensatoren bringen keine Veränderung.
Habe auch nochmal direkt an den Pins nachgemessen, bekommt auch die 5V.
Re: Der AVR-/ARDUINO-Faden
meine 5 Nanos sind gekommen, melden sich ordnungsgemäß als 328P, per ISP gefragt. zumindest der eine getestete.
Hier gibt's (auch?) eine Problematik mit den PB:
https://wiki.mobaledlib.de/
Hast du mal ohne Bootloader probiert?
KA ob ein falscher die zum abstützen bringen könnte. oder falsche Fuses.
nochmal edit bzgl unten . ah so. ok.
Hier gibt's (auch?) eine Problematik mit den PB:
https://wiki.mobaledlib.de/
Hast du mal ohne Bootloader probiert?
KA ob ein falscher die zum abstützen bringen könnte. oder falsche Fuses.
nochmal edit bzgl unten . ah so. ok.
Zuletzt geändert von ch_ris am Fr 21. Okt 2022, 06:36, insgesamt 2-mal geändert.
- Alexander470815
- Beiträge: 2385
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
Die Abstürze habe ich jetzt in den Griff bekommen indem ich noch direkt an die Versorungspins einen 100n gelötet habe. Damit funktioniert es zuverlässig.
Irgendwas ist mit den Platinen komisch.
Das es ein PB ist stört mich eigentlich nicht, der kann immerhin mehr.
Irgendwas ist mit den Platinen komisch.
Das es ein PB ist stört mich eigentlich nicht, der kann immerhin mehr.
Re: Der AVR-/ARDUINO-Faden
Hallo,
ich suche eine Divisionsroutine für 8 Bit Prozessor (ATTINY).
das hier funktioniert, ich bräuchte es aber für (24Bit : 16 Bit) = (16 Bit), also mit 3 Byte Dividenten, 2 Byte Divisor, 2 Byte Ergebnis.
http://www.avr-asm-tutorial.net/avr_de/ ... div8d.html
ich komme leider nicht alleine drauf Kann mir jemand helfen?
EDIT: 16 Bit Divident reicht auch. Nur der Divisor muss auf 16 Bit erweitert werden
NOCHEINEDIT: ich habe bei Microcontroller.net das hier gefunden:
das bastele ich mal rein, und teste es
ich suche eine Divisionsroutine für 8 Bit Prozessor (ATTINY).
das hier funktioniert, ich bräuchte es aber für (24Bit : 16 Bit) = (16 Bit), also mit 3 Byte Dividenten, 2 Byte Divisor, 2 Byte Ergebnis.
http://www.avr-asm-tutorial.net/avr_de/ ... div8d.html
Code: Alles auswählen
div:
;.DEF rd1l = R0 ; LSB Divident
;.DEF rd1h = R1 ; MSB Divident
;.DEF rd1u = R2 ; Hifsregister
;.DEF rd2 = R3 ; Divisor
;.DEF rel = R4 ; LSB Ergebnis
;.DEF reh = R5 ; MSB Ergebnis
;.DEF rmp = R16; Hilfsregister zum Laden
;
; Divieren von rd1h:rd1l durch rd2
div8:
clr rd1u ; Leere Hilfsregister
clr reh ; Leere Ergebnisregister
clr rel ; (Ergebnisregister dient auch als
inc rel ; Zähler bis 16! Bit 1 auf 1 setzen)
;
; Hier beginnt die Divisionsschleife
;
div8a:
clc ; Carry-Bit leeren
rol rd1l ; nächsthöheres Bit des Dividenten
rol rd1h ; in das Hilfsregister rotieren
rol rd1u ; (entspricht Multipliklation mit 2)
brcs div8b ; Eine 1 ist herausgerollt, ziehe ab
cp rd1u,rd2 ; Divisionsergebnis 1 oder 0?
brcs div8c ; Überspringe Subtraktion, wenn kleiner
div8b:
sub rd1u,rd2 ; Subtrahiere Divisor
sec ; Setze carry-bit, Ergebnis ist eine 1
rjmp div8d ; zum Schieben des Ergebnisses
div8c:
clc ; Lösche carry-bit, Ergebnis ist eine 0
div8d:
rol rel ; Rotiere carry-bit in das Ergebnis
rol reh
brcc div8a ; solange Nullen aus dem Ergebnis
; rotieren: weitermachen
; Ende der Division erreicht
ret
EDIT: 16 Bit Divident reicht auch. Nur der Divisor muss auf 16 Bit erweitert werden
NOCHEINEDIT: ich habe bei Microcontroller.net das hier gefunden:
Code: Alles auswählen
Division
32 Bit / 32 Bit
Ergebnis gerundet, und mit Restbildung.
.def a0 = r16
.def a1 = r17
.def a2 = r18
.def a3 = r19
.def b0 = r20
.def b1 = r21
.def b2 = r22
.def b3 = r23
.def t0 = r24
.def t1 = r25
.def t2 = r26
.def t3 = r27
.def t4 = r28
;************************************************************************
;* *
;* unsigned rounded division 32 bit *
;* *
;************************************************************************
urdiv32:
mov t0, b0 ;T = B
mov t1, b1
mov t2, b2
mov t3, b3
lsr t3 ;B / 2
ror t2
ror t1
ror t0
add a0, t0 ;A = A + B / 2
adc a1, t1
adc a2, t2
adc a3, t3
;************************************************************************
;* *
;* unsigned division 32 bit *
;* *
;************************************************************************
; a3..0 = a3..0 / b3..0 (Ganzzahldivision)
; b3..0 = a3..0 % b3..0 (Rest)
; cycle: max 684
udiv32:
clr t0
clr t1
clr t2
clr t3
ldi t4, 32
udi1: lsl a0
rol a1
rol a2
rol a3
rol t0
rol t1
rol t2
rol t3
cp t0, b0
cpc t1, b1
cpc t2, b2
cpc t3, b3
brcs udi2
sub t0, b0
sbc t1, b1
sbc t2, b2
sbc t3, b3
inc a0
udi2: dec t4
brne udi1
mov b0, t0
mov b1, t1
mov b2, t2
mov b3, t3
ret
Eine Version, die je nach konkreten Zahlen Rechenzeit einspart
.def a0 = r16
.def a1 = r17
.def a2 = r18
.def a3 = r19
.def b0 = r20
.def b1 = r21
.def b2 = r22
.def b3 = r23
.def t0 = r24
.def t1 = r25
.def t2 = r26
.def t3 = r27
;************************************************************************
;* *
;* unsigned rounded division 32 bit *
;* *
;************************************************************************
urdiv32:
mov t0, b0 ;T = B
mov t1, b1
mov t2, b2
mov t3, b3
lsr t3 ;B / 2
ror t2
ror t1
ror t0
add a0, t0 ;A = A + B / 2
adc a1, t1
adc a2, t2
adc a3, t3
;************************************************************************
;* *
;* unsigned division 32 bit *
;* *
;************************************************************************
;cycle: max 431 (63%) (684)
udiv32:
clr t1
tst b3
breq udi10
ldi t0, 8
udi1: lsl a0
rol a1
rol a2
rol a3
rol t1
cp a1, b0
cpc a2, b1
cpc a3, b2
cpc t1, b3
brcs udi2
sub a1, b0
sbc a2, b1
sbc a3, b2
sbc t1, b3
inc a0
udi2: dec t0
brne udi1
mov b0, a1
clr a1
mov b1, a2
clr a2
mov b2, a3
clr a3
mov b3, t1
ret
udi10: tst b2
breq udi20
ldi t0, 16
udi11: lsl a0
rol a1
rol a2
rol a3
rol t1
brcs udi12
cp a2, b0
cpc a3, b1
cpc t1, b2
brcs udi13
udi12: sub a2, b0
sbc a3, b1
sbc t1, b2
inc a0
udi13: dec t0
brne udi11
mov b0, a2
clr a2
mov b1, a3
clr a3
mov b2, t1
ret
udi20: tst b1
breq udi30
ldi t0, 24
udi21: lsl a0
rol a1
rol a2
rol a3
rol t1
brcs udi22
cp a3, b0
cpc t1, b1
brcs udi23
udi22: sub a3, b0
sbc t1, b1
inc a0
udi23: dec t0
brne udi21
mov b0, a3
clr a3
mov b1, t1
ret
udi30: ldi t0, 32
udi31: lsl a0
rol a1
rol a2
rol a3
rol t1
brcs udi32
cp t1, b0
brcs udi33
udi32: sub t1, b0
inc a0
udi33: dec t0
brne udi31
mov b0, t1 ;store remainder
ret
;------------------------------------------------------------------------
Re: Der AVR-/ARDUINO-Faden
Lässt sich beim Arduino der CS-Pin des SPI Bus über einen PCF8574 Port Expander routen?
Der normale Aufruf ist
MCP2515 mcp2515(3); // CS Pin
Muss ich die MCP2515 Klasse dafür umbauen, oder wie kann man das machen.
Den Pin schreibe ich über
PCF8574(addr).write(pin, state);
Der normale Aufruf ist
MCP2515 mcp2515(3); // CS Pin
Muss ich die MCP2515 Klasse dafür umbauen, oder wie kann man das machen.
Den Pin schreibe ich über
PCF8574(addr).write(pin, state);
Re: Der AVR-/ARDUINO-Faden
Keine Ahnung.
Würde meinen du könntest die zuständige Routine der MCP2515 Lib in deinem eigenen Code überladen/überschreiben.
Dann musst du an der Lib selbst nix ändern.
Frag mich ned wie das geht in C(++)
Vielleicht?:
Lib::sendZeug(){
mach mein ding statt deins;
}
Würde meinen du könntest die zuständige Routine der MCP2515 Lib in deinem eigenen Code überladen/überschreiben.
Dann musst du an der Lib selbst nix ändern.
Frag mich ned wie das geht in C(++)
Vielleicht?:
Lib::sendZeug(){
mach mein ding statt deins;
}
Re: Der AVR-/ARDUINO-Faden
Also könnte ich schlecht schreiben: Adriano mach was ich will!. Hätte ichAuch selber drauf kommen können.ch_ris hat geschrieben: ↑Mi 28. Dez 2022, 08:38 Keine Ahnung.
Würde meinen du könntest die zuständige Routine der MCP2515 Lib in deinem eigenen Code überladen/überschreiben.
Dann musst du an der Lib selbst nix ändern.
Frag mich ned wie das geht in C(++)
Vielleicht?:
Lib::sendZeug(){
mach mein ding statt deins;
}
Re: Der AVR-/ARDUINO-Faden
Hä? versteh ich nich, egal...
welche Lib benutzt du? ich hab hier 3 zur Auswahl.
welche Lib benutzt du? ich hab hier 3 zur Auswahl.
Re: Der AVR-/ARDUINO-Faden
Ich benutze diese Lib:
https://github.com/atc1441/arduino-mcp2515
Damit spreche ich mit dem Conti Akku.
Jedoch hab ich 20 Akkus und die Akkus haben alle die gleiche CAN-ID so das ich 20x den MCP2515 habe und dessen CS per PCF portexpander bedienen muss.
https://github.com/atc1441/arduino-mcp2515
Damit spreche ich mit dem Conti Akku.
Jedoch hab ich 20 Akkus und die Akkus haben alle die gleiche CAN-ID so das ich 20x den MCP2515 habe und dessen CS per PCF portexpander bedienen muss.
- Alexander470815
- Beiträge: 2385
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
Ich habe so eine Problemstellung mal umgangen indem ich den CS Pin einfach mit einem Analog Multiplexer umgeschaltet habe
Das ganze in Software lösen ist natürlich eleganter.
Das ganze in Software lösen ist natürlich eleganter.
Re: Der AVR-/ARDUINO-Faden
Die benutzt SPI, der expander I2C.
kann man das einfach so mischen in dem Zusammenhang?
(ich nix weiss)
Ich nehme an die Adresse vom Akku ändern geht nicht.
Reicht der Speicher für 20 Can Objekte? oder willst das jedes Mal neu initialisieren?
von Seeed gibts I2C Can Module. Ob das besser wäre?
noch mal pseudo code:
PCF8574 *ex[8];
int addr[8] = {0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27};
for(int i = 0;i < 8;i++) ex = new PCF8574(addr);
CanDings.init(*ex[7]);
sorry, leider nur Fragen keine Antworten.
oder, (wie@Alexander sacht) du brauchst doch nur ein paar oder einen CanDing wenn du dahinter expanderst?
kann man das einfach so mischen in dem Zusammenhang?
(ich nix weiss)
Ich nehme an die Adresse vom Akku ändern geht nicht.
Reicht der Speicher für 20 Can Objekte? oder willst das jedes Mal neu initialisieren?
von Seeed gibts I2C Can Module. Ob das besser wäre?
noch mal pseudo code:
PCF8574 *ex[8];
int addr[8] = {0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27};
for(int i = 0;i < 8;i++) ex = new PCF8574(addr);
CanDings.init(*ex[7]);
sorry, leider nur Fragen keine Antworten.
oder, (wie@Alexander sacht) du brauchst doch nur ein paar oder einen CanDing wenn du dahinter expanderst?
Re: Der AVR-/ARDUINO-Faden
@Hightech
Du kannst die 3 wichtigen Dateien (can.h, mcp2515.cpp und mcp2515.h) aus der Library in deinen Arduino Sketch Ordner kopieren und am besten noch den Namen ändern (von den Dateien aber auch der library selber, also überall wo "MCP2515" vorkommt zu etwas eigenem Ändern, dann gibt es keine Kollision mit der "richtigen" lib das inlcude in der .h natürlich auch zu dem eigenen) dann kannst du die lib direkt editieren und das eigenen CS verhalten einfügen.
Am einfachsten wäre es ein Callback für das CS in der lib zu machen, sprich jedes mall wenn ein startSPI oder stopSPI aufgerufen wird wird eine Funktion im Main Sketch aufgerufen
Dann braucht es nur eine CAN Instanz
Du kannst die 3 wichtigen Dateien (can.h, mcp2515.cpp und mcp2515.h) aus der Library in deinen Arduino Sketch Ordner kopieren und am besten noch den Namen ändern (von den Dateien aber auch der library selber, also überall wo "MCP2515" vorkommt zu etwas eigenem Ändern, dann gibt es keine Kollision mit der "richtigen" lib das inlcude in der .h natürlich auch zu dem eigenen) dann kannst du die lib direkt editieren und das eigenen CS verhalten einfügen.
Am einfachsten wäre es ein Callback für das CS in der lib zu machen, sprich jedes mall wenn ein startSPI oder stopSPI aufgerufen wird wird eine Funktion im Main Sketch aufgerufen
Dann braucht es nur eine CAN Instanz
Re: Der AVR-/ARDUINO-Faden
Ich hab den Punkt in der Lib nicht gefunden, an der der CS bedient wird,
Man übergibt der mcp2515(cs-Pin) ich sehe nur nicht, wo das am Ende landet, dort würde ich das dann über den I2C Expander umbiegen.
Man übergibt der mcp2515(cs-Pin) ich sehe nur nicht, wo das am Ende landet, dort würde ich das dann über den I2C Expander umbiegen.
Re: Der AVR-/ARDUINO-Faden
Hier:
mcp2515.cpp
void MCP2515::startSPI() {
SPIn->beginTransaction(SPISettings(SPI_CLOCK, MSBFIRST, SPI_MODE0));
digitalWrite(SPICS, LOW);
}
void MCP2515::endSPI() {
digitalWrite(SPICS, HIGH);
SPIn->endTransaction();
}
mfg herb
mcp2515.cpp
void MCP2515::startSPI() {
SPIn->beginTransaction(SPISettings(SPI_CLOCK, MSBFIRST, SPI_MODE0));
digitalWrite(SPICS, LOW);
}
void MCP2515::endSPI() {
digitalWrite(SPICS, HIGH);
SPIn->endTransaction();
}
mfg herb
Re: Der AVR-/ARDUINO-Faden
Danke, das hab ich nicht gesehen.
Ich habe die LIB mal um gebogen.
So kann ich mit
MCP2515 mcp2515(0x3E, 3)
machen, das Schreiben klappt schon mal, aber lesen tut es nicht ... komisch
Der Akku bleibt an, weil der die Befehle empfängt, aber die gesendeten Daten kann ich nicht einlesen.
Ich habe die LIB mal um gebogen.
So kann ich mit
MCP2515 mcp2515(0x3E, 3)
machen, das Schreiben klappt schon mal, aber lesen tut es nicht ... komisch
Der Akku bleibt an, weil der die Befehle empfängt, aber die gesendeten Daten kann ich nicht einlesen.
Code: Alles auswählen
MCP2515::MCP2515(const uint8_t _CsAddr, const uint8_t _CS)
{
SPI.begin();
SPICS = _CS;
CsAddr= _CsAddr;
PCF8574(CsAddr).begin();
endSPI();
}
void MCP2515::startSPI() {
SPI.beginTransaction(SPISettings(SPI_CLOCK, MSBFIRST, SPI_MODE0));
PCF8574(CsAddr).write(SPICS, 0);
}
void MCP2515::endSPI() {
PCF8574(CsAddr).write(SPICS, 1);
SPI.endTransaction();
}
Re: Der AVR-/ARDUINO-Faden
UUUNd der nächste Fuck, bittschön:
Der PCF8574 macht beim schalten von Pin x an jeder Flanke einen Peak auf Pin y.
Watt soll dat denn??
Muss ich da was blocken?
Der PCF8574 macht beim schalten von Pin x an jeder Flanke einen Peak auf Pin y.
Watt soll dat denn??
Muss ich da was blocken?
Re: Der AVR-/ARDUINO-Faden
Wäre mir neu.
Sind die Ausgänge auch richtig verschaltet?
Es sind nämlich nur OC-Ausgänge die nur Masse schalten können. VCC ist nur eine Stromquelle die ein paar uA liefert.
Was passiert ist das der Interrupt-Ausgang auch beim setzen der Ausgänge schaltet, das muss man per Software lösen.
Edit meint: Abblockkondensator vergessen?
Grüße Jan
Zuletzt geändert von Jannyboy am Fr 30. Dez 2022, 23:41, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
So sieht das aus:
Re: Der AVR-/ARDUINO-Faden
Sieht fast nach POR-Reset aus.
Ich betreibe die Tierchen unter mit 4.7u + 100n an der Versorgung.
Grüße Jan
Ich betreibe die Tierchen unter mit 4.7u + 100n an der Versorgung.
Grüße Jan
- Bastelbruder
- Beiträge: 11544
- Registriert: Mi 14. Aug 2013, 18:28
Re: Der AVR-/ARDUINO-Faden
Das stimmt nicht ganz.Es sind nämlich nur OC-Ausgänge die nur Masse schalten können. VCC ist nur eine Stromquelle die ein paar uA liefert.
Die Ausgänge haben zwar bloß einen schwachen Highside-Treiber, aaber es gibt da noch einen Transistor der die Flanke während des internen write-Impulses (SCL-Low-Phase während SDA-slave-ack) hart high zieht.
Das Oszillogramm sieht aber eher danach aus als hätte der Compiler zwei unmittelbar aufeinander folgende Schreibvorgänge produziert. Erst werden alle Ausgänge "off" (=high) gesetzt und mit dem zweiten Schreiben der gewünschte Ausgang gesetzt.
Etwas mehr Zoom und gleichzeitig SCL mit auf dem Schirm könnten das bestätigen.
Zuletzt geändert von Bastelbruder am Sa 31. Dez 2022, 12:28, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
Nur die Zeit ist dafür zu kurz.
Man benötigt 2 Byte, also 18Bit auf den I2C-Bus + Start- und Stop-Bedingung.
Also grob 190 uSec bei 100 kHz Busfrequenz. Das waren auf dem Bild ungefähr eine Div.
EDIT: Ich habe es gerade in einer sauberen Schaltung nach gemessen.
Da ist am Oszi nicht die leiseste Zuckung zu sehen.
Entrweder hasst du es mit Signalübersprechen zutun oder dein C ist richtig dimensioniert (siehe Oben)?
Grüße Jan
Man benötigt 2 Byte, also 18Bit auf den I2C-Bus + Start- und Stop-Bedingung.
Also grob 190 uSec bei 100 kHz Busfrequenz. Das waren auf dem Bild ungefähr eine Div.
EDIT: Ich habe es gerade in einer sauberen Schaltung nach gemessen.
Da ist am Oszi nicht die leiseste Zuckung zu sehen.
Entrweder hasst du es mit Signalübersprechen zutun oder dein C ist richtig dimensioniert (siehe Oben)?
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Das ist echt interessant.
Ich habe ein original NXP PCF8574T.
Kanal 1 ist SCL und Kanal 2 ist der Port-Pin.
Der Pin selbst schaltet von High auf Low. Der Nachbar-Pin schaltet von High nach Low, während der Pin selbst auf Low bleibt. Welchen Typ und Hersteller hast du genau?
Edit: Dein Verhalten passt zum TI PCF8574, siehe Dabla Grüße Jan
Ich habe ein original NXP PCF8574T.
Kanal 1 ist SCL und Kanal 2 ist der Port-Pin.
Der Pin selbst schaltet von High auf Low. Der Nachbar-Pin schaltet von High nach Low, während der Pin selbst auf Low bleibt. Welchen Typ und Hersteller hast du genau?
Edit: Dein Verhalten passt zum TI PCF8574, siehe Dabla Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Ich habe einen PCF8574AP von Philips
Re: Der AVR-/ARDUINO-Faden
Der Baustein ist schon lang EOL.
Probiere doch mal zu deinen 100n noch mal 2.2u oder 4.7u hin zuzufügen. Nur um mal auszuschließen das da noch Power-Glitches mit reinspielen.
Kann sich einfach sein das die alten eine alte DIE haben. Ich würde mir sonst mal das passende Dabla zum Datecode holen.
EDIT: Deine Masse ist auch arg dünn angebunden.
Wenn du CS8 nach innen legst kannst du den Masse-PIN direkt mit der GND-Plane verbinden.
Grüße Jan
Probiere doch mal zu deinen 100n noch mal 2.2u oder 4.7u hin zuzufügen. Nur um mal auszuschließen das da noch Power-Glitches mit reinspielen.
Kann sich einfach sein das die alten eine alte DIE haben. Ich würde mir sonst mal das passende Dabla zum Datecode holen.
EDIT: Deine Masse ist auch arg dünn angebunden.
Wenn du CS8 nach innen legst kannst du den Masse-PIN direkt mit der GND-Plane verbinden.
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Leider ändert sich da nichts, auch mit 4,7µF direkt zwischen VCC und GND.
Re: Der AVR-/ARDUINO-Faden
Mal eine andere Frage:
Bei einem solchen Board, kann man da den deep-sleep Modus überhaupt sinnvoll nutzen:
https://www.az-delivery.de/collections/ ... pmentboard#
Wenn ich den Chip in den Deep-Sleep schicke, zieht das Board trotzdem 16mA.
Isso oder? Wegen dem Spannungsregler und dem CP2102.
Bei einem solchen Board, kann man da den deep-sleep Modus überhaupt sinnvoll nutzen:
https://www.az-delivery.de/collections/ ... pmentboard#
Wenn ich den Chip in den Deep-Sleep schicke, zieht das Board trotzdem 16mA.
Isso oder? Wegen dem Spannungsregler und dem CP2102.
Re: Der AVR-/ARDUINO-Faden
Okay dann wird das wohl normal sein bei deiner Revision. Siehe TI Datenblatt -> Invalid data.
Da hilft dann nur einen aktuellen Chip zu verwenden oder RC-Glieder nach den Port-Pins, die die Spikes weg bügeln.
Der Deep-Sleep macht nur Sinn wenn du das nackte ESP32-Modul an einer 3V-Lithium Batterie oder eine Spannungsregler wie MCP1702.
Hier muss dann auch mit 2 Reglern gefahren werden.
Einmal der MCP und dann muss man erst einen kräftigeren Regler zuschalten bevor man das Wifi aktiviert.
Ich verwende immer den Light-Sleep Mode mit einem LF33CV oder LM1117-3.3. Das ist dann meistens auch ein Bleiaquarium mit dran.
Der Deep-sleep hat auch so seine Tücken.
Die MCU kann in einigen Silizium Revision durch Power-Glitches stehen bleiben. Und wacht da nie mehr auf. Da hilft dann nur noch der Reset.
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Ich versuche über I2C Daten von einem AHT10 Sensor mit einem Arduino Nano zu lesen.
Ich habe schon ein paar andere Module zum Laufen bekommen, ein SPI Display auf das ich Daten Schreiben konnte, einen PWM gesteuerten Motorcontroller für 220V Motoren, ein Lichtschrankenmodul, und ich habe auch eine LED Blinken lassen. Bin aber sonst was Arduinos angeht noch recht grün und hab auch elektrotechnisch nur oberflächlich Ahnung.
Sensor scheint optisch baugleich mit diversen anderen Anbietern von AHT10 Modulen: https://www.aliexpress.com/item/1005001722606573.html
Die Pins sind wie folgt Verbunden:
AHT10 - Arduino
GND - GND
VIN - 5V
SDA - A4
SCL - A5
Ich habe zuerst die Code Sketch von hier probiert, und auch vorher die Libary importiert: https://elektro.turanis.de/html/prj349/index.html
Da kommt zunächst eine Fehlermeldung das der Init gescheitert ist. Wenn ich die Adresse auf 0x39 ändere kommen auf dem Serial Monitor in der Arduino IDE dann Fantasiewerte von mehreren 10.000°C und negativ 1.000de % Feuchtigkeit die stark schwanken, egal ob Modul angesteckt oder nicht.
Ich hab dann noch dieses Codebeispiel aus dieser Libary (mit dieser Libary importiert) Verwendet: https://github.com/enjoyneering/AHTxx/b ... Serial.ino
Auf dem Serial Monitor erscheint dann das hier: ������ ��������������������������������������������������������������
Bin ein bisschen ratlos, vielleicht weiß ja hier Jemand woran es liegen könnte oder wie man Diagnostizieren könnte.
Ich habe schon ein paar andere Module zum Laufen bekommen, ein SPI Display auf das ich Daten Schreiben konnte, einen PWM gesteuerten Motorcontroller für 220V Motoren, ein Lichtschrankenmodul, und ich habe auch eine LED Blinken lassen. Bin aber sonst was Arduinos angeht noch recht grün und hab auch elektrotechnisch nur oberflächlich Ahnung.
Sensor scheint optisch baugleich mit diversen anderen Anbietern von AHT10 Modulen: https://www.aliexpress.com/item/1005001722606573.html
Die Pins sind wie folgt Verbunden:
AHT10 - Arduino
GND - GND
VIN - 5V
SDA - A4
SCL - A5
Ich habe zuerst die Code Sketch von hier probiert, und auch vorher die Libary importiert: https://elektro.turanis.de/html/prj349/index.html
Da kommt zunächst eine Fehlermeldung das der Init gescheitert ist. Wenn ich die Adresse auf 0x39 ändere kommen auf dem Serial Monitor in der Arduino IDE dann Fantasiewerte von mehreren 10.000°C und negativ 1.000de % Feuchtigkeit die stark schwanken, egal ob Modul angesteckt oder nicht.
Ich hab dann noch dieses Codebeispiel aus dieser Libary (mit dieser Libary importiert) Verwendet: https://github.com/enjoyneering/AHTxx/b ... Serial.ino
Auf dem Serial Monitor erscheint dann das hier: ������ ��������������������������������������������������������������
Bin ein bisschen ratlos, vielleicht weiß ja hier Jemand woran es liegen könnte oder wie man Diagnostizieren könnte.
- Später Gast
- Beiträge: 1697
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Wenn der Serial Monitor Hieroglyphen anzeigt, ist meist die falsche Baudrate im Sketch/im Monitor eingestellt.
Re: Der AVR-/ARDUINO-Faden
Die Baudrate war das Problem, nun läuft es!
Danke!
Danke!
Re: Der AVR-/ARDUINO-Faden
Oder die Spannung reich nicht.Später Gast hat geschrieben: ↑So 1. Jan 2023, 19:20 Wenn der Serial Monitor Hieroglyphen anzeigt, ist meist die falsche Baudrate im Sketch/im Monitor eingestellt.
Re: Der AVR-/ARDUINO-Faden
Ich hab nun einen 100n am Ausgang. das reicht nicht...
Ich muss wohl mal neue Kaufen.
- Bastelbruder
- Beiträge: 11544
- Registriert: Mi 14. Aug 2013, 18:28
Re: Der AVR-/ARDUINO-Faden
Die Bilder sind besser als aus dem Lehrbuch, man erkennt daß die Weichware alles richtig macht!
Das falsche high kann mit dem internen "Write Pulse" nach (Zeichning 8.2.2) garnicht erzeugt werden, weil das D-Flipflop schon vorher den Zustand L gespeichert hatte. Die t_pv von max. 4 µs hat mit dem Fehler nichts zu tun, das ist eher die Durchlaufverzögerung. Aber komisch ist diese Angabe im Datenblatt schon.
4 µs ist auch für Standard-CMOS eine lange Zeit.
Ich hätte jetzt erstmal andere Hersteller durchprobiert.
Den "Glitch" auszublenden geht sauber bloß mit einer Diode, die nur den "Open Drain" durchläßt.
Ein Serienwiderstand mit zusätzlicher Lastkapazität macht m.E. keinen Sinn.
Das falsche high kann mit dem internen "Write Pulse" nach (Zeichning 8.2.2) garnicht erzeugt werden, weil das D-Flipflop schon vorher den Zustand L gespeichert hatte. Die t_pv von max. 4 µs hat mit dem Fehler nichts zu tun, das ist eher die Durchlaufverzögerung. Aber komisch ist diese Angabe im Datenblatt schon.
4 µs ist auch für Standard-CMOS eine lange Zeit.
Ich hätte jetzt erstmal andere Hersteller durchprobiert.
Den "Glitch" auszublenden geht sauber bloß mit einer Diode, die nur den "Open Drain" durchläßt.
Ein Serienwiderstand mit zusätzlicher Lastkapazität macht m.E. keinen Sinn.
Re: Der AVR-/ARDUINO-Faden
Das ist in der Tat interessant
Hast du die mal nackt auf den Steckbrett probiert?
Gleiche Verhalten?
Und mal welche von NXP probiert?
Ich denke langsam das ist m.E. ein TI spezifisches Verhalten. Was auffällt ist das der Spike und der ACK Impuls genau gleich lang sind. Zudem fehlt die Passage "Invalid data" im NXP Datenblatt.
Grüße Jan
Hast du die mal nackt auf den Steckbrett probiert?
Gleiche Verhalten?
Und mal welche von NXP probiert?
Ich denke langsam das ist m.E. ein TI spezifisches Verhalten. Was auffällt ist das der Spike und der ACK Impuls genau gleich lang sind. Zudem fehlt die Passage "Invalid data" im NXP Datenblatt.
Grüße Jan
Zuletzt geändert von Jannyboy am Mi 4. Jan 2023, 01:31, insgesamt 1-mal geändert.
Re: Der AVR-/ARDUINO-Faden
Hat doch direkt mit den Daten zu tun(Daten low, Clock low-> switch), also kein Spike.
Edith:kein zusammenhang mit der Ausgabe.
offene Eingänge kann man ausschließen? Is ja bei hoher Eingangsimpendanz relevant.
Programmierung saubär? Was sagt der SPI Datenstring was die cpz tun soll?
Re: Der AVR-/ARDUINO-Faden
Also der nackte IC macht das:
Anscheinend gehen die Ports von selber auf High, wenn ich irgendwelche Befehle Sende
Der D0 wird auf 1 gesetzt
Der D3 sollte eigentlich immer 0 sein
Im Code ist 0 und 3 vertauscht
PCF8574(0x20).begin();
//i2c_datasend(0x26,0,0);
i2c_datasend(0x20,3,0);
while(1==1){
i2c_datasend(0x20,3,0);
i2c_datasend(0x20,0,0);
delay(10);
i2c_datasend(0x20,0,0);
;}
Anscheinend gehen die Ports von selber auf High, wenn ich irgendwelche Befehle Sende
Der D0 wird auf 1 gesetzt
Der D3 sollte eigentlich immer 0 sein
Im Code ist 0 und 3 vertauscht
PCF8574(0x20).begin();
//i2c_datasend(0x26,0,0);
i2c_datasend(0x20,3,0);
while(1==1){
i2c_datasend(0x20,3,0);
i2c_datasend(0x20,0,0);
delay(10);
i2c_datasend(0x20,0,0);
;}
Re: Der AVR-/ARDUINO-Faden
Warum schickst du denn die LOW-Befehle doppelt?
Jetzt sieht es ja so aus wie es sein sollte!?
Grüße Jan
Jetzt sieht es ja so aus wie es sein sollte!?
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Ich sende überhaupt gar kein high Level.
Re: Der AVR-/ARDUINO-Faden
Täuscht micht das oder stimmt das Scopebild oben überhaupt nicht mit dem Codeschnipsel überein? Die gesendete Adresse ist immer gleich, aber das Datenwort ist im Scopebild deutlich abweichend....
Noch eine Frage:
Was macht der dritte Parameter?
Insgesamt hat das Datagram irgendwie nichts mit der Ausgabe der Pins gemein. Kann dein LA auch das Protokoll dekodieren? Und sind die analog gemessenen Pegel auch noch digital?
Noch eine Frage:
Code: Alles auswählen
i2c_datasend(0x20,3,0);
Insgesamt hat das Datagram irgendwie nichts mit der Ausgabe der Pins gemein. Kann dein LA auch das Protokoll dekodieren? Und sind die analog gemessenen Pegel auch noch digital?
Re: Der AVR-/ARDUINO-Faden
Ah, sorry, das Scopebild zeigt noch den alten Code an, dort hatte ich einmal 0x26,3,1 mit reingeschrieben.
Den LOW Befehl sende ich mehrfach, um zu schauen, was beim senden eines Befehls passiert.
Ich denke ich habe eine Ursache gefunden:
Alle Ports sind auf High, wenn der Chip nicht initialisiert ist. Man muss ihn initialisieren und dann erst ein mal alle Ports auf 0 ziehen.
In der i2cdatasend(addr, pin, state) wird aber mit
if (!PCF8574(addr).begin)
{
Serial.print("init fail");
PCF8574(addr).begin;
}
nicht nur gefragt, ob der Chip initialisiert wurde, sonder direkt in der Abfrage der Init bei if (!PCF8574(addr).begin)) neu initialisiert.
Bei jedem benutzen der i2cdatasend.
Da gehen dann alle Pins wieder auf High
Das ist für die Ansteuerung des CS-Pins des MCP2515 egal, der arbeitet ja eh als invertierter Eingang, aber der ULN2308 arbeitet mit Highlevel.
So hab ich am Ausgang des ULN immer ein Signal, wenn der PCF initialisiert wird.
Das zweite Problem sind heftige Spikes, die muss ich aber noch untersuchen, wo und wann die auftreten.
Den LOW Befehl sende ich mehrfach, um zu schauen, was beim senden eines Befehls passiert.
Ich denke ich habe eine Ursache gefunden:
Alle Ports sind auf High, wenn der Chip nicht initialisiert ist. Man muss ihn initialisieren und dann erst ein mal alle Ports auf 0 ziehen.
In der i2cdatasend(addr, pin, state) wird aber mit
if (!PCF8574(addr).begin)
{
Serial.print("init fail");
PCF8574(addr).begin;
}
nicht nur gefragt, ob der Chip initialisiert wurde, sonder direkt in der Abfrage der Init bei if (!PCF8574(addr).begin)) neu initialisiert.
Bei jedem benutzen der i2cdatasend.
Da gehen dann alle Pins wieder auf High
Das ist für die Ansteuerung des CS-Pins des MCP2515 egal, der arbeitet ja eh als invertierter Eingang, aber der ULN2308 arbeitet mit Highlevel.
So hab ich am Ausgang des ULN immer ein Signal, wenn der PCF initialisiert wird.
Das zweite Problem sind heftige Spikes, die muss ich aber noch untersuchen, wo und wann die auftreten.
Re: Der AVR-/ARDUINO-Faden
Wäre es nicht einfacher gewesen, hinter dem PCF einen 74HCxx 8 Bit Latch einzubauen und dessen Output Enable mit dem CS für das SPI anzuschalten?
Re: Der AVR-/ARDUINO-Faden
Der ULN macht andere Sachen und hat mit dem CS des SPI nichts zu schaffen.
Re: Der AVR-/ARDUINO-Faden
Wo denn? Auf SDA? Das wäre normal und (bei korrektem Timing) egal. Deshalb fragte ich nach nem LA der das Protokoll dekodieren kann.Das zweite Problem sind heftige Spikes, die muss ich aber noch untersuchen, wo und wann die auftreten.
Re: Der AVR-/ARDUINO-Faden
Okay das Wissen hatte ich als gegeben angenommen, Sorry.
Jetzt verstehe ich langsam wo der Wind her weht.Hightech hat geschrieben: ↑Do 5. Jan 2023, 08:03 Das ist für die Ansteuerung des CS-Pins des MCP2515 egal, der arbeitet ja eh als invertierter Eingang, aber der ULN2308 arbeitet mit Highlevel.
So hab ich am Ausgang des ULN immer ein Signal, wenn der PCF initialisiert wird.
Das zweite Problem sind heftige Spikes, die muss ich aber noch untersuchen, wo und wann die auftreten.
Der PCF8574 ist auch eher als Low-Active LED-/Motor-Driver bzw. zum einlesen von Tastern erdacht worden. Überall wo es billig sein soll. Ich verwende die sehr gerne in Frontpanels von DIN-Rail Gehäuse.
Für deine Anwendung ist ein MCP23017 wohl besser geeignet, das ist ein vollwertiger Port-Expander.
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Irgendwie seltsam.
Kanal 1 ist Pin3
Kanal 4 ist Pin 0
Warum zum Geier geht der immer wieder nach High wenn ich den Pin 3 beschreibe?
void loop()
{
PCF8574(0x26).write(0, 0);
_delay_us(100);
PCF8574(0x26).write(3, 0);
_delay_us(100);
PCF8574(0x26).write(3, 1);
_delay_us(100);
}
0xff sollte dann auch alle Pins auf 0 bedeuten oder?
Kanal 1 ist Pin3
Kanal 4 ist Pin 0
Warum zum Geier geht der immer wieder nach High wenn ich den Pin 3 beschreibe?
void loop()
{
PCF8574(0x26).write(0, 0);
_delay_us(100);
PCF8574(0x26).write(3, 0);
_delay_us(100);
PCF8574(0x26).write(3, 1);
_delay_us(100);
}
0xff sollte dann auch alle Pins auf 0 bedeuten oder?
Re: Der AVR-/ARDUINO-Faden
Kann das mit der Art zu tun haben wie die PCF-lib das schreibt?
Code: Alles auswählen
void PCF8574::write(const uint8_t pin, const uint8_t value)
{
if (pin > 7)
{
_error = PCF8574_PIN_ERROR;
return;
}
if (value == LOW)
{
_dataOut &= ~(1 << pin);
}
else
{
_dataOut |= (1 << pin);
}
write8(_dataOut);
}
void PCF8574::write8(const uint8_t value)
{
_dataOut = value;
_wire->beginTransmission(_address);
_wire->write(_dataOut);
_error = _wire->endTransmission();
}