Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

:shock: Das werd ich sofort! prüfen. Danke.
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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.
Laufen die abstürzenden auch tatsächlich mit 5V oder nur mit 3,3V?
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

Weisskeinen hat geschrieben: Do 6. Okt 2022, 14:11 Laufen die abstürzenden auch tatsächlich mit 5V oder nur mit 3,3V?
5V, da Arduino Nano Standard Board direkt mit 5V gespeist aus einem 7805.
Zusätzliche Abblockkondensatoren bringen keine Veränderung.
Habe auch nochmal direkt an den Pins nachgemessen, bekommt auch die 5V.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

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.
Zuletzt geändert von ch_ris am Fr 21. Okt 2022, 06:36, insgesamt 2-mal geändert.
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

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.
Benutzeravatar
Toni
Beiträge: 2523
Registriert: Di 13. Aug 2013, 18:24

Re: Der AVR-/ARDUINO-Faden

Beitrag von Toni »

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

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    
ich komme leider nicht alleine drauf :cry: 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:

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
;------------------------------------------------------------------------

das bastele ich mal rein, und teste es
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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);
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

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;
}
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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;
}
Also könnte ich schlecht schreiben: Adriano mach was ich will!. Hätte ichAuch selber drauf kommen können.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Hä? versteh ich nich, egal...
welche Lib benutzt du? ich hab hier 3 zur Auswahl.
2022-12-30 07_49_18-Window.png
2022-12-30 07_49_18-Window.png (6.87 KiB) 947 mal betrachtet
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Benutzeravatar
Alexander470815
Beiträge: 2371
Registriert: So 11. Aug 2013, 15:42
Wohnort: D:\Hessen\Gießen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Alexander470815 »

Ich habe so eine Problemstellung mal umgangen indem ich den CS Pin einfach mit einem Analog Multiplexer umgeschaltet habe :lol:
Das ganze in Software lösen ist natürlich eleganter.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

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?
Lokaro
Beiträge: 16
Registriert: So 20. Nov 2022, 23:18

Re: Der AVR-/ARDUINO-Faden

Beitrag von Lokaro »

@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
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
he25rb
Beiträge: 35
Registriert: So 4. Dez 2016, 14:18

Re: Der AVR-/ARDUINO-Faden

Beitrag von he25rb »

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
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.


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();
}
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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?
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Hightech hat geschrieben: Fr 30. Dez 2022, 23:29 Muss ich da was blocken?
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.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

So sieht das aus:
SDS00001.png
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Sieht fast nach POR-Reset aus.

Ich betreibe die Tierchen unter mit 4.7u + 100n an der Versorgung.

Grüße Jan
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

Es sind nämlich nur OC-Ausgänge die nur Masse schalten können. VCC ist nur eine Stromquelle die ein paar uA liefert.
Das stimmt nicht ganz.

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.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

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
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Ich hab mal was zum schauen gemacht:
Kanal 1 ist der Pin3 den ich schalte
Kanal 3 ist Pin0, der soll aus sein.
Kanal2 SCL
Kanal 4 Data
Bild
Bild
Bild
Bild
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

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.
scope_0.png
Der Nachbar-Pin schaltet von High nach Low, während der Pin selbst auf Low bleibt.
scope_1.png
Welchen Typ und Hersteller hast du genau?

Edit: Dein Verhalten passt zum TI PCF8574, siehe Dabla
Bildschirmfoto vom 2022-12-31 14-08-35.png
Grüße Jan
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Ich habe einen PCF8574AP von Philips
Bildschirmfoto zu 2022-12-31 14-26-52.png
Bildschirmfoto zu 2022-12-31 14-28-33.png
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

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.
Bildschirmfoto vom 2022-12-31 14-51-12.png
Bildschirmfoto vom 2022-12-31 14-52-10.png
Grüße Jan
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Leider ändert sich da nichts, auch mit 4,7µF direkt zwischen VCC und GND.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Hightech hat geschrieben: Sa 31. Dez 2022, 21:03 Leider ändert sich da nichts, auch mit 4,7µF direkt zwischen VCC und GND.
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.
Hightech hat geschrieben: Sa 31. Dez 2022, 22:23 Mal eine andere Frage:
Bei einem solchen Board, kann man da den deep-sleep Modus überhaupt sinnvoll nutzen:
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
jay
Beiträge: 55
Registriert: Di 20. Sep 2022, 12:45

Re: Der AVR-/ARDUINO-Faden

Beitrag von jay »

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.
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Wenn der Serial Monitor Hieroglyphen anzeigt, ist meist die falsche Baudrate im Sketch/im Monitor eingestellt.
jay
Beiträge: 55
Registriert: Di 20. Sep 2022, 12:45

Re: Der AVR-/ARDUINO-Faden

Beitrag von jay »

Die Baudrate war das Problem, nun läuft es!

Danke!
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Oder die Spannung reich nicht.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Jannyboy hat geschrieben: So 1. Jan 2023, 00:06
Hightech hat geschrieben: Sa 31. Dez 2022, 21:03 Leider ändert sich da nichts, auch mit 4,7µF direkt zwischen VCC und GND.
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.


Grüße Jan
Ich hab nun einen 100n am Ausgang. das reicht nicht...
Ich muss wohl mal neue Kaufen.
Benutzeravatar
Bastelbruder
Beiträge: 11481
Registriert: Mi 14. Aug 2013, 18:28

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bastelbruder »

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.
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Jannyboy hat geschrieben: Sa 31. Dez 2022, 15:42 Kann sich einfach sein das die alten eine alte DIE haben. Ich würde mir sonst mal das passende Dabla zum Datecode holen.
Ich hab heute mal neu Bausteine von TI gekauft. Ändert auch nicht an der Misere.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Das ist in der Tat interessant :roll:
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.
unlock
Beiträge: 632
Registriert: Sa 31. Dez 2016, 20:21

Re: Der AVR-/ARDUINO-Faden

Beitrag von unlock »

Hightech hat geschrieben: Sa 31. Dez 2022, 14:32 Ich hab mal was zum schauen gemacht:
Kanal 1 ist der Pin3 den ich schalte
Kanal 3 ist Pin0, der soll aus sein.
Kanal2 SCL
Kanal 4 Data
Bild
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?
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Also der nackte IC macht das:

Bild

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);



;}
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Warum schickst du denn die LOW-Befehle doppelt?
Jetzt sieht es ja so aus wie es sein sollte!?

Grüße Jan
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Ich sende überhaupt gar kein high Level.
Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

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:

Code: Alles auswählen

i2c_datasend(0x20,3,0);
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?
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

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?
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Der ULN macht andere Sachen und hat mit dem CS des SPI nichts zu schaffen.
Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Das zweite Problem sind heftige Spikes, die muss ich aber noch untersuchen, wo und wann die auftreten.
Wo denn? Auf SDA? Das wäre normal und (bei korrektem Timing) egal. Deshalb fragte ich nach nem LA der das Protokoll dekodieren kann.
Jannyboy
Beiträge: 1406
Registriert: So 11. Aug 2013, 14:49
Wohnort: Kreis Augsburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Jannyboy »

Hightech hat geschrieben: Do 5. Jan 2023, 08:03 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.
Okay das Wissen hatte ich als gegeben angenommen, Sorry.
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.
Jetzt verstehe ich langsam wo der Wind her weht.
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
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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);
}

Bild

0xff sollte dann auch alle Pins auf 0 bedeuten oder?

Bild
Benutzeravatar
Hightech
Beiträge: 11306
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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();
}

Antworten