[EL] Hoe 4 async lijnen in een PIC lezen?

[Belgar]

Voor een klein projectje dat ik binnenkort wil gaan doen wil ik 4 asynchone lijnen inlezen en bewerken. Het probleem is nu dat ik dat dus niet met interrupts of polling op kan lossen binnen een enkele PIC processor. Nu kan ik natuurlijk 5 PICs gebruiken (1 per lijn en een 'master'), maar dat lijkt me nu niet de meest ideale oplossing.

De 4 inkomende lijnen zijn MIDI interfaces die op een snelheid van ongeveer 31 kbaud draaien. Voor mijn projectje wil ik deze 4 interfaces in een snelle seriele output stoppen. Ik vraag me nu af hoe ik de 4 inputs nu zo efficient mogelijk kan inlezen en verwerken. Het gaat dus zeker lukken door elke input te verwerken door een simpele PIC en deze de informatie naar de 'master' te laten sturen. Simpelle 'polling' op een enkele PIC is volgens mij onmogelijk, omdat elke input op ieder willekeurig moment kan starten en dan dus een eigen klok nodig heeft. Ik ben redelijk bedreven in het programmeren van PICs, maar mischien hebben mensen met meer ervaring ideeen om dit probleem op te lossen zonder naar een overkill van 5 PICs te grijpen ?

Het project betreft overigens het gebruik van de COM poort als input van 4 virtuele MIDIports. De software hiervoor is al redelijk gevorderd, de hardware ben ik dus nu aan het bekijken

[sebastius]

heeft midi geen standaard clock? Of is het probleem dat je 4 verschillende midi devices koppelt?

* sebastius heeft iets dergelijks gemaakt, maar dan voor i²c.

[Belgar]

De bedoeling is dat (maximaal) 4 instrumenten worden aangesloten op een doos waar vervolgens een enkele seriele uitgang naar een COM-poort op een computer gaat. Daar de seriele interface naar de computer vele malen sneller is dan de standaard snelheid van MIDI is de delay dus verwaarloosbaar.

Het probleem met 'normale' MIDI multiplexers is dat ze dus weer een standaard MIDI-out hebben. Indien dan 4 instrumenten tegelijk worden bespeeld kan er dus delay ontstaan, omdat er queing wordt toegepast. Ik wil dus een echte serial multiplexer bouwen, maar ik krijg dus te maken met 4 aparte asynchrone lijnen. Deze zijn wel geclocked maar niet gesynchroniseerd met elkaar. Polling is dan dus (volgens mij) geen optie.

wat wel zou kunnen is een 'round-robbin' techniek, maar dan moet de verbinding tussen multiplexer en PC synchroon zijn. Op zich niet zo'n probleem, maar dan wordt de afstand tussen PC en multiplexer wel sterk beperkt en wordt de software op de PIC erg complex. Ook wordt de PC software dan verantwoordelijk voor het 'clocken' van de lijn en wordt mijn software mogelijk weer platform-afhankelijk.

Om al deze redenen zoek ik dus een eventueel betere oplossing dan 5 PICs gebruiken.

[ Voor 3% gewijzigd door Belgar op 02-04-2004 12:05 ]

[sebastius]

en als je nou eens een stevige microcontroller pakt, die snel genoeg alle midi lijnen inleest, en dat dan achter elkaar prakt op je com poort? Desnoods alleen ruwe bitjes inlezen en de PC het laten decoderen om megahertzen op de PIC te besparen.

Of anders FiFo buffers (zoals in een logic analyser gemikt worden) gebruiken? Dan kun je aan de ene kant rustig data er in gooien, en op je gemak uit lezen.

En waarom niet direct bijvoorbeeld op de parallele poort? Of gewoon de midi poort op je soundcard?

[ Voor 12% gewijzigd door sebastius op 02-04-2004 12:09 ]

[Belgar]

Hoe weet ik dan welk bitje origineel van welk kanaal komt? Er moet dus een soort encapsulatie komen zodat ik later op de COM poort weer het zendende apparaat kan terugvinden. Dit moet dus op byte niveau en kan dus alleen door de inkomende data per kanaal te lezen

Paralelle poort en MIDI poort vallen af vanwege de zeer beperkte snelheid van deze poorten. 4 kanalen op paralel gaat nog wel, maar dan is de afstand multiplexer naar PC maximaal 40 cm. niet echt handig op een podium.

Fifo buffers is interessant, maar hoe clock ik die dan op 31.2 kbaud ? Zijn er buffers die kunnen shiften op een externe puls? Zo ja is dit natuurlijk wat ik zoek.

[sebastius]

FiFo buffers werken ongeveer als volgt: op een signaal (jouw 31,2kbaud bijvoorbeeld) wordt de data die op de poort staat ingelezen. De schrijfpointer gaat één omhoog en staat weer klaar. Aan de andere kant geeft je PIC een signaal om te lezen (leespointer) en dan word de data aangeboden op die kant van de chip. Onafhankelijk samplen en uitlezen dus. Elektuur heeft er een logic analyser mee gemaakt, dat zou je als inspiratiebron kunnen gebruiken. Februari 2003 is het nummer.

Bedenk wel dat je signaaltjes dan perfect TTL compatible moeten zijn, anders gaat het stinken.



Een illustratie van het geheel.

[ Voor 9% gewijzigd door sebastius op 02-04-2004 13:52 ]

[Belgar]

Bedankt, ik ga eens verder lezen over deze buffers. Hopelijk kan ik hiermee redelijk eenvoudig bereiken wat ik in gedachte heb. Dat wordt weer 2 dagen datasheets verslinden. TTL probeer ik op het moment te bereiken door de signalen door een schmitt-trigger poort te halen. Tot nu toe heb ik daar geen problemen mee ondervonden.

[sebastius]

Als ik jou was zou ik die elektuur (02-2003) even opzoeken, want daar staat haarfijn bijna je hele systeem in uitgelegd

[EXX]

Kan je geen hardware UARTs (UARTs die je dus met straps kan instellen, er komt geen software aan te pas) gebruiken? Ik heb ooit is zoiets in elkaar geknusteld om MIDI met zijn kromme 31.2 kbps om te zetten naar RS232 38400 kbps. Dat werkte prima; het enige waar je rekening mee moest houden is dat de PC niet te snel data stuurde want door de lagere MIDI snelheid kreeg je dan overruns.

Je had dus 2 UARTs back to back, met de ene op MIDI snelheid geklokt en de andere op 38400 kbps.

[ Voor 9% gewijzigd door EXX op 02-04-2004 15:08 ]

[Belgar]

Het probleem wat je blijft houden met hardware UARTs is dat je nog steeds de startbit moet opvangen met polling en daar vervolgens een clock aan moet koppelen. deze clock kan nog steeds afwijken van de andere 3 inkomende kanalen. Daarom zou inderdaad een FIFO register uitkomst kunnen bieden. Echter nog geen geschikte kleine FIFO gevonden. De FIFOs die ik wel heb gevonden zijn dus duurder dan een extra PIC