Eenvoudige bitrate converter

Ja ik had er natuurlijk "verkrijgbare UART's " neer moeten zetten, maar dat leek me voor zich te spreken. ;-)

Dombo wrote: | Dat geld ook voor het ontvangen. Voor deze toepassing lijken me dat | interrupt handlers geen issue zullen zijn.

De ontvangstsnelheid is 8 maal langzamer dan de zendsnelheid, de interrupt latency zal dus ook veel minder invloed hebben.

| Desondanks is verzenden eenvoudiger dan (betrouwbaar) ontvangen. Het | verzenden zou je op de Atmel ATtiny2313, die je in een eerdere post | aanhaalt, ook m.b.v. de Universal Serial Interface (USI) kunnen doen.

Dat kan, maar ik denk niet dat de code daar eenvoudiger van wordt. Zo'n USI is nogal primitief, en werkt bovendien met de verkeerde bit-volgorde (MSB first).

| Aan de andere kant een microcontroller met twee UARTs (bijv. ATmega162) | kost je de kop ook niet.

Met 40 of 44 pennen is dat wel een joekel van een chip.

Het is ook wel een uitdaging om de hardware zo simpel mogelijk te houden, b.v. alleen een 8-pins ATtiny25 zonder kristal. Je hebt dan geen enkele extra component nodig, maar je moet wel alles softwarematig doen, en eventueel de interne oscilator calibreren.

Code zal niet heel ingewikkeld zijn. Laat je timer op 38k4 lopen en je hebt verzend klok en 8X oversampling op de 4800 ontvanger in een.

Interne osc moet je toch wel mee oppassen. Calibreren gaat natuurlijk en af fabriek zit ie op 1% bij 3V en 25 graden. Maar het verloop over het temperatuurbereik en voedingsspanning is behoorlijk. Voeding is natuurlijk goed te regelen, maar temperatuur meestal wat minder.

Voor seriele communicatie moet je toch proberen onder de 3% afwijking te blijven en dat lijkt mij in dit geval toch het eenvoudigst met een kristal op te lossen, zeker omdat je de pennen toch over hebt. Maar mocht je het echt willen, dan kun je eens naar je gewenste temperatuurbereik kijken en bepalen of je daar +/-3% afwijking over kunt halen.

Je zal bij ontvangen wel moeten oversamplen, het verschil is dus een stuk kleiner dan die 8x. Daarnaast komt er bij betrouwbaar ontvangen wat meer software kijken (denk aan bijv. omgaan met glitches).

Persoonlijk vind ik dat ook leuke uitdaging om met minimale middelen iets te realiseren (de eenvoudigste AVR of PIC volstaat voor deze toepassing). Echter als het om te doen is om snel, en met minimale effort, een one-of oplossing te hebben dan kan het handig zijn om een microcontroller te pakken die het allemaal al aan bord heeft, ook al is die volstrekte overkill voor deze toepassing.

Zonder kristal lijkt mij niet verstandig als de oplossing betrouwbaar moet werken, de marge bij seriële communicatie zijn niet zo heel erg groot.

Het houdt nogal wat in. Je moet minimaal 8, liefst 16 bitsamples nemen, en dan bepalen OF het een startbit was , EN welke het midden van het startbit was, en dan precies netjes getimed alle andere bits lezen.

P.

Nou, poeh hee! Op 4.8MHz heb je 1000 instructies per bit te verbranden en mocht dat niet genoeg zijn dan kan je met de genoemde ATtiny25 tot 16MHz gaan, 3333 instructies per bit. Daar kun je echt heel luxe filtering mee bouwen hoor.

Hoe denk je dat een 'normale' UART met 16x klok dat doet? Dat geeft toch echt veel minder mogelijkheden hoor.

Maar je hebt wel gelijk dat het een aardig stukje code wordt. :-)

Op zich moet het met een beetje moeite ook best lukken met een onnauwkeurige, ongecalibreerde klok. Je kunt uit het bitpatroon gaan bepalen wat de bitrate is. Kost even moeite, maar die procesor heeft verder toch niets te doen. Ik heb zoiets wel eens gedaan voor een simpele debug interface op een ATtiny12, heb je gelijk auto-baud en het ding had ook nog wat anders te doen op z'n ~1.2MHz klok.

Zelf zat ik te denken om voor zoiets twee simpele microotjes "rug aan rug" te zetten. Met twee UARTS zie je ze niet zo vaak en als je twee complete microcontrollers neemt dan ben je nog niet zoveel geld kwijt, per slot van rekening gaat het volgens mij om een eenmalig projectje, laat het dan 3 euro meer kosten (die ATTiny2313 waarnaar iemand anders verwijst lijkt mij al geen slecht keuze). Je hebt dan aan elke kant een UART en je laat ze gewoon via 8 pinnetjes en nog enkele voor de handshake de waarde aan elkaar doorgeven. Heb je alleen een mainloopje nodig wat deze parallele communicatie afhandelt en de juiste waarde uit de UART leest dan wel er in schrijft. De andere oplossingen die aangedragen worden zullen vast allemaal maakbaar zijn, maar dit lijkt mij veruit het simpelste, er komt amper programmeerwerk aan te pas.

Ik ben het overigens met je eens, ik zou het ook met kristallen doen.

Groeten, Rene

"P." schreef in bericht news: snipped-for-privacy@4ax.com...

Is dat zo? De UARTs die ik heb bekeken, pakken één of drie samples in het midden van het bit. Bij drie samples is het: De meeste stemmen gelden. Meer samples geven niet altijd een hogere betrouwbaarheid. Hoe verder je samples uit het midden van het bit liggen, hoe onzekerder het wordt of ze wel de juiste waarde hebben. Bij mooie, rechthoekige signalen heb je sowieso geen detectieprobleem. Maar als er van een enkele "1" tussen een boel nullen alleen maar een afgeronde bobbel overgebleven is, zullen drie samples uit het midden hem wel juist decoderen. Als je over zestien samples gaat middelen, vind je ten onrechte een "0". Daar is dan ook wel weer wat aan te doen maar dan ga je zachtjesaan in de richting van DSP.

