Rätt micro...

[gunnerfeldt]

Hej,

Ni verkar ju kunna det här.
Jag håller på med ett projekt där jag via PC - USB (bulk transfer) läser/skriver 8 kbytes i sekunden till en 18F4550, som i sin tur delar upp det och kommunicerar via en 8 bits parallellbuss med 14 stycken 18F4520.

Kommunikationen måste hålla en fast hastighet. Var 40:e ms skickas 256 bytes ut/in från PC:n. Däremellan jobbar 18F4520:orna på med diverse ADC m.m.

Systemet funkar hyfsat som det är nu. Ca 2-3 gånger i minuten hackar det till och 1-2 paket med 256 bytes är "scramblat". Jag har inte felsökt utan lagt till en error check som kastar bort de transaktionerna.


Jag undrar om experterna kunde ge mig antingen ett: "Kör på, det verkar vettigt"
...eller "Oj oj, varför använder du inte en XXXXX som skickar XXXX över en XXXX buss"

Tacksam för kommentar. Fråga gärna om det är något jag glömt specifiera.

/Pelle Gunnerfeldt

[sodjan]

Hur "kör" du USB'n ? Eget device eller emulering av HID, COMport eller så ?
Helt egen programvara eller någon av de exempel/framework som MC erbjuder ?
Vad är det för programvara på PC sidan ? Är det enbart data *ut* från PC'n ?
"Hackar det till" mellan PC och 18F4550 eller mellan 18F4550 och 18F4520'orna ?
Sänds data om eller kan du bara kasta det utan att det gör något ?

> Jag undrar om experterna kunde ge mig antingen ett: "Kör på, det verkar vettigt"

Ganska omöjligt att svara på utan att veta vad det hela ska göra...

[gunnerfeldt]

Hmm.. det är svårt att med några enkla rader beskriva helheten.
Det är ett automationssystem till ett mixerbord som går på tidskod.

Jag använder WINusb drivaren.
Jag minns inte exakt, men författaren till "USB complete" har gjort några enkla API till .net funktioner som jag använder.

PICens firmware bygger på något "high bandwidth" exempel från microchip med dubbla buffrar.
Datan går både ut och in ur PC:n.

Var hackar det till?
Jag vet inte riktigt, jag gissar att USB rutinerna och parallellbussrutinerna krockar eller inte får nog med tid. Kanske att bulk transfer inte flyter så bra och behöver vänta och blir "orytmisk" ibland. Jag vet inte.

Jag sänder inte datan igen vid fel utan kastar bort den, det är inte hela världen. Men visst, kan jag lösa det så gör jag det såklart.


Det jag är mest osäker på är USB transfer protokollen. Isochronous verkar ju vara det jag ska använda men jag har inte den kompetensen (ÄN).
Även parallellkommunikation verkar vara omodernt, jag har dock inte lyckats komma upp i samma hastighet med seriell kommunikation.

Fortfarande flummigt?

/Pelle

[blueint]

USB är pollande, monodirektionel etc.. och behöver buffertar. Och Microsofts OS saknar snabb respons övh, så där behövs också buffertar.

Däremot kan förmodligen dom olika MCU:erna kommunicera sinsemellan utan problem.

[Icecap]

Det finns USB-kretsar som emulerar en COM-port men som egentligen har parallell dataåtkomst (FT245R), det borde väl vara grejen?

[sodjan]

Kan man programmera/kontrollera FT245R så mycket så att man
man styra parr-gränsnittet mot 14 st olika "mottagare" ?
Spontant känns det lite tveksamt.

[Icecap]

Den bit skulle "master-controllern" klara, jag tänkte att USB-kommunikationen kunde skötas utan fulhack...

[sodjan]

OK, så den skulle fortfarande finnas kvar. Nu med dubbla parr.interface,
ett mot FTDI kretsen och ett mot de 14 slavarna. Den stora skillnaden
blir, som jag ser det, att det går långsammare att få över USB datat.

Aja, det som saknas här just nu är en analys om *var* paketen "scramblas".
Är det under USB transfern eller är det i överföringen mot de 14 slavarna ?
Och om det är så att alla data skickas kontinuerligt, så kanske ett tappat
packet igentligen inte gör så mycket ? Vi vet för lite om hur det är tänkt
att fungera för att säga så mycket om det.

[ds77]

Kommunikationen måste hålla en fast hastighet. Var 40:e ms skickas 256 bytes ut/in från PC:n. Däremellan jobbar 18F4520:orna på med diverse ADC m.m.

Hastigheten sak väl fungera, men (och rätta mig gärna om jag har fel...) är inte USB ganska värdelöst om man måste skicka något inom en viss bestämd tid?

[sodjan]

Jo. Jag reagerade också på det där.
Å andra sidan finns ju ljudkort och likande som behöver ett
stadigt flöde av data, men det går ju att dölja pauser i flödet
genom att ha lämpliga buffertar och skicka större paket när
"linjen är öppen", så att säga, det totala flödet räcker sannolikt till.

Dock så sticker det ut lite, det där med "Var 40:e ms"...

[gunnerfeldt]

Ja. Jag håller med om att det skulle behövas en ordentlig analys för att hitta felet.

Projektet börjar bli stort och omfattande och jag måste acceptera att vissa delar inte blir 100%, tyvärr. Jag är själv och labbar på kvällar och helger.

Jag tror inte jag har något problem med USB kommunikationen.
I så fall att windowsdrivaren uppehålls ibland vilket leder till en "hickning" någon annanstans i ledet.

Jag har testat att låta PICen endast sköta USBn och skicka tillbaka mottagen data.
Om jag gör en loop och tajmar det i windows så blir det några cykler här och där som tar dubbla eller trippel tid.
Som jag tolkar specifikationen för "bulk transfer" så skadet ska vara så.
- Datan skickas så fort det går men utan timing-garantier, bra för mass storage o.s.v.

Men, men. Kanske om någon här hade gjort något liknande fast med audio eller midi som också måste strömma data. Det är inte det att jag är lat. Jag läser och läser och testar och labbar.


Men som sagt. Det funkar ok som det är, som användare märker man inte om en "frame" ligger kvar i sitt föregående läge någon enstaka gång.

Ibland blir man så isolerad och kör för fullt utan att veta att man är på fel spår, såklart så lär man sig massor av det. Forum är ju toppen för att för att bolla med virtuella arbetskamrater.

/Pelle

[gunnerfeldt]

Oj. Jag såg inte era sista inlägg medan jag skrev.

Precis vad varit inne på. Med bulk tr så får man ha fifo buffrar som är redo och tajma dem lokalt. Då kan jag nog utveckla det system jag har. Annars så använder audio sig av isochronous transfer och då blir det nya böcker att önska sig till jul...

Tack för att ni engagerar sig, det betyder enormt mycket!!!

/Pelle

[sodjan]

> Oj. Jag såg inte era sista inlägg medan jag skrev.

Märkligt, det var ju flera minuter sedan !
Syntes de inte när du gjorde "Förhandsgranska" ??
I så fall bör du anmäla det så att admins får kolla på det...

[gunnerfeldt]

Jorå, jag skriver och matar sjuka barn, tvättar, plockar ur diskmaskinen... RTOS