buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
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.
MGP
LDmicro user.
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.
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
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.
MGP
LDmicro user.
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.
MGP
LDmicro user.
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.
fatbeard
Honourable Member
Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.
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.
MGP
LDmicro user.
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 
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%)]
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
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.
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
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.
benleentje
Golden Member
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
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
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)
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
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.
Op vrijdag 30 augustus 2024 15:53:35 schreef trix:
[...]
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.
Nee normaliter met een rs485 achtig bus staat iedereen in ontvangst. En krijgt iedereen dus alle berichten. Enkel als het adres in dat bericht aangeeft dat het voor jou is, doe je er wat mee, maar dat moet je zelf allemaal maken.
Het hoeft niet ingewikkeld te zijn.
Zorg dat je bericht begint met een gedefinieerde start (STX). Voeg een adres toe. Optioneel een lengte. Iets van het type commando. En vervolgens de data indien van toepassing. Sluit af met een gedefinieerd eind karakter (ETX)
Ik neem aan dat in jouw systeem de pi de master is en die moet aan al je (scanners denk ik) vragen om hun data. Dan moet de mega32 die een matchen adres heeft. Zijn max485 omschakelen van rx naar tx en dan verstuur je via de uart je bericht volgens je protocolletje.
Op vrijdag 30 augustus 2024 22:16:54 schreef Stijnos:
[...]
Ik neem aan dat in jouw systeem de pi de master is en die moet aan al je (scanners denk ik) vragen om hun data. Dan moet de mega32 die een matchen adres heeft. Zijn max485 omschakelen van rx naar tx en dan verstuur je via de uart je bericht volgens je protocolletje.
klopt helemaal.
ik ga er natuurlijk een beetje vanuit dat iedereen de UART gebruikt zoals ik dat doe, maar dat is natuurlijk niet zo.
kijk hier eens naar.
Ik weet dat je geen arduino doet, maar je kan wel zien wat ze doen. Beetje wat ik hierboven al schetste