Hallo allemaal,

Ben helaas op het gebied van hardware communicatie protocollen een beetje een leek en wil daar verandering in brengen. Ben momenteel aan het expirimenteren met een Uart poort op een MSP430H1121 Print van Olimex. Nou wil ik deze Uart Poort gaan koppelen aan een PC. Nou is alleen mijn vraag hoe krijg je dat voor elkaar ? immers een Uart verzend 1 byte. Hoe maak je hier op een makkelijke manier gewoon een string van ? Wat ik wil gaan doen is een reeks data gaan verzenden via deze Uart Poort en op die manier een eigen protocolletje schrijven. maargoed 1 stap tegelijk. Hoe zorg ik ervoor dat de data die ik op mn uC uitzend ook sequentieel aankomt op mijn PC ?

Mzzl Stephan

Een string is ook niet meer dan een reeks bytes. Als je een string verzend doe je dat steed met een byte per keer. Bij RS232 communicatie is de data altijd sequentieel. Dat wil zeggen in de volgorde waarin het verzonden wordt komt het ook aan.

Ok duidelijk. en hoe worden de tekens van elkaar gescheiden ? door tijd of door een specifiek karakter ?

Het is een serieel protocol. De bytes worden opgesplitst in bits en eventueel voorzien van een of meerdere startbits, stopbits en een pariteitsbit. Bits worden 1 voor 1 verzonden en aan de andere kant weer samengevoegt tot een byte. Zoek met google nog maar eens op de werking van seriele protocollen en RS232. De datarate (bits of bytes per tijdeenheid) bepaald uiteindlijk hoe snel dat gaat. Dus ja tijd.

Ok. en hoe kun je de timing dan het beste doen tussen een PC en een uC ? heb immers alleen een TX en RX lijn. geen clock of wat ook

http://www.beyondlogic.org/serial/serial1.htm#40

Lees op deze site de informatie over de RS232 door. :-) Informatief. simpel en duidelijk uitgelegd.

Bij RS232 heb je "startbit-data(-pariteitsbit)-stopbit" voor elke verzending, een verzending is een byte data. De byte's die je verzend staan dus volledig los van elkaar, Als je een verband ertussen wil bekomen moet je dit zelf voorzien (bijvoorbeeld de ASCII waarde van "S" om Start aan te geven, dan het aantal byte's dat volgt, dan de data zelf).

Een protocol als I2C werkt enigsinds anders, daar heb je "startbit-adres(zenden of ontvangen bepaald door laatste bit)-ACK-databyte1-ACK-databyte2-....-stopbit".

Je moet aan beide zijden een baudrate instellen. Voor je uc is het dan aan te raden een kristal als tijdbasis te nemen, vooral bij hogere snelheden.

tijd om eens te kijken hoe een uart werkt ....
al wat je moet doen is de divider instellen voor de baudclock
je zult ergens een transmit register hebben : daar gooi je het te verzenden byte in en langs de pc kant komt dat automatisch ind e receive buffer.
de uart doet de rest. je hebt geen controle over timing. je kan alleen de baudclok programmeren. en die moet aan beide kanten gelijk staan.
lees eens de datasheet van die processor van jou. het staat erin uitgelegd

Op 13 september 2006 22:07:43 schreef Marcel:
Je moet aan beide zijden een baudrate instellen. Voor je uc is het dan aan te raden een kristal als tijdbasis te nemen, vooral bij hogere snelheden.

dat laatste is onzin, je max niet meer dan een bepaald percentage (in totaal ~4%) afwijking hebben. Dat geld voor lage en hoge baudrates.

Misschien nog een domme vraag,

heb ik voor het communiceren met een PC ook een MAX232 chip nodig of niet ? er zit op mn uC board namelijk al direct een DB9 connector...

gelijk nog een vraag. Bij normale rs232 communicatie, gaat daar de zender zn volgende karakter pas zenden als het eerste bevestigd is ? ik zag namelijk net ergens source code staan die elke keer het bytje wat binnenkomt echoot en daarna de volgende zend

Op 13 september 2006 22:24:48 schreef Stephan de Wit:
er zit op mn uC board namelijk al direct een DB9 connector...

je had het eerst over een MSP430H1121 header board, volgens mij zit daar geen DB9 op.

Op 13 september 2006 22:30:08 schreef Stephan de Wit:
gelijk nog een vraag. Bij normale rs232 communicatie, gaat daar de zender zn volgende karakter pas zenden als het eerste bevestigd is ?

dat mag je helemaal zelf weten. de meeste protocollen werken niet zo, maar er zijn er die dat wel doen (mijn originele WBus bijvoorbeeld)

Nee klopt, dit is een speciale Olimex uitvoering die hebben ze er bij olimex opgezet. alleen zit er volgens mij geen logica meer tussen

Op 13 september 2006 22:30:08 schreef Stephan de Wit:
gelijk nog een vraag. Bij normale rs232 communicatie, gaat daar de zender zn volgende karakter pas zenden als het eerste bevestigd is ? ik zag namelijk net ergens source code staan die elke keer het bytje wat binnenkomt echoot en daarna de volgende zend

hangt er vanaf ... er zijn veel varianten van rs232

als je handshaking gebruikt ( zowel DTR en CTS ) dan is het in princiepe gelockt. alleen als de ontvanger klaar is wordt de zender vrijgegeven

er is gene echo op hardware niveau, alleen handshake

voor software echo dienen protocollen zoals kermit en tcp/ip

Op 13 september 2006 23:03:53 schreef Stephan de Wit:
Nee klopt, dit is een speciale Olimex uitvoering die hebben ze er bij olimex opgezet. alleen zit er volgens mij geen logica meer tussen

Als het een special is dan kunnen wij er natuurlijk niets over zeggen, tenzij je ons het schema geeft.

Wat heet Special. Tis een Print die om de uC heengemaakt is door Olimes. hier isie te vinden de afbeelding : http://www.olimex.com/dev/images/msp430-1121stk-sch.gif

Net even de datasheets bekenen op de TI website, maar ik kon daar geen HW UART in die chip vinden. Als je dus deze chip wilt gebruiken voor serielle comms zuls je alles in software moten organiseren. Kan wel, maar een stuk lastiger.

Op 14 september 2006 08:20:09 schreef Stephan de Wit:
Wat heet Special. Tis een Print die om de uC heengemaakt is door Olimes. hier isie te vinden de afbeelding : http://www.olimex.com/dev/images/msp430-1121stk-sch.gif

geef die link dan gelijk ....

er zit een (primitieve) level shifter op, dus je hebt geen max232 nodig.

Op 13 september 2006 22:24:47 schreef Wouter van Ooijen:
dat laatste is onzin, je max niet meer dan een bepaald percentage (in totaal ~4%) afwijking hebben. Dat geld voor lage en hoge baudrates.

Ach natuurlijk, het gaan om de relatieve afwijking, niet de absolute. Je hebt helemaal gelijk.