Seite 28 von 31

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 5. Okt 2022, 07:09
von ch_ris
:shock: Das werd ich sofort! prüfen. Danke.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 6. Okt 2022, 14:11
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 6. Okt 2022, 21:02
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 21. Okt 2022, 06:29
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 21. Okt 2022, 06:35
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 17. Dez 2022, 17:22
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 27. Dez 2022, 13:59
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);

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 28. Dez 2022, 08:38
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;
}

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 28. Dez 2022, 10:16
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 08:51
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) 1196 mal betrachtet

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 09:17
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 09:48
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 10:08
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 10:31
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 13:56
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 14:49
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 22:02
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();
}

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 23:29
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 23:40
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 23:41
von Hightech
So sieht das aus:
SDS00001.png

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 30. Dez 2022, 23:48
von Jannyboy
Sieht fast nach POR-Reset aus.

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

Grüße Jan

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 12:14
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 12:26
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 14:32
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 15:00
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 15:24
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 15:42
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 21:03
von Hightech
Leider ändert sich da nichts, auch mit 4,7µF direkt zwischen VCC und GND.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Sa 31. Dez 2022, 22:23
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 00:06
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 17:13
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 19:20
von Später Gast
Wenn der Serial Monitor Hieroglyphen anzeigt, ist meist die falsche Baudrate im Sketch/im Monitor eingestellt.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 20:21
von jay
Die Baudrate war das Problem, nun läuft es!

Danke!

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 20:24
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 21:04
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: So 1. Jan 2023, 22:48
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 3. Jan 2023, 21:52
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Di 3. Jan 2023, 23:50
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 4. Jan 2023, 00:32
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 4. Jan 2023, 08:47
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);



;}

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 4. Jan 2023, 09:03
von Jannyboy
Warum schickst du denn die LOW-Befehle doppelt?
Jetzt sieht es ja so aus wie es sein sollte!?

Grüße Jan

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 4. Jan 2023, 09:15
von Hightech
Ich sende überhaupt gar kein high Level.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Mi 4. Jan 2023, 09:28
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 08:03
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 08:08
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?

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 08:25
von Hightech
Der ULN macht andere Sachen und hat mit dem CS des SPI nichts zu schaffen.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 08:27
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.

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 08:29
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Do 5. Jan 2023, 23:56
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

Re: Der AVR-/ARDUINO-Faden

Verfasst: Fr 6. Jan 2023, 00:31
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();
}