UART logic analyzer ?

Wat stuur je en wat ontvang je?
Heeft die LA geen UART mode om te decoderen?

ik stuur vanuit een atmega 32,vanuit een array de no: 101 t/m 112
ik ontvang in raspberry pico, de no: 101 t/m 112.

in de logic analyzer zitten decodeer protocollen, daar van is de UART geselecteerd, zie linkse kollom.

de bitjes op de gele lijn komen overeen met de decimale waarde in het groene vlak, dat heb ik gechekt, maar dat lijkt mij ook wel logisch natuurlijk.

[Bericht gewijzigd door trix op zondag 25 augustus 2024 15:02:05 (26%)]

Wat is de sample rate van de logic analyser, en wat is de bitrate van de UART?

sample rate is 50 kHz
baudrate atmega 32 = is 9600

Van de uart via RS232 zijn de bitjes geinverteerd tegenover serial TTL. Heb je dat toevallig net verkeerd staan?

vergeten te vermelden:
als ik vanuit de raspberry pico over de UART data verstuur, dan komt wel de juiste code op mijn logic analyzer, maar andersom niet

Protocol analyser goed ingesteld? Mijn ervaring is dat de Lap-C dat wel goed doet.

Van een opgeslagen bestand.

Instellingen van de uart bus

De gele trace van de LA geeft wel de juiste bit-stroom : 0x65, 0x66, 0x67 dus precies wat je zou verwachten.

Maar de decodering lijkt fout te gaan : 153,230,230,243, ...
ofwel 0x99, 0xE6 0xE6, 0xF3. Het lijkt erop dat de decoder te laat begint. De code correspondeert met de gele trace als je het begin van een byte laat samenvallen met de groene markering vlak voor de code.

Dus ik zou het zoeken in de instellingen van de LA decoder.

Trigger van je gele data stream staat op stijgen, deze zou juist dalen moeten zijn.
Misschien de oorzaak dat hij te laat begint met decoderen.

Op zondag 25 augustus 2024 15:49:21 schreef trix:
sample rate is 50 kHz
baudrate atmega 32 = is 9600

Welk kristal gebruik je? Houdt er rekening mee dat een standaard kristal 8MHz, 16MHz, 20MHz er bij een ATmega voor zorgt dat er een kleine fout zit in de baudrate. Zie hiervoor de datasheet. Gebruik van een zogenaamd communicatie kristal van 14,7456MHz of 18,4320MHz werkt die fout weg. Als ik het goed herinner heb ik die fout ook wel eens vastgesteld met de Lap-C. De baudrate op auto loste dan het euvel op of net niet, dat herinner ik me niet meer.

de instelling van de UART staan goed, al ga ik dat morgen dubbel checken, ook dacht ik straks te zien dat het bitpatroon op de gele lijn overeen kwam met hetgeen wat in het groene veld word weer gegeven, maar dekees ziet wat anders (en die heeft er meer kijk op ) dus dat ga ik morgen ook nog eens goed bekijken.

als je meerdere bytes (hier 12) achter elkaar verstuurt van uit een atmega 32, is het dan gebruikelijkdat je tussen de bytes een delay verzorgt ? of gaan die meteen achter elkaar de deur uit ?

edit: 8 Mhz externe X-tal. als ik de lengte meet van een verzonden pakketje (1 start 8x data 1 stop bit) wat zou die moeten zijn in het geval 9600 Baud ? die is nu dacht ik iets meer dan 1 mSec. (moet ik morgen ook eens bekijken om het zeker te weten).

als je meerdere bytes (hier 12) achter elkaar verstuurt van uit een atmega 32, is het dan gebruikelijk dat je tussen de bytes een delay verzorgt ? of gaan die meteen achter elkaar de deur uit ?

Je moet beginnen met een pauze zodat de ontvangende uart de start-bit kan herkennen. Maar daarna kun je de bytes zonder pauze versturen.

In arduino omgeving een testprogramma(tje) geschreven. Na elk cijfer zou je een CR moeten krijgen. Fuses dienen correct te staan voor een extern 8MHz kristal.

void setup() {
  Serial.begin(9600);

}

void loop() {
  for(uint8_t cnt = 101; cnt < 113; cnt++){
    Serial.println(cnt);
  }
  delay(1000);
}