In dit geval, 4800bps, current loop en heel korte verbindingen is er geen enkele reden om allerlei bijzondere technieken uit de kast te halen. Micro's, ook de kleinsten, hebben een instructietijd van 1us of minder. Bij een klusje als dit staat zo'n ding hoe dan ook meer dan negentig procent van de tijd te wachten.

De vraag is wat de OP met dit alles opschiet. Er zijn nu mensen genoeg die het probleem begrijpen en weten hoe het aangepakt kan worden. Een kant en klare oplossing heeft nog niemand. Ik ook niet.

petrus bitbyter

Goede uarts doen dit echt. Het is geen dsp maar zit gewoon in wat hardware ingebakken, voor hardware stelt zoiets qua timing niets voor.

De simpelste oplossing is echt lees-schrijf. En dan alleen een beetje instellen. Dat spaart een hoop gepuzzel en mogelijke fouten uit.

Die is er denk ik ook niet.

P.

In article , petrus bitbyter wrote: ...

Hoewel ik beslist niet vies van electronica (en ander) knutselwerk en al helemaal niet van wat programmeerwerk, begrijp ik dat "eenvoudig" voor dit probleem niet bestaat. Vooral als het ook nog betrouwbaar en robuust (zeewaardig) moet zijn (een ATtiny op experimenteerbordje is dat m.i. niet).

Ik ga een Brookhouse multiplexer bestellen, kost wel wat, maar kan wat hier nodig is, heeft zich in de scheepvaart bewezen en is vlot leverbaar.

In ieder geval: iedereen zeer bedankt voor het meedenken,

-- ted

Gewoon niet naar software oplossingen kijekn, dan is het wel betrouwbaar.

P.

In die Brookhouse multiplexer zit ook software, dus miet betrouwbaar?

"Ted Lindgreen" schreef in bericht news:4b0d4dee$0$22944$ snipped-for-privacy@news.xsall.nl...

Je hebt groot gelijk. Ik wist niet dat er zo'n kant en klare oplossing te koop is anders had ik direct al aangeraden die in overweging te nemen. Voor de gemiddelde gebruiker loont het maar zelden de moeite iets te gaan ontwerpen dat al kant en klaar te koop is. Uiteraard geldt dat niet voor hobbyisten en andere liefhebbers. Die rekenen de tijd die het kost niet en calculeren een eventuele mislukking ook nog in... Als het goed is.

"Eenvoudig" bestaat wel degelijk. Voor die oplossing heb je immers gekozen. Of zelf bouwen eenvoudig is, hangt vooral van je kennis en vaardigheden af. Ik voor mij vind het probleem vrij eenvoudig op te lossen maar dat geldt vast niet voor iedereen. Intussen snijd je wel een zaak aan die door elektronici nogal eens over het hoofd gezien wordt: De mechanische kant van een ontwerp. Zelfs al had ik op dit moment een kant en klaar geprogrammeerde micro, dan was ik nog niet halverwege. Eer de interfaces in orde zijn (al was het alleen maar de juiste sockets), alles netjes op een PCB zit, de voeding, een kastje "robuust en betrouwbaar", ben je vele, vele uren verder. Het kan allemaal. Maar als je tijd geld waard is, je niet al te lang wilt hoeven wachten en ook nog "proven technology" op prijs stelt, is ?500,- niet eens te duur. Ik schat zoiets trouwens nog een stuk goedkoper maar daar kan ik best naast zitten.

petrus bitbyter

Right:

-p

Geen bitbanging op poorten, dat is niet betrouwbaar. Het is wel betrouwbaar te maken, maar dat kost je veel meer dan gewoon een systeem met 2 uarts. En spaart je een hoop testen en onzekerheid uit.

P.

Je bedoeld een software UART is niet betrouwbaar neem ik aan?

Wat wil je nu zeggen? Het is niet betrouwbaar, maar wel betrouwbaar te maken? Ergo, er is een betrouware oplossing te maken met een software UART. Kost inderdaad meer software dan een hardware UART, maar zo heel dramatisch is het nu ook weer niet. En bij goed ontwerp zou ik niet van 'onzekerheid' willen spreken. En 'kost meer' hangt natuurlijk helemaal af van component kosten, kosten van je tijd, en aantallen.

Voor de OP al helemaal niet meer relevant, want hij koopt een standaard converter. Dat is in zijn geval het 'goedkoopst'.

Ja. Jaren ervaring bij Philips!

Alles is te maken. Maar het blijft bagger en een slechte oplossing.

Dat is echt het goedkoopst. Je moet ook de uren meetellen. En vooral betrouwbaarheid.

P.

Ik heb jaren geleden wel eens een project gedaan waarbij een apparaat (met Z80 processor) voorzien moest worden van een soort locaal netwerk (langzaam). Ik heb toen een Z8530 SCC gespecificeerd, want daar zit HDLC helemaal in geimplementeerd inclusief CRC, NRZ->NRZI conversie, clock recovery, etc. Hardstikke makkelijk (als je er ervaring mee hebt) om die chip te vertellen dat je een blokje data wilt versturen en inkomende blokjes data te ontvangen. Toch werd dat niet echt op prijs gesteld want die chip kostte geld, en dat ging maal het aantal verkochte units terwijl allerlei broddel oplossingen wellicht meer programmeertijd kostten maar in serie productie goedkoper waren.

Ging dat bij Philips niet zo dan?