Tjenare.
Är skitglad då jag precis lyckats få en 16F876A att skriva och läsa en 25AA256 eeprom via SPI =) Anledningen till detta är att jag vill fylla minnet med lite data (runt 28kbyte) som sen ska läsas.
Jag hade tänkt få över datan via PICens UART men har stött på problem. Enligt datablandet så är 25AA256s "Internal Write Cycle Time" 5ms, vilket skulle betyda runt 200baud att skicka datan. Men PIC:en stödjer bara ner till 300baud.
Tänker jag fel här eller finns det någon väg runt? Jag kan ju alltid fixa till något eget program på min PC som väntar på svar innan den skickar eller pausar lite imellan skickningarna, istället för att bara skicka ut all data direkt på serieporten. Men jag vill hålla det enkelt så mycket det går.
mvh/Christian
Skriva EEPROM i realtid.
-
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Ett alternativ är att vänta på två inkommna bytar från PC'n innan du genererar en writecycle på minnet. Du kan samla ihop ända upp till 64 bytes i stöten och få alla inskriva i minnet på sammanlagt 5 mS.
Detta går ju förståss inte att göra om det är viktigt att byterna verksligen flashas ner så fort dom kommer in
Detta går ju förståss inte att göra om det är viktigt att byterna verksligen flashas ner så fort dom kommer in
> Jag kan ju alltid fixa till något eget program på min PC som väntar på
> svar innan den skickar eller pausar lite imellan skickningarna,
Jo, det är väl så man ska/bör göra. Annars har du ju inte heller
någon kontroll på att datat har kommit fram.
> istället för att bara skicka ut all data direkt på serieporten.
Vad menar du med "direkt på serieporten" ?
> Men PIC:en stödjer bara ner till 300baud.
USART'en har ingen sådan undre gräns.
Det vettigaste verkar vara att skicka ett block data till PIC'en,
detta lagras i EEPROM'et och sedan skickar PIC'en en ACK till
PC'n som kan skicka nästa block.
Sen är det skillnad på 64 bytes och 64 bitar...
> svar innan den skickar eller pausar lite imellan skickningarna,
Jo, det är väl så man ska/bör göra. Annars har du ju inte heller
någon kontroll på att datat har kommit fram.
> istället för att bara skicka ut all data direkt på serieporten.
Vad menar du med "direkt på serieporten" ?
> Men PIC:en stödjer bara ner till 300baud.
USART'en har ingen sådan undre gräns.
Det vettigaste verkar vara att skicka ett block data till PIC'en,
detta lagras i EEPROM'et och sedan skickar PIC'en en ACK till
PC'n som kan skicka nästa block.
Sen är det skillnad på 64 bytes och 64 bitar...

Sodjan:
Inget undgår dig
cat data > /dev/ttyS0 är väl rätt enkelt att bara skicka ut datan på serieporten. Men fungerar det inte så får jag väl skriva ett litet program som väntar på ACK.
Till baudgeneratorn kollade jag bara tabellen i datablandet men om man kör efter formeln (på en 4MHz kristall) så blir det 4e6/(64(255+1))=244 och det är fortfarande för högt.
Men 64bytes åt gången löser det problemet.
Inget undgår dig

cat data > /dev/ttyS0 är väl rätt enkelt att bara skicka ut datan på serieporten. Men fungerar det inte så får jag väl skriva ett litet program som väntar på ACK.
Till baudgeneratorn kollade jag bara tabellen i datablandet men om man kör efter formeln (på en 4MHz kristall) så blir det 4e6/(64(255+1))=244 och det är fortfarande för högt.
Men 64bytes åt gången löser det problemet.
Fungerar och fungerar, det handlar väl mer om vilken säkerhet man vill ha i
överföringen. Med cat skickar man väl bara ut det utan kontroll över
hur det gick i andra änden. Är det OK, så visst...
Angående baudrate. Visst vid 4 Mhz ja, men det går att köra en PIC
hur långsamt som helst. Vad jag menade är att det inte finns någon
begränsning i USART'en som sådan, det är bara att köra PIC'en
tillräckligt långsamt. Men igentligen är det ointressant, för mig är det
självklart att man skall ha någon slags handskakning i överföringen.
Förresten, kan din ttyS0 används Xon/Xoff ? I så fall kan det vara
en lösning. Det är bara att PIC'en sänder Xoff innan EEPROM
skrivningen och en Xon efteråt. Och då skulle "cat" fungera oavsett
hastighet.
överföringen. Med cat skickar man väl bara ut det utan kontroll över
hur det gick i andra änden. Är det OK, så visst...
Angående baudrate. Visst vid 4 Mhz ja, men det går att köra en PIC
hur långsamt som helst. Vad jag menade är att det inte finns någon
begränsning i USART'en som sådan, det är bara att köra PIC'en
tillräckligt långsamt. Men igentligen är det ointressant, för mig är det
självklart att man skall ha någon slags handskakning i överföringen.
Förresten, kan din ttyS0 används Xon/Xoff ? I så fall kan det vara
en lösning. Det är bara att PIC'en sänder Xoff innan EEPROM
skrivningen och en Xon efteråt. Och då skulle "cat" fungera oavsett
hastighet.
Halvsovandes i sängen igår kom jag på att jag tänkt helt jäkla fel, 5ms väntan per byte blir ju runt 200 byte i sekunden, 300 baud avser ju i det här fallet något helt annat. Pinsamt 
Men jag greppade hunden och skrev ett program som ser till att det bli säker överföring istället, så har jag något hållbart för framtida bruk.

Men jag greppade hunden och skrev ett program som ser till att det bli säker överföring istället, så har jag något hållbart för framtida bruk.