Gecompileerde hex in bijlage.

De Baudrate kan je controleren door continue het karakter 'U' te versturen.
Met 1 start en 1 stopbit krijg je een mooie blokgolf.
Met een frequentieteller of scoop kan je dan eenvoudig de snelheid controleren.

de decoder start te laat,
in de printscreen zie je links boven dat de bitreeks mooi tegelijk start met het startbit (data van raspberry pic naar atmega 32)
en rechtsonder komt het startbit te laat. (data van atmega 32 naar raspberry pico)

die linksboven gaat ook wel eens fout mnerk ik nu, maar veel minder vaak.

Baudrate mag max. iets van 3% afwijken...

.

[Bericht gewijzigd door trix op maandag 26 augustus 2024 17:18:41 (99%)]

Ik heb ook wel eens heel rare uitkomsten gehad met een UART decoder. Met een scoop, dat wel.
Bleek te liggen aan de instelling van de threshold en hysteresis: spanningsnivo's dus.

Dat zou ook kunnen verklaren waarom het de ene kant op (RasPi->ATMega) wel goed gedecodeerd wordt en de andere kant op niet.

vandaag nog eens gekeken met de scoop en er vallen me een aantal dingen op:
de situatie:

vervolgens de scoop:
de bovenste (gele) lijn is: atmega32 --> raspberry
de onderste (groene) lijn is: raspberry pico --> atmega 32

bovenste lijn heeft een spanning van ruim 5V -> die gaat met de codering altijd fout.
onderste lijn heeft een spanning van 2V -> die gaat met de codering bijna altijd goed.

die gele lijn gaat bij de 1e flank ook eerst ruim 1V omhoog ?

ik send hier op de bovenste lijn 0b10101010, de eerst "laag" periode heeft 2 bit lengtes ?

ik heb ook nog geprobeerd om in de LA de baudrate op "AUTO" te zetten, maar dat maakte geen verschil.

vooral die verschillenden spanningen begrijp ik niet, en dat die met 2V wel goed codeert en die met 5V niet, waar ik eerder andersom zou verwachten. en vanwaar die verschillen ?
beide probes staan op 1X.

Wel raar dat je niet gelijk in de openingspost vermeld dat je via 2x een max485 werkt. Dan de vraag hoe is dat aangesloten.

Voor de meelezers. De max485 zet het signaal om van serial TTL naar een 4 draads bus.

https://www.alldatasheet.com/datasheet-pdf/view/73493/MAXIM/MAX485.htm…

bovenste lijn heeft een spanning van ruim 5V ->

Niet echt duidelijk wat je ermee bedoelt. Verwijst even naar het schema hierboven op wel pin van de max485 je het precies hebt aangesloten.

Maar even uit de losse pols dan maar. 2V lijkt mij juist niet goed want de uitgang RO van de max485 schakelt tussen laag en hoog. En als de max485V op 5V draait is dat ca 0 en 5V.

Een max485, dus half duplex rs485. Hoe wordt de DIR aangestuurd van de transcievers? Met DIR pin bedoel ik de RE en DE die men meestal aan elkaar legt.
Bias weerstanden toegepast op de bus (indien deze idle komt te staan) om geen valse data te krijgen?
Als ik het goed begrijp zenden de pico en atmega te samen volgens de oscilloscoop?

Bij rs485 problemen begin ik altijd te zoeken met de ene probe op de TX van de transciever, de tweede probe op de A of B pin om te zien of deze de data volgen. Ook de DIR pin controleren, laag is ontvangen, hoog is zenden.
Als 2 transcievers in zend modus staan kan geen betrouwbare communicatie tot stand komen.

ik send hier op de bovenste lijn 0b10101010, de eerst "laag" periode heeft 2 bit lengtes ?

Dat klopt toch? (dat is het startbit)

ik dacht dat die 1 bit lang was.
startbit is "0" en stopbit is "1".

(ik moet de rest nog goed doorlezen)

Als ik het goed begrijp zenden de pico en atmega
 te samen volgens de oscilloscoop?

nee die 2 lijnen is met een handigheidje op 1 beeld gezet, ze liggen in werkelijkheid verder uit elkaar.