AVR - twee baudrates met 1 USART

Je kan de baudrate tijdelijk veranderen via de code, maar dat heeft nog steeds invloed op zowel zenden als ontvangen.

Andere optie is om zelf een software UART te schrijven, dan sta je vrij wat betreft baudrates. Je hoeft natuurlijk alleen maar de zender te schrijven, de ontvanger laat je door de hardware AURT lopen.

Er is maar één klokdeler.

Er zijn echter alternatieven voor de SoftwareSerial library voor Arduino die vrij wilde dingen toestaan, zoals Rx en Tx op dezelfde pin of enkel Rx / Tx bedrijf. Als je twee aparte draait voor Rx en Tx moet dit volgens mij kunnen.

Split baudrate als V.23 wordt al heel lang niet meer (actief) gebruikt, dus veel support is daar niet voor te vinden.
Mogelijkheid is inderdaad om een software UART te gebruiken. (is hier en daar nog wel code voor te vinden.)
Simpeler is om een controller met 2 uarts te gebruiken op verschillende baudrates. Van de ene gebruik je dan de TX, van de andere de RX.

Je kunt natuurlijk altijd de SPI periferal misbruiken als TX UART door simpelweg alleen de MOSI (master-out-slave-in) pin aan te sluiten, en zelf het startbit en eventueel het stopbit toe te voegen aan je data. De echt UART kun je dan gebruiken voor het ontvangen.

Als je het in software gaat doen, zou ik inderdaad ook de hardware receiver gebruiken en de transmitter in software implementeren. Dat maakt de timing eenvoudiger, omdat je zelf bepaald wanneer je begint met zenden.

Aangezien op dit niveau bitrate gelijk is aan baudrate... is er weinig met 'verdubbeling' ofzo te trucen.

Hardware split-bitrate doen AVRs niet. 1 zit maar 1 clock divider in. Je kunt wel omschakelen als je protocol dat toelaat (in het kader van de smerige oplossingen)

Een software-uart voor TX is niet zo spannend. Voor RX iets ingewikkelder. Als je bitrate niet (te) hoog ligt, dan is het prima op interrupt basis te maken. Al je bitrate erg hoog ligt, is het ook prima in code te maken als het blocking mag zijn.
Ik zou het zo oplossen. Als dat je te spannend wordt (waarom?) dan pak je een AVR met 2 UARTS of je doet het met een dual-SPI-uart (wellicht dat daar ook nog wel een exemplaar te vinden is wat wel split-bitrate lust).

Vroeguh, in de 80's en begin 90's met viditel BBS'en modem-en met het Elektuur zelfbouw modem op 75/1200 baud.

75 up was genoeg want je kon toch niet sneller typen. En hetzelfde voor 1200bd downstream, veel sneller lezen ging toch ook niet.

Een aparte baud rate generator (Western Digital 1941) met een ay5-1013 uart.

een beetje Uart heeft verschillende ingangen voor de clock.

Even het hele verhaal. Ik wil de data van 16 seriele poorten samenvoegen en via een usb poort naar een pc sturen.
De binnenkomende seriele verbindingen zijn al traag en ik wil zo min mogelijk vertraging inbrengen bij de verwerking en het doorsturen van deze signalen

De goedkoopste oplossing tot nu is 2 uC's met 8 seriele ingangen elk.
ATXMEGA128B3-AU 2,77
(foutje: heeft maar een UART)

ATXMEGA128A1 5,80 Euro bij Farnell
(Gaat het waarschijnlijk niet worden, ik wil iets kleiners)

Deze mogelijkheden heb ik overwogen:

nodig in de eerste chip:
- USB
- 7 UART ingangen
- 1 UART ingang (1Mbit)
nodig in de tweede
- 7 UART ingangen
- 1 UART uitgang (1Mbit)
Snelle communicatie tussen IC's (1Mbit) maar als nadeel, verlies van 2 seriele poorten

nodig in de eerste chip:
- USB
- 8 UART ingangen
- 400kHz I2C master
nodig in de tweede
- 8 UART ingangen
- 400kHz I2C slave
Gebruik van alle poorten, maar als nadeel maar slechts 400 kHz communicatie tussen de uC's

Ik heb (nog) geen ervaring met SPI communicatie. Kan in de datasheet die ik weghaalde bij Farnell ook niet zien of SPI samenvalt met een van de UART pinnen. Dat zal ik dan eerst maar eens gaan onderzoeken.

