Snelheid seriële poort

De 115K beperking komt door de RS232 level converters, die gaan vaak niet hoger (soms 230K). Je kan wel sneller met een USB<->COM maar dan moet je geen level converters hebben (bijv. een printje met alleen een FTDI232 en het TTL signaal rechtstreeks gebruiken).

ofwel die MAX232 zou de boel kunnen vertragen? Maar wat zou mijn laptop aan kunnen?

datasheet MAX232: Operates Up To 120 kbit/s

zou een serieele PCMCIA helpen?

[Bericht gewijzigd door Marcel (5) op dinsdag 2 oktober 2007 16:39:45 (11%)]

je kan een pc boven de 1 megabit duwen zonder problemen.
je moet er wel voor zorgen dat de tranceiver op jouw bord die snelheid aan kan. een max232 kan dat niet ...
je zult een 75xxx moeten grijpen van ti of iets anders van maxim.

Ik gebruik dit: http://www.voti.nl/winkel/catalog.html?K-USB-1 zonder problemen op 500 kBit. Dan gebruik je dus geen RS232 level converters.
Het werkte ook met 1Mbit maar dan kon de PC het af en toe niet aan met de VCP driver (dumpen grote datablokken van micro naar PC)

Veel serieele poorten op laptops hanteren 5 volt i.p.v. 12 volt. Qua compatibiliteit is dit soms wat minder, maar de snelheid is vaak hoger. (Dit ivm. de slew-rate)

Op 2 oktober 2007 16:32:10 schreef JoWi:
De 115K beperking komt door de RS232 level converters, die gaan vaak niet hoger (soms 230K). Je kan wel sneller met een USB<->COM maar dan moet je geen level converters hebben (bijv. een printje met alleen een FTDI232 en het TTL signaal rechtstreeks gebruiken).

Geloof dat maar niet. Zelfs een RC5 signaal door zulke comconvertor is te snel. Zie dit topic.
http://www.circuitsonline.net/forum/view/23162/1/

hoe krijg ik een COM poort om mijn laptop die +1Mbps aan kan?

edit: ik ga voor dat FTDI IC.

[Bericht gewijzigd door Marcel (5) op dinsdag 2 oktober 2007 19:11:39 (34%)]

Met een FT232R (FTDI232 is geen typenummer) heb ik in ieder geval 50kbyte/s weten te halen met een AVR, op 500kbps baudrate. Let wel op dat handshaking belangrijk wordt bij dit soort snelheden, anders ga je data kwijtraken.

is er iemand die een hogere snelheid heeft weten te behalen?

Op 2 oktober 2007 21:13:23 schreef Marcel (5):
is er iemand die een hogere snelheid heeft weten te behalen?

Optimist !
Dat haalt je MCU niet, ik neem aan dat die micro behalve het verzenden van data (en controle van de handshakelijnen) ook nog andere dingen moet doen.

Hier gaat het om:

We hebben een fclk van 16 MHz

[Bericht gewijzigd door Marcel (5) op dinsdag 2 oktober 2007 22:03:18 (17%)]

Bij heel hoge snelheden is de kloksnelheid van de uart niet de beperking, maar de snelheid waarmee je de de data erin kan proppen, die programmaloopjes kosten ook tijd.

We lezen eerst de ADC uit, deze waarden gaan in een Array, vervolgens worden deze waarde in één keer uit het Array gelezen en verstuurd via de uart. Er wordt 16 keer een dataframe verstuurd (10-bits resolutie van 8 kanalen).

Effe snel in het datasheet gekeken:
Conversietijd 65 tot 125 microseconden, je gebruikt meerdere kanalen dus je moet switchen, in differential mode is dat 125 microseconden bij elkaar dus al 200 tot 300 microseconden per meting. Dat is dus maximaal 3000 tot 5000 metingen per seconde, dus maximaal 6kbyte tot 10kbyte data per seconde zonder extra software overhead. Waar maak je je druk om ? 250 kBit op de UART is voldoende.

ADC conversie is één onderdeel wat we nodig hebben, we zullen ook digitale uitgangen aansturen.

