Svenska ElektronikForumet

d99dan:

Det du söker kanske vore någon uC med inbyggd SPI som använder DMA (Direct Memory Access), men jag vet inte om det finns någon sådan. Det skulle ju avlasta processorn betydligt oavsett klocka. Bara peka ut en ~256 byte och trigga.

Annars tror jag det är meningslöst att försöka få en PIC under 40MHz och göra mycket om du skall ha en ständig trafik på 10Mbit, om du inte skall ha den som typ switch eller nåt.

Skall du göra en enkel webserver eller styra något över nätet, så duger det nog gott med en enklare PIC. Det räcker ju med 9600bps för att styra några servon med bra respons. Jag har också svårt att se många användningsområden för PIC med sån datamängd. Kanske kryptering/VPN eller?

Sedan får du ju också väga risken att det skickas data som du skall läsa av med 10Mbit också. Frågan är om buffern blir överskriven och du missar data, då blir det väl omsändningar och ännu segare. Känner dock inte till hur Ethernet funkar i det fallet, om det skickas en ack eller liknande efter varje byte, eller om det skickas hela paket.

Mats

Kaggen: ja det skulle naturligtvis underlätta mycket med DMA

I ethernet skickas väl hela paket och i det här fallet om man använder Microchips ethernet interface så har den en buffert på 8Kb har jag för mig

Jaja jag förstår nog inte riktigt varför ni inte vill ta till er en mer "Akademisk" frågeställning om prestandan på en PIC

Men kan ju göra ett nytt försök, ponera istället då att jag skickar en byte till SPI interfacet på PIC:en den tar ett beslut beroende på vad värdet är lägger ut någar värden på en I/O port läser ett värde från A/D omvandlaren. Sen 24 instruktioner senare så har den genererat 3bytes med data den ska skicka över SPI. Kommer den hinna med det kontinuerligt? Egentligen precis samma frågeställning

Och nu när jag sitter här och skriver så kom jag på en tillämpning som man kanske skulle kunna klara med ethernet och en enklare krets som en PIC VoIP telefon, Jag kommer inte riktigt ihåg vad det kräver för bandbredd men det är väl inte så mycket?

Det spelar nog ingen större roll för jag har bestämt mig för att skaffa ett Inerface och lite PIC:ar att leka med i vilket fall som helst, ja och en WISP får det väl bli, Jag skickar ett PM Sodjan

Tack för visat intresse

Ja, Ethernet chippet har en buffert så att processorn inte ska behöva
jobba i "ethernet-fart".

> jag förstår nog inte riktigt varför ni inte vill ta till er en mer "Akademisk" frågeställning om prestandan på en PIC

Och du förstår nog inte riktigt varför det inte går att ge mer en ett "akademiskt" svar på en "akademisk" fråga.
Var konkret så blir det säkert mer konkreta svar.

> ponera istället då att jag skickar en byte till SPI interfacet på PIC:en

Från din PIC kod eller "utifrån" ? Kör du SPI interfacet som master eller slave ?
Är det utifrån och SPI interfacet är master, så *läser* du en byte, inte skickar.
För att *skicka* en byte utifrån till PIC'ens SPI interface, måste den vara slave.

> Sen 24 instruktioner senare...

Senare än vadå ? Efter att ADC'n är klar ?

> så har den genererat 3 bytes med data den ska skicka över SPI. Kommer den hinna med det kontinuerligt?

Här blir jag väldigt osäker. Vad skall vara "kontinuerligt" ? SPI kommunikationen ?
Eller hela kedjan SPI -> beslut -> I/O -> ADC -> SPI ?
Och vad menas igentligen med kontinuerligt ?
Visst kan man köra kontinuerligt, men frågan är väll hur lång tid det tar ?
Skall allt det du har beskrivit ske på de 24 instruktionern ?

> Egentligen precis samma frågeställning

Fast förrut handlade det om Ethernet kommunikation, den är helt borta här.
Så inte är det precis samma fråga !?

Om de 3 bytesen skall skickas över Ethernet, så tillkommer det ju en
den extra för att "paketera" i ett Ethernet paket (av något slag). Det är
möjligt att en del av detta kan förberedas i Ethernet chippet, jag har inte
studerat det så noga...

> Jag skickar ett PM Sodjan

Och du har fått svar...

Jag skulle rekommendera någon ur PIC18 familjen för få någon fart, sedan går det väl att använda fler än en enchipsdator för hinna med flera saker samtidigt.

PIC18 ger lite mer fart, jo, men inte så väldigt mycket mer.

> sedan går det väl att använda fler än en enchipsdator för hinna med flera saker samtidigt.

