UART logic analyzer ?

Het startbit is inderdaad 1 bittijd lang, maar het wordt direct gevolgd door het least significant bit van de data. Zo te zien is dat de letter U (binair 01010101).
Omdat de data op een 232-lijn altijd geinverteerd is (0=H, 1=L) en het startbit altijd een 1 is (L) zie je een start van 2 bittijden.
Het vereist enige oefening om vanaf een scoopbeeld de data te lezen omdat die data 1) geinverteerd en 2) achterstevoren staat.

word er in ieder geval niet duidelijker op.

Kun je schematisch tekenen hoe de max 485's er tussen hangen?
Hangen grounds van pi en mega 32 aan elkaar?
Hoe zijn de max 485s gevoed aan beide kahten van de lijn?
Gebruik je voor rx en tx 1 max485 die je dmv de dir lijn steeds in ontvangst of transmissie zet?
Spanningen zijn inderdaad vreemd.

Met een max(3)485 ertussen hoeven de GND en +5V niet aan elkaar te hangen. A aan A en B aan B. Dat is net het voordeel dat je geen GND-loop kan krijgen. Bij 3V3 heb je een MAX3485 nodig.

Op dinsdag 27 augustus 2024 22:17:15 schreef trix:
word er in ieder geval niet duidelijker op.

Je maakt het ons enorm moeilijk aangezien je geen schema's maakt, dat is één van de grootste fouten die je kunt maken in een project.

Ik begrijp ook niet waarom je een LA gebruikt om RS232 signalen te controleren, ik gebruik altijd een andere PIC(Atmega in uw geval) in een testopstelling.

Eerst maken dat de RS232 werkt vooraleer er RS485 of andere modules tussen te plaatsen, je verliest er heel veel tijd mee als er iets fout is.

RS485 sniffer er tussen en probleem opgelost. Je kan dan gemakkelijk alles volgen in een serial monitor zoals Putty of Arduino monitor. Je ziet dan ook wat aan beide kanten wordt verzonden.

Op woensdag 28 augustus 2024 08:13:23 schreef MGP:
[...]
Ik begrijp ook niet waarom je een LA gebruikt om RS232 signalen te controleren, ik gebruik altijd een andere PIC(Atmega in uw geval) in een testopstelling.

die heb ik gebruikt omdat ik een probleem had met het versturen van een 0 die werd niet geprint in de "shell" van thonny, dus ik wou kijken of die daadwerkelijk werd verstuurt vanuit de atmega 32, en toen zag ik wat vreemde dingen.

Als ik het goed begrijp kan de Atmega ontvanger de Atmega zender pin to pin niet 'verstaan', dus geen RS485 modules ertussen, dan heb je een nog groter probleem.

Misschien kan ik een testprogramma schrijven in een andere taal, dan kun je zien of het aan de code ligt of de hardware.
Je moet mij dan wel zeggen wat je wenst, ik maak dan een hexfile zonder configbits want volgens mij moet je die invullen voor het programmeren, ik heb ik geen ervaring met AVR's en de programmeertaal LDmicro compileert voor zowel PIC's als AVR's.

Het staat u volledig vrij.

Op woensdag 28 augustus 2024 18:11:04 schreef MGP:
Als ik het goed begrijp kan de Atmega ontvanger de Atmega zender pin to pin niet 'verstaan', dus geen RS485 modules ertussen, dan heb je een nog groter probleem.

ik denk dat je bedoeld de TX en de RX pin van de atmega 32 aan elkaar, dat heb ik helemaal nog niet getest.

ik ga morgen de logic analyzer direct aan de atmega hangen (TX & RX) dan weet ik dus of de MAX 485 roet in het eten gooit.

Op woensdag 28 augustus 2024 19:08:13 schreef trix:
[...]
ik denk dat je bedoeld de TX en de RX pin van de atmega 32 aan elkaar, dat heb ik helemaal nog niet getest.
...

Nee, 2 Atmega's, één die zend en de andere ontvangt zonder iets tussen, aan de ontvanger kun je dan bv. 8leds aan een poort hangen en de ontvangen byte op de leds tonen.

dat heb ik ook niet getest, maar afhankelijk van het resultaat van de test morgen (LA direct op de atmega), is dat mischien ook niet nodig.