In het 'hele verhaal' ontbreken nog steeds de bitrates.

Overigens doet het geheel mij een beetje denken aan een constructie waar Baytech vroeger 'multiports' voor had.

Je hebt het over 'traag'. Ik denk dat een SPI chippie met 4 UARTs dat prima gaat doen. SPI kun je in hardware afhandelen of bitbangen. Dat eerste is handiger, maar je moet ff zorgen dat je goed weg komt met je control lines (als je meerdere nCS gebruikt.

Een AVR met meerdere poortjes acht ik in deze niet zo simpel - je hebt teveel UARTS nodig.

Een andere optie is een aantal software UARTs. Bij 'lage' bitrates is dat prima te doen als je een ISR op zeg 5x of 10x je bitrate kunt laten rennen. Het is wel een beetje 'programmeren voor gevorderen'. Dat wel...

Heb je al eens over een FPGA gedacht? Daar maak je zoveel UARTs als je wilt (binnen het redelijke).

Je kunt ook een aparte UART chip overwegen. Die heeft ook alle handshaking aan boord.
https://www.exar.com/connectivity/uart-and-bridging-solutions/8-bit-vl…

@Arco
Bij Mouser vind ik een XR16V798 voor 36 Euro, dat zie ik niet als een alternatief voor een uC van 5,80 euro met 8 USART's
Als je handshaking wel nodig hebt dan is het beslist een heel mooi chippie.

@EricP
Je wilt bitrates zien:
Mijn data komt binnen met 30 kbit/s current loop en moet zo snel mogelijk doorgestuurd, liefst binnen 100us na ontvangst.
De USB verbinding naar de pc is snel genoeg maar wat ik daar tussen ga zetten moet A goedkoop en B snel zijn. Die twee gaan meestal niet samen.

Ik heb ondertussen eea gelezen over SPI en begin daar warm voor te lopen. Met een SPI clock van (uC)CLK/4 en de chips strak tegen elkaar gemonteerd moet ik toch binnen een enkele microseconden een paar bytes kunnen versturen?

Het gaat allemaal om reactietijd. Als er op alle 16 ingangen data binnenloopt met 30kbit en ik ga dat met dezelfde snelheid doorzetten naar een enkele lijn dan mag het niet binnen de reactiesnelheid komen.

Als ik de reactiesnelheid van de gemiddelde mens even in schat op 20ms (van mij is niet meer zo snel) Dan is dat voor 8 poorten maximaal 8 bytes per poort.

31250 kbit/s is 32us per bit.
8poorten * 8bytes *10bits-per-byte * 32us = 20480us

EDIT:
Helaas op de ATXMEGA128A1 zitten SPI en USART1 elkaar ook dwars. Zowel MISO als RXD1 zitten op PC6.
Ik kan trouwens geen goede datasheet vinden waarin alle dubbelfuncties in pinnen van de ATXMEGA128A1 te zien zijn

Helaas SPI en USART1 zitten elkaar ook dwars. Zowel MISO als RXD1 zitten op PC6.

Waar zit RXD0?

De Atmega8/88/168 RXD en TXD pen 2 en 3. MOSI, MISO, SCK op pennen 17, 18 en 19.

Ook bij de 644A zitten de pennen niet samen.

Quad UART to USB van FTDI maar 5 euro: https://www.arrow.com/en/products/ft4232hl-reel/ftdi-chip#page-1

als een alternatief voor een uC van 5,80 euro met 8 USART's

Als die die vindt, dan gebruik je die toch??

Mijn data komt binnen met 30 kbit/s current loop en moet zo snel mogelijk doorgestuurd, liefst binnen 100us na ontvangst.

Dat is aan 'rare' bitrate, maar goed... Stel dat je dat op 8 channels naar binnen lepelt... Dan zit je zonder protocol overhead al op 240kbps. Welnu, dat gaat. Net. Maar ik neem aan dat je 'host' ook nog moet weten waar de data vandaan komt - en dat je niet de bytes van elke ingang zomaar door elkaar kunt husselen. Daar is je eerste protocol overhead. Als het dan ook nog een soort van packets zijn (die indruk heb ik...), moet je wachten tot een compleet packet binnen is. Daar is je 2de stuk overhead.
Je moet ook eens gaan rekenen hoeveel clock cycles die AVR heeft om dit te doen. Als je een indruk hebt wat er moet gebeuren, kun je kijken of dat grofweg haalbaar is. Mijn gevoel zegt dat je het - mits slim geprogrammeerd - net moet kunnen halen. Als de AVR op 24MHz loopt (aanname) en je hebt 240kbps aan throughput, dan heb je 1000 ticks per character. Daar kun je wel wat in doen - maar niet teveel.

Helaas SPI en USART1 zitten elkaar ook dwars.

De AVRs die ik ken, gebruiken hun USART voor hardware SPI. Hety zit niet dwars, het is dezelfde hardware die je gebruikt.

De USB verbinding naar de pc is snel genoeg maar wat ik daar tussen ga zetten moet A goedkoop en B snel zijn. Die twee gaan meestal niet samen.

Als die PC iets van M$ draait, dan hoe je je over die snelheid niet zo druk te maken. Het is hoe dan ook verre van real-time.

Op 24 januari 2016 14:46:48 schreef hennep:
Even het hele verhaal. Ik wil de data van 16 seriele poorten samenvoegen en via een usb poort naar een pc sturen.

Er bestaan producten hiervoor, al hebben ze meestal een ethernet poort met drivers met COMx emulatie. Ken je die al?

Ik heb niet de indruk dat het om een hobbyproject gaat dus.... Wil je echt van scratch zelf iets opzetten wat je in de winkel kunt kopen?

bijvoorbeeld: http://www.digi.com/products/serial-servers maar er zijn meerdere fabrikanten. Ik heb zelf nog een 8-poorts ding met rs485 ergens op een plank liggen. Current loop zal wat lastiger worden. Als het geen async protocol op een standaard bitrate is zoals 9k6, 19k2 of 38k4 dan wordt het nog lastiger denk ik.

[Bericht gewijzigd door joopv op maandag 25 januari 2016 10:30:42 (26%)

Blijkbaar wordt intern dezelfde hardware gebruikt maar als je dit in specificaties hebt gelezen:

- Eight USARTs, IrDA modulation/demodulation for one USART
- Four SPI (Serial Peripheral Interface) peripherals

Dan zit het mij behoorlijk dwars dat ik weer opnieuw mag gaan zoeken.
Als Farnell het aantal seriele poorten opnam in de parameter search voor uC's, of Atmel een prijsindicatie, dan zou dit zoeken een stuk eenvoudiger gaan. Het zal beslist een commerciele reden hebben om dit niet te doen.
Ik heb nog maar 1 project met de xmega gedaan en struikelde al gelijk over het feit dat niet iedere xmega 8 poorten heeft.
Maar genoeg gekletst over mijn frustraties.

De goedkoopste midi merger die ik tegenkom op ebay, kost ongeveer 150 US$ ex verzendkosten/importheffing. Maar die heeft maar 8 poorten.
Een 16 poort versie kon ik zo snel niet vinden. Is ook niet belangrijk, het gaat even om een prijsindicatie.

Ik verdien de boterham met programmeren dus het blijft voor mij een hobby. Ik zoek daarom een zo goedkoop mogelijke oplossing om die 8 poorten per atxmega te koppelen tot 16 ingangen.
Het is redelijk eenvoudig om 3 uC's te pakken en met die 24 poorten te bouwen wat ik wil, maar ik wil eerst de uitdaging om het met 2 uC's te proberen nog verder uitzoeken.

Het is makkelijk om te zeggen dat de tijd die ik er nu al in heb gestopt het rechtvaardigt om er eentje kant en klaar te kopen. Maar ook de puzzel om het zo compact mogelijk te maken hoort bij de uitdaging.

Eric noemde het al, what about an FPGA? Daarmee los je al je timing issues in 1 klap op. Moet je alleen even kijken hoe je handig naar je PC komt, want USB implementeren is niet zo eenvoudig. Misschien kan het via een FTDI chippie of zo.

Als ik het goed begrijp wil je 16x30kbit je PC in lepelen.
Met 4x oversampling kun je je uart signaal reconstrueren, dus moet je 4x16x30kbit = 240kByte/s je PC in pompen.

Ik denk dat je dat met een Arduino Due, of willekeurig welke andere ARM-Cortex wel red.

Dan moet je daarna op de PC uit die 4 samples/bit je UART-signaal reconstrueren. Maar dat is software, en daar is die PC snel genoeg voor.
(En het zou me niet verbazen als je SoftwareSerial op 30kbit ook voor 16 kanalen op zo'n ARM-Cortex chippie red)

@blurp, Ik voel er weinig voor om de driver aan de pc kant aan te passen. Zoiets zul je toch bedoelen met signaal reconstrueren. Nu kan ik een standaard driver installeren. Ik pas nu aan de kant van de uC de LUFA library toe van Dean Camera. Daarmee kan een aantal standaard usb apparaten worden gemaakt en hoef ik op de pc niets anders te doen dan het installeren van een open source driver.

@flipflop, Ik ben zeker geinteresseerd in een fpga toepassing maar heb er nog nooit mee gewerkt. Onwetendheid maakt de opstartdrempel een stuk hoger.
Ik zie dat je een fpga al voor rond de 3 euro kunt kopen. Daarin zitten dan 1280 function blocks, geen idee hoeveel ik er daarvan nodig heb maar de software zal het mij waarschijnlijk wel vertellen als ik te kort kom.

Wat ontbreekt is een goede tutorial om mij op weg te helpen.
De usb poort is geen probleem, de meest eenvoudige avr met usb aan boord kan die klus klaren.

Op 24 januari 2016 16:54:48 schreef hennep:
en moet zo snel mogelijk doorgestuurd, liefst binnen 100us na ontvangst.
De USB verbinding naar de pc is snel genoeg

BZZZZT. Game over!

Als een USB chip "iets te melden" heeft, moet ie wachten totdat ie 1ms later weer gepolled wordt door de PC. De PC kan ieder moment beginnen met zenden, maar als er data de andere kant op moet, is het wachten op de volgende "POLL" van de PC.

Gemiddeld zit ik dan voor 16 ingangen, per ingang nog wel onder de 100us.
Maar je hebt gelijk, het is minder mooi dan ik had gehoopt.

Op 16 seriele poorten komen pakketjes van 3 bytes binnen met 31250 baud.
De communicatie per pakket van 3 bytes duurt 960 us. Die tijd ben ik kwijt, zo werkt het protocol, kan en mag ik niet verbeteren.
Als ALLE binnengekomen data na 1 ms extra vertraging via usb wordt opgestuurd met 450 Mbit/s naar de pc, dan valt het totaal ruim binnen de reactietijd.
De totale zendtijd is dan ongeveer 2 ms, een heel mooi resultaat.

De meeste mergers die op de markt zijn zetten het signaal weer op een seriele uitgang met dezelfde snelheid.
Dan komt bij een 4 poort merger de data van het laatste pakket 5ms later aan. Bij een 8 poort merger na 9 ms.
Voor 16 poorten zou de vertraging te groot en hoorbaar worden. Met USB moet ik dit probleem kunnen oplossen.

@blurp, Ik voel er weinig voor om de driver aan de pc kant aan te passen. Zoiets zul je toch bedoelen met signaal reconstrueren

Controller zend het oversampled signaal op normaal wijze naar de pc daar hoef je echt geen drivers voor aan te passen. Enkel het signaal wat binnenkomt is heel wat anders.

Ik denk dat blurp bedoelt dat je 16 gewone io poorten van je controller neemt en die op 4x de snelheid van de bautrate scant. Die ruwe date stuur je direct door naar de PC.

De pc moet nu uit de ruwe data de 16 kanalen zien te herleiden ipv dat de controller het zware werk moet doen.

@benleentje: jij begrijpt het. TS begrijpt het ook, daarvoor moet je software maken op de PC. En die moet het (maak ik op uit TS zijn verhaal) dan als enkele uart aan andere, bestaande software aanbieden.

Dat is op unox een eitje (alles is een file, ook een uart), maar op windows wellicht wat lastiger.

Op 26 januari 2016 11:33:28 schreef hennep:
Wat ontbreekt is een goede tutorial om mij op weg te helpen.
De usb poort is geen probleem, de meest eenvoudige avr met usb aan boord kan die klus klaren.

Hoe zie je die AVR dan nog in de FPGA oplossing? Mijn gedachte was om de FPGA de 16 kanalen te laten multiplexen naar 1 kanaal, bv UART. Met dat kanaal moet je dan de PC in, en dat zou via USB kunnen. Ofwel, een UART naar USB converter. Moet je wel even rekenen of dat qua snelheid allemaal kan, hoeveel baud wordt dat...

Nog een wild idee: stel je neemt 16 USB/Serieel kabels en die sluit je op 16 (!) USB poorten van je PC aan. Dan gebeurt het samenvoegen "vanzelf" in de PC.