avr uart met MAX485: send from slave to master ?

Ik zie 8 bits van 104 us en een stuk 208 us vooraan (startbit+LSB), ook 2 bits dus.
Dus dat zijn 10 bits en aan het einde hebt je nog een stop bit zitten wat je niet ziet = hoog, dus 11 bits.

Begin eens met dat extra 9-ste bitje eruit te slopen (TXB8). Zoals ik al zei gebruikt bijna niemand dat. Dus ook de ontvanger gewoon 8 bits ontvangst zonder parity of gekke dingen.

Verder moet je dit soort dingen gewoon niet pollen maar fatsoenlijk met interrupts oplossen.

Heb je straks genoeg RAM om alles te verwerken? Als je 900 bytes moet ontvangen hou je van die 1KB niet veel meer over. Je moet dit allemaal bufferen namelijk.
Ik zou eerder een STM32 CPU variant gebruiken voor dit soort dingen.

Inderdaad, 208 laag is startbit en bit 0.
Dan 7 keer 104 zijn de volgende bits, afwisselend hoog en laag. Dat maakt de byte vol. Het laatste data bit is hoog.

En dan zou je een hoog verwachten als stopbit, maar in de trace komt dan nog een 104 laag. Die hoort daar niet en resulteert in een framing error aan de andere kant.

Kan komen door een parity instelling, of door een 9e bit, of door te vroeg afschakelen van de transmitter, maar is in elk geval niet goed.

Of misschien is het wel goed, als de andere kant juist een parity verwacht ?

Te vroeg afschakelen van de transmitter kan niet want dan zie je een hoog signaal (of een korte glitch misschien).

Even nog een reactie hier op:

Op 11 april 2020 08:30:14 schreef fatbeard:
Een veelgemaakte fout is het afzetten van de transmitter vóórdat het laatste bit (dat stopbit dus) ook daadwerkelijk is verzonden: niet alleen de buffer maar ook het transmit register moet echt leeg zijn.

Volledig mee eens.

Omdat dat stopbit niet in het transmit register staat wordt het vaak over hoofd gezien.

Hier ben ik het dus NIET mee eens. Als de transmitter empty is dan MOET het stopbit ook verzonden zijn.
Ik geef toe, er zijn UART chips (of IP blokken in VHDL) waar BUGS inzitten dat het TX-EMPTY status bit al aangezet wordt voordat de stopbit(s) verzonden zijn. Maar dat is echt geen regel. Loop je tegen zo'n bug aan zul je dus een workaround in de software moeten maken.

Op 12 april 2020 10:35:20 schreef henri62:
Begin eens met dat extra 9-ste bitje eruit te slopen (TXB8). Zoals ik al zei gebruikt bijna niemand dat. Dus ook de ontvanger gewoon 8 bits ontvangst zonder parity of gekke dingen.

dat betekent dat ik dan geen MPCM mode doe, ik had dit gekozen omdat dat volgens mij speciaal er voor was wanneer er meerdere slaves waren.

als de 1k ram van een atmega 16 niet genoeg is, kan ik nog naar de atmega 32 die heeft 2k RAM.

zal het eens zoder MPCM proberen.

Je moet niet een 900 byte buffer in een 1k MCU willen hebben. Ik doe voorzichtig met "1k buffer" als ik een microcontroller met 20k RAM gebruik.... Ram gaat echt "snel". Je kan niets meer als je 90% van je geheugen voor 1 doel gebruikt.

Anders gezegd: die 100 bytes die over blijven zijn belachelijk weinig om stack en andere variabelen in op te kunnen slaan. Tuurlijk, in 1985 moesten we het ermee doen, maar toen wilden we niet 900 bytes aan data opslaan. En als we dat wel wilden, dan kochten we een 32k extern RAM geheugen.

Echt, als je op dag 1 van je project al 90% van je RAM vol hebt zitten weet je zeker dat het project zo niet af komt. Ik koop processoren met 128k flash (64k zou goedkoper zijn) waar ik na zoveel jaar uitbreiding op uitbreiding... eindelijk meer dan 40k in gebruik heb.