Wat ook nuttig is om te weten is dat de roemruchte RS485 driver chipjes een maximale common-mode spanning hebben, zeg maar het verschil tussen de twee GNDs.
Een verschil kan heel makkelijk ontstaan als er twee verschillende voedingsapparaten/adapters gebruikt worden...
In zo'n geval kun je beter de GNDs via een 100Ω weerstandje aan elkaar knopen.

Die maximale common-mode spanning verschilt overigens per type en per fabrikant, dus altijd de datasheet raadplegen.

Heb je al eens geprobeerd om beide uarts gewoon op TTL niveau aan elkaar te verbinden? Waarschijnlijk heb je dan wel een level shifter nodig gezien je mega32 5V doet en de pi 3,3 vermoed ik. Al zou denk ik een klein weerstands delertje in de 5V tx van de atmega naar de pi genoeg moeten zijn. Die atmega slikt denk ik wel gewoon 3,3v ttl op zijn RX.

Heb je niet een TTL naar usb kabel (zo'n ftdi ding of equivalent)
Dan kun je simpel weg kijken of je atmega gewoon zend wat hij moet doen.
Ik kan me niet herinneren dat ik daar ooit moeite mee hebt gehad, of rare fratsen heb moeten doen.

Je stelt je uart peripheral in, baudrate (passende bij je clock frequentie), 8N1. En dan schrijft je gewoon in het UDR register. Die byte komt er dan uit. Je chceck wanneer de TX complete of het dataregister empty bitje is gezet en dan schrijf je de volgende byte erin. Al die delays er tussen is helemaal nergens voor nodig en maakt het voor je LA alleen maar lastiger zou ik denken.

Hier heb je 2 programma's in hex.
2 Atmega32's op 8MHz, 9600b

De Atmega zender zendt elke 0.5 sec een byte uit, de binaire optelling van 0 tot 255, dan heb je alle bits gezien.
Dit programma kun je zonder aanpassingen in uw systeem programmeren, alle hardware mag blijven, enkel de TX pin wordt gebruikt.

De Atmega ontvanger toont die byte op #PORTB ... willekeurig gekozen.
Je kunt de ontvanger ook gebruiken met uw opstelling.

Als je aanpassingen wilt zeg het maar, het is <10min werk ... je bent er vrij van want ik wil niet opdringerig overkomen.

[Bericht gewijzigd door MGP op (13%)]

ik ga dat van MGP en stijnos morgen eens testen, kom er vandaag niet meer aan toe.
bedankt voor de input.

de decodering op de logic analyzer werkt, wat was het geval :o
vanuit de atmega stuurde ik 9-bits formaat an de LA stond op 8 bits formaat |:(
nu word ook de 0 in de shell van thonny geprint, man man man, wat kan een mens soms dom zijn.
positief zien te benaderen, het was wel leerzaam :)

edit: vandaar ook de ene kant op wel goed, en de andere kant op niet.

[Bericht gewijzigd door trix op (11%)]

Wordt 9 bits nog wel ergens gebruikt? (ik heb het al hééél lang niet meer meegemaakt...)

bij mij dus ;)
het kan ook in combinatie met de MPCM (Multi-processor Communication mode) bit worden gebruikt, al weet ik niet wat die MCPM precies doet.

Bij MPCM zitten er meerdere processors op de bus. Een ontvanger reageert dan alleen als een bericht met het juiste adres begint. En zo een adres wordt dan gemarkeerd door dat 9e bit.

Op vrijdag 30 augustus 2024 15:07:52 schreef deKees:
Een ontvanger reageert dan alleen als een bericht met het juiste adres begint.

dat is toch altijd al zo ?
ik gebruik straks iets van 24 stuks (10 om te testen) ontvangers op de bus, ik stuur (ben ik van plan) een adres op de bus, en ik ga er van uit dat alleen die met het juist adres "luistert" en de verdere instructies volgt.

Meestal is er ook een broadcast adres waarop alles moet 'reageren'. Reageren niet in de vorm van een reactie sturen maar bijvoorbeeld kleppen sluiten.

Je kan het maken zoals je wil. Ik verstuur tussen master (esp32) en 9 nodes (ATmega644) alles in JSON formaat via RS485. Elke node is een adres ingesteld in BCD formaat. Met 2 schakelaars in te stellen.
Broadcast bijvoorbeeld het correcte uur (om een RTC juist te zetten bij een ATmega644).