Denk je dat 1Mbit haalbaar is met deze uC en ftdi IC ?

De FTDI chip waarschijnlijk wel, ik dacht dat ik er wel 200kbyte/s mee gehaald had, maar dat was wel in combinatie met een CPLD, niet een microcontroller.
Volgens de datasheet is 1Mbit haalbaar, maar je software moet ook wel met die snelheid kunnen werken natuurlijk, dus dat is afhankelijk daarvan.

Wel is het zo dat als je handshaking gebruikt het ook goed gaat als de microcontroller of de PC (of USB lijn) even te druk is, het zenden of ontvangen stopt dan even en gaat later weer verder. Je hebt geen gegarandeerde 1Mbit dan meer natuurlijk maar dat heb je toch al niet over USB.

@JoWI: Volgens mij praat jij over snelheden, wij denken in vertragingen. Volgens onze berekeningen zal de ADC een vertraging van 2,1ms hebben (dus voordat hij alles heeft ingelezen) en de RS232 poort 1,5ms. We willen de data zo snel mogelijk op de PC hebben.

berekening:
- 8 x 260uS = 2,1ms (vertraging inlezen analoog)
- 2 frames van 11 bit per kanaal (10 bits resolutie)
- 22 bits * 8= 176bits
- 176bits/115200bps= 1,5ms vertraging RS232

Wat ga je dan op die PC draaien? Een real-time OS? Of linux? (ik mag hopen geen winshit).
Anders is je onderwerp redelijk zinloos...

windows

windhoos kan die snelheid niet aan dus ?

[Bericht gewijzigd door Marcel (5) op woensdag 3 oktober 2007 10:08:40 (70%)]

Winshit doet veel te veel andere dingen tussendoor. Responsetijden zijn daarmee nogal ondefinieerbaar -> hoge snelheid alleen leuk voor veel data.

Als ik zeg dat we de data met VB6 willen binnenhalen zal je wel lachen?

Gezien de dingen die je de micro allemaal moet doen ga je die snelheid toch niet halen.
Snelheid en vertraging zijn trouwens uitwisselbare begrippen: Als ik 1000 karakters per seconde verstuur is dat een "vertraging" van 1 milliseconde per karakter. Om snelheden van tientallen kilobytes per seconde te halen moet je toch al creatief in assembly programeren (door bijvoorbeeld de A/D conversie en serieele I/O tegelijkertijd te doen). Dus niet eerst alles binnen halen en dan verzenden.
Er zit trouwens nog een foutje in je berekening: per byte gebruik je 10 bits op de serieele link, niet 8, je vergeet het start- en stopb.

Als je VB gebruikt aan de windows kant: je gebruikt toch geen Basicvariant aan de MCU kant ?, dan kan je het helemaal vergeten.

Wij hebben 11 bits in 1 frame zitten (2 stopbits).

edit: we programmeren in AVR studio (C dus).

[Bericht gewijzigd door Marcel (5) op woensdag 3 oktober 2007 10:53:35 (32%)]

niks te lachen. waarom zou vb minderwaardig zijn dan iets anders ?

de boel wordt gebufferd in de communcation driver van windows. al wat je doet is de buffer uitlezen.

langs de microcontrollerkant heb je wel ene probleem.
je kan welsiwaar een hoge buadrate zetten , maar je moet de data nog kunnen aanleveren ook.

stel je draait op 1 megabaud. 8,n,1 dat betkente 10 bits per karaketer.

je moet dus 100.000 writes per seconde naar de sbuf kunnen doen om die pijp vol te duwen...

je kan je transmissie tijd verkorten door de boel te pipelinen.
je geeft op dat het 2.1 milliseconde duurt om de conversies te doen. en de transmissie duurt maar 1.5 milliseconde.

wel , steek de transmit routine in de idle time van de convertoren. dus terwijld e convertoren aan het converteren zijn stuur je het vorige pakket. daarmee ben je van de inter packet delay vanaf. de data stroomt dan op volle snelheid naar de pc ( even snel als de converter ze kan halen. )