Dat optimaliseren op "de kleinste processor die voldoet" dat moet je vooral doen als je er een miljoen gaat maken. Als je dan 1 euro per processor spaart dan scheelt het mooi een miljoen. Als je nu een prototype maakt waar 4 van die dingen ingaan, dan kan je veel beter 4x 5 euro te veel voor de processor neerleggen dan een 10% kans dat je deels overnieuw moet beginnen met een grotere processor.

ik was in de harware nog wat aan het controleren, en er viel mij iets op wat niet klopt.
zoals al gezegd kan ik met de LA de pulstrein (10101010) zien op de TXD lijn v/d slave die zend (TSOP), dat is de lijn tussen de atmega 16 en de MAX485.
dan verwacht ik dat ik b.v. op de andere slave (TSAL) op de RXD lijn (weer tussen atmega en de max) dezelfde pulstrein te zien krijg,....maar dat is niet zo.
zou het kunnen liggen aan de status v/d RXD pin in de atmega (TSAL) ?

@rew, klopt je hebt gelijk. het is geen centen kwestie, maar een keuze in de beginne niet gestoeld op voldoende kennis v/d materie. ik kan nog wel heel eenvoudig naar 2 k.

RS485 is een bus. Alles wat er verstuurd wordt moet voor alle ontvangers te zien zijn. Zoniet dan klopt er iets niet in de hardware.

En tegenwoordig zijn er veel nieuwe AVR varianten bijgekomen.

Met AtMega1284 kun je door naar 16K ram, al moet je dan wel de software wat aanpassen. Deze is niet helemaal compatible met zijn I/O registers.

ja...dat v/h geheugen is inderdaad niet het grootste probleem, dat komt wel goed.

ik moet nog wat checken op de bus, ik heb denk ik een denk fout gemaakt .

nee het werkt nog niet zoals verwacht:
ik heb alle RX & TX lijnen op de LA gezet. in totaal dus 6x (master, TSAL & TSOP)

als ik iets stuur v/d master --> slave zie ik op:
master TX & TSAL RX & TSOP RX hetzelfde signaal.

als ik iets stuur v/d TSOP --> master zie ik op:
TSOP TX de pulstrein, maar zowel op de master RX en op TSAL RX niets.

de pulstrein komt niet "door" de MAX 485.

als je data wilt versturen met de TX pin, dan moeten toch de DE & RE van de MAX 485 naar "1" ?

DE moet omhoog als je wilt versturen. RE mag laag blijven, dan krijg je je eigen data weer terug.

Maar DE van alle andere drivers moeten wel laag blijven, je kunt maar 1 transmitter tegelijk op de bus hebben. Anders gaan ze vechten.