{"Adres":255 ,"Jaar":24,"Maand":08,"DagVanMaand":30,"Uur":16,"Minuten":41,"Seconden":00}

Toestand van een node opvragen.

{"Adres":1, "Status":"?"}

Antwoord:

{"Adres":1, "Status":"Alive", "Pomp":"Aan", "Klep":"Toe", "WaterFlowIn": 2980, "RtcTemperatuur": 20.5}

Je kan je ook eens verdiepen in een protocol dat bij modeltreinen wordt gebruikt. Bijvoorbeeld DCC. De signaalniveaus moet je geen zorgen om maken. Dat is niet van toepassing. Wel het aansturen van periferie met adres en toestand van meerdere uitgangen. Beide zijn een 2 draad bus.

Niet alle berichten beginnen met een adres. Dat hangt af van het protocol dat je gebruikt. Een uart wordt meestal gebruikt voor een point-to-point verbinding. Geen adressen nodig.

Het 9e bit kun je gebruiken om een adres-byte te markeren. De ontvanger kan dan de uart zo instellen dat alleen de adressen binnenkomen. Aan de hand van het adres kan de ontvanger dan besluiten of de uart al dan niet moet worden omgezet om ook de rest van het bericht te ontvangen.

Je gebruikt nu de Uart en dat is eigenlijk enkel een seriele hardware verbinding. Hoe je de verbinding gaat gebruiken word dan een protocol genoemd.
Als je dan adressering wilt gebruiken dan kan je daar bv je eigen protocol voor gebruiken of kijken of er al iemand daarvoor iets gemaakt heeft wat je kan gebruiken. Maar de rest wat je aan die bus hangt moet dan ook via dat protocol gaan werken.

Een protocol klinkt heel erg ingewikkeld maar hoeft dat zeker niet te zijn zie het voorbeeld hierboven van buckfast_beekeeper. Maar het gaat me er even om dat je weet dat de UArt en een protocol 2 verschillende dingen zijn.

Kan je dan niet beter I2C gebruiken dat werkt al met adressering maar heeft als nadeel de beperkt lengte van de bus wat toch maximaal 1 meter is bij lage snelheid

Bij standaard snelheid (100kHz) haal je makkelijk 5m met i2c, mits goede kabel en pull-ups gebruikt...
(met een extender als de P82B715 haal je zelfs nog veel meer (tot 1 mijl op lagere snelheid is mogelijk)

Op vrijdag 30 augustus 2024 20:00:26 schreef deKees:
Niet alle berichten beginnen met een adres. Dat hangt af van het protocol dat je gebruikt. Een uart wordt meestal gebruikt voor een point-to-point verbinding. Geen adressen nodig.

Het 9e bit kun je gebruiken om een adres-byte te markeren. De ontvanger kan dan de uart zo instellen dat alleen de adressen binnenkomen. Aan de hand van het adres kan de ontvanger dan besluiten of de uart al dan niet moet worden omgezet om ook de rest van het bericht te ontvangen.

Als je het eng bekijkt is je point to point de UART <=> MAX(3)485. De MAX485 heeft een blokgolf nodig die de info bevat. Hoe de baudrate eruit ziet, dat maakt niet uit. Je kan een eigen baudrate verzinnen en als alles die baudrate volgt, dan is dat OK. RS485/RS422 (2-weg RS485) is dan weer een seriele dataoverdracht die niet point to point beperkt is. In de eerste standaard waren er een beperkt aantal nodes mogelijk. Iets van 16 als ik me niet vergis. Later is dat uitgebreid.

Wat je verstuurt kan je inderdaad zelf bedenken. Je kan ook een bestaand protocol gebruiken zoals modbus. Standaard is alles op de bus in de ontvangst mode. Er mag ook altijd maar 1 tegelijk zenden. Ook al gebruik je RS422, dan nog mag er maar 1 tegelijk gaan zenden.

Goedkope twisted pair is meestal wel voldoende om RS485 storingvrij te gebruiken. Ik gebruik 38400Bd. Meer dan snel genoeg voor mijn doeleinde. Binnen 1 seconde worden er zo 7 nodes opgevraagd die elk antwoorden. 57 600Bd bleek niet echt voor snelheidswinst te zorgen. Er is sowieso een kleine delay na het omschakelen tussen ontvangen en zenden en vice versa.