Jag har inte sett något krav på att göra flera saker samtidigt här.
Snarare att det är 3-4 olika saker som måste göras i sekvens, och
då hjälper inte flera processorer speciellt mycket...

Från din PIC kod eller "utifrån" ? Kör du SPI interfacet som master eller slave ?
Är det utifrån och SPI interfacet är master, så *läser* du en byte, inte skickar.
För att *skicka* en byte utifrån till PIC'ens SPI interface, måste den vara slave.

Spelar det någon roll för prestandan? Om den är master eller slave styr väl bara vem som får initiera kommunikation

Fast jag kan nog hålla med om att det kanske inte blev mer klart här men jag tänkte så här

1. Det skickas en byte till picen alltså är den slave
2. picen behandlar data på något sätt i 24 instruktioner
3. den externa enheten som skickade byten läser nu 3 bytes med svar så då fortsätter den väl vara slave

och med kontinuerlig så menade jag att man skickar en ny byte för att så att säga börja om, och det är ju klart att man kan men frågan är ju då när. Det är ju då som det blir egenligen samma frågeställning tar det 24intruktioner för att skicka 3bytes innan man kan ta emot 1 så har man ju en utilisation av SPI interfacet på 50%

Sodjan ethernet delen var ingen "central" del i frågan utan den handlade om SPI interfacet och hur stor del av bandbredden som gick att använda i en PIC. Att man får svårt att skicka/ta emot i bit varje klocka verkar ju rimligt men hur mycket man faktsikt klarar av beror ju väldigt mycket på dels hur stor buffert man har till SPI:n på PIC:en och dels overheaden för en interupt. Man får väl förutsätta att SPI delen bör vara avbrotts styrd.

Jag får väl försöka testa när jag har fått igång en PIC men det blir nog svårt när jag bara har en med SPI stöd.

Jag tog en PIC i mängden (18Fxx2 serien) och 10 Mbit/s är högsta SPI hastighet.
Om vi räknar med 2 extra bitars "overhead" så blir det 1 byte/us.
Att ta imot 1 och skicka 3 bytes tar alltså 4 us.
Vid 40 Mhz körs 10 instruktioner/us, eller 40 instruktioner för 4 us.
Tillkommer overhead för interrupt m.m.
Sen beror det även på om du kan köra någon del av beräkningarna
samtidigt som SPI interfacet t.ex sänder föregående 3 resultat-bytes.

Ovanstående är oerhört teoretiskt, det förutsätter ju t.ex att den andra
SPI enheten också kan köra 10 Mbit/s.

> tar det 24intruktioner för att skicka 3bytes innan man kan ta emot 1 så
> har man ju en utilisation av SPI interfacet på 50%

Här förstår jag inte riktigt hur du räknar. Var kommer 50% från ??
Det finns ingen direkt koppling mellan utnyttjandegrad av SPI interfacet
och belastningen på själva processorn, de jobbar ju till stor del
oberoende av varandra.

> frågan utan den handlade om SPI interfacet och hur stor del av
> bandbredden som gick att använda i en PIC.

SPI interfacet ska väl gå att köra nära 100%, om du inte behöver
göra något mer i processorn.
Kör SPI interfacet långsamt så blir det enklare att köra 100%

Det är helt omöjligt att svara på utan en bättre analys, d.v.s genom att
räkna instruktionscykler för olika saker.

> hur stor buffert man har till SPI:n på PIC:en

Det finns ingen speciell "buffert" i hårdvaran. Det är ett register för att sända
och ett för att ta imot.

> Man får väl förutsätta att SPI delen bör vara avbrotts styrd.

Ja, om man vill. Det blir "snyggast" kod så, men i extrema fall så är
det inte säkert att det blir snabbast...

> Här förstår jag inte riktigt hur du räknar. Var kommer 50% från ??
> Det finns ingen direkt koppling mellan utnyttjandegrad av SPI interfacet
> och belastningen på själva processorn, de jobbar ju till stor del
> oberoende av varandra.

Jo fast man får ju en stor overhead när man bara kan skriva 1 byte i taget i registret om det ska skötas av en interupt så blir det antagligen väldigt lite tid kvar till något annat

Som skapare av tråden så tycker i allafall jag att saken är utedd, jag funderade ju mest på om en PIC var tillräcklig för att klara av kommunikation över ethernet. Och slutsatsen får väl bli att ja det är den, om det handlar om lagom små datamängder Vi får väl se men jag kanske får anledning att återkomma med mer konkreta frågor när blir dags att få igång en PIC

Din slutsats ("Det beror på...") verkar väl ganska rätt...