Over DE/RE: het (chipje) is ontworpen dat je ze aan mekaar kan hangen en met 1 signaal kan besturen. Anderzijds, het is ook simpel om de reciever altijd te enabelen door RE altijd laag te houden. (het exacte niveau weet ik niet uit m'n hoofd, ik praat hier deKees na-> tip: opzoeken/dubbelchecken).

Dus... je wilt de DE van de master en de slave op je logic analyser hebben. En de RX/TX aan beide kanten. Als je dan ook nog de AB van de bus op de LA zet dan kan je precies volgen wat er gebeurt. 8 signalen....

Op 12 april 2020 10:35:20 schreef henri62:
Begin eens met dat extra 9-ste bitje eruit te slopen (TXB8). Zoals ik al zei gebruikt bijna niemand dat. Dus ook de ontvanger gewoon 8 bits ontvangst zonder parity of gekke dingen.

Verder moet je dit soort dingen gewoon niet pollen maar fatsoenlijk met interrupts oplossen.

als ik dat extra 9e bit er uit haal (dus de MPCM mode laat vervallen) hoe gaat dat dan met de adresering v/d slaven ?

dat met die interrupts is mij nog niet duidelijk, ga ik eens bekijken.

er zijn 3 verschillende interrupts:
1 - A USART Receive Complete interrupt will be generated
2 - A USART Transmit Complete interrupt will be generated
3 - A Data Register Empty interrupt will be generated

wat kan ik in zo'n interrupt doen, om niet te hoeven "pollen" ?

@rew: ik ga dat morgen eens zo aan de LA hangen. weet eigenlijk niet of dat met A & B zomaar gaat, is een andere spanning, maar ik verwacht zelf dat dat geen probleem is.

Volgens mij kun je ook het eerste byte matchen als slave adres. Volgens mij heb je daar het 9-de bit niet voor nodig.
Mocht dat niet werken kun je in je interrupt handler state bijhouden of je wel of niet geadresseerd bent en als je geen correct adres hebt ontvangen alles wegmikken tot je het hele frame gehad hebt.
Dat is ook niet heel moeilijk te maken.

Je ontkomt er niet aan om een kleine statemachine te maken om je pakketten te ontvangen.

P.S. Die AB lijnen aan de LA hangen gaat denk ik ook niet. Levels zijn anders. Maar je kunt geluk hebben.

[Bericht gewijzigd door henri62 op zondag 12 april 2020 20:52:11 (11%)

volgens mij is is dat hele MPCM gebeuren bedoeld om de adresering van meerdere slaven te verzorgen. en dat werkt nu.
als zo'n slave eenmaal geselecteerd is kan ik daar data naar toe sturen (werkt ook al) en die slave kan ook data terug sturen (dat werkt nog niet)
dan zie ik op dit moment geen noodzaak om het een en ander om te zetten naar 8-bits mode. wat het moet doen, doet het.

Volgens mij is die MPCM mode onafhankelijk van het feit dat je 8 of 9 bits gebruikt.

Als je nu 9 bits gebruikt moeten alle slaves dus ook 9 bits terugsturen en ontvangen. Anders krijg je framing errors en dus niks binnen.

-edit- Net even heel snel door de ATMEGA page 154 gelezen.
Blijkbaar wordt het STOP bit gebruikt om aan te geven of het een adres of data frame is. Heel ongelukkig gekozen woord gebruik want een stop bit is ALTIJD hoog. Ze gebruiken gewoon een bit extra voor het aangeven of het data of adres is. Dus effectief wordt je wordsize 1 bit kleiner. Wil je dan toch nog 8 bits verzenden moet je dus wel 9 bits mode gebruiken.
Dus het eerste byte wat de master verzend moet RXB8 = 1 zijn, alle andere bytes moet RXB8=0 zijn. (Tot dat je een andere slave wilt adresseren)

In de slaves moet je dus ook 9 bits wordsize terug verzenden.

Verder moet je nog ergens je adres match register invullen in de slave, zal ook wel ergens staan in die 315 paginas.

Ook moeten er hier en daar timeouts toegevoegd worden om te controleren of je ontvanger wel iets terug stuurt en of je binnn X-tijd alles ontvangen heb etc. zowel aan de zender als de ontvanger.
Dat is allemaal niet triviaal.

Op 12 april 2020 21:08:25 schreef henri62
In de slaves moet je dus ook 9 bits wordsize terug verzenden.

hier twijfel ik aan of dat zo is. is het niet zo dat MPCM niks anders doet dan de adresering v/d slaves verzorgen. en wanneer 1 maal een slave geselecteerd, er bij het ontvangen en verzenden v/d bytes geen 9e bit nodig is.

Dat is niet helemaal duidelijk. Het werkt nu bij jou niet, dus zou ik het gewoon proberen.

Maar omdat in de CPU's alles zo efficient mogelijk geimplementeerd moet worden zullen ze echt dat bit er niet af gaan strippen, kost te veel logic gates.

Het enige wat de CPU doet als MPCM aan staat is:
Kijken of bit 9 aan is EN het byte wat ontvangen is matched het adres DAN een flipflop aanzetten, anders uitzetten.

Dan als deze flipflop aan is: alle bytes ontvangen zo nee alle bytes negeren.
(Lees even voor bit 9 het MSB bit, dit kan dus ook bit 8,7,6 zijn afhankelijk van de ingestelde 'word' breedte)

Het zou ook nog kunnen dat je in de ontvanger ook je adres byte toch nog binnen krijgt, die kun je dan wegmikken.

Dus zowel de ontvanger als de zender moet op 9 bits komen te staan, dan het 9-de bit gewoon links laten liggen.

ja dat denk ik ook, ga dat testen.

goede nieuws is dat de pulstrein nu wel "door" de MAX 485 komt. de DE v/d master werd niet laag tijdens het ontvangen v/d pulstrein, dan krijg je een conflict zoals dekees al zij.
nu een interrupt gemaakt: transmision compleet ( bits zijn naar buiten geschoven) en in die interrupt de DE & RE laag gemaakt. nu kijken of ik ook de pulstrein in de master krijg

In tegenstelling wat gezegd wordt dat het 2-draads verbinding is heb je bij RS485 ook je GND nodig

Ik heb redelijk wat ervaring met RS-485 en werk zonder problemen altijd zonder GND wat in theorie ook helemaal niet nodig is, misschien voor afscherming bij lange kabels.

Altijd GND doorverbinden voor een betrouwbare verbinding.
De receivers werken wel gebalanceerd, maar het common mode bereik is maar klein, iets van 7 volt.

Kan best dat het werkt op kleine afstanden maar gaat toch ten koste van de betrouwbaarheid.

En een moderne voeding met SMPS hangt met condensatortjes aan de netspanning, dus de Gnd vliegt alle kanten op.

ik krijg de pulstrein niet in de master binnen. ik zie de pulstrein op de RX pin v/d master, maar het lukt niet om hem in de UDR0 register te krijgen.
er zit een regel in de code waar het programma niet voorbij komt:

while ((UCSR0A & (1 << RXC0)) == 0) {};   // Do nothing until data have been received and is ready to be read from UDR
receivedbyte = UDR0;                      // Fetch the received byte value into the variable "ReceivedByte"

RXC0 flag = This flag bit is set when there are unread data in the receive buffer and cleared when the receive buffer is empty

ik heb dus wel een pulstrein op de RX pin, maar die komt niet in de "receive buffer" ???

weet iemand waarom niet ? bedankt.

[Bericht gewijzigd door trix op maandag 13 april 2020 16:36:24 (100%)

Misschien heeft dit er iets mee te maken:
Uit de datasheet:

• Bit 0 – MPCM: Multi-processor Communication Mode

This bit enables the Multi-processor Communication mode. When the MPCM bit is written to one, all the incoming frames received by the USART receiver that do not contain address information will be ignored. The transmitter is unaffected by the MPCM setting.

For more detailed information see “Multi-processor Communication Mode” on page 159.

verwacht het niet, dit gaat specifiek over het adreseren v/d slaves. als je v/d slave naar de master stuurt hoef je niet te adreseren.
maar ik ga het eens bekijken.

zit net te bedenken, dat wanneer je v/d slave naar de master stuurt, je mischien de slave atmega uit de MPCM mode moet halen, en de data gewoon als 8-bits moet versturen. gaan we z.s.m. testen.

De master moet zowiezo helemaal nooit in MPCM mode staan. Alleen de slaves.

"The transmitter is unaffected by the MPCM setting"

Waarschijnlijk kun je dan alles beter gewoon in 9 bit mode laten staan. Omschakelen elke keer is irritant in de software en levert een hoop ellende op.

dat is zeker irritant,.... maar ja als het niet werkt, probreer je van alles natuurlijk. met een beetje mazzel brengt deze test mij tot nieuwe inzichten die op zijn beurt de oplossing brengt,..je weet nooit hoe een koe een haas vangt