Bakgrund:
Då har jag köpt mig ett "FRAM" (fabr. Ramtron) med SPI gränssnitt efter tipps jag fick i en tidigarre tråd. Jag får det dock inte riktigt att gå ihop. Har kopplat och programerat halva dagen uten någon riktig framgång.
Kommunikations-sättet som gäller är PICen som master. Klockpulserna genereras alltså av min PIC. Använder (förtås?) MSSP-modulen.
Frågor:
1. Hur beter sig klock-utgången på PICen när man sänt en byte? Fortsätter den att generera klockpulser för att kunna klocka in data från FRAMet? Hur många pulser?
2. Har jag förstått det rätt om jag säger att sändningen av en byte ska startas en instruktionscykel efter att skrivning till SSPBUF genomförts? (Förutsatt att SSPCON och SSPSTAT är korrekt inställda)
3. Tycker att informationen som ges i PIC-databladet kunde vart mer utförlig och hittar inte mycket på PIClist eller google. Någon som har något tipps på ytterligare dokument som hanterar SPI på PIC16xxx?
Jag har alltså läst igenom SPI-sidorna i manualen mer än en gång utan att kunna uttyda något riktigt svar på mina frågor. Det är ju ganska så elementära frågor så jag antar nästan att det är något jag missat, som någon av er kunde upplysa mig om.
Ha det bra!
/Tottish
Problem med/Frågor om SPI. PIC16f886 *uppdaterad*
Problem med/Frågor om SPI. PIC16f886 *uppdaterad*
Senast redigerad av Tottish 16 oktober 2007, 22:09:38, redigerad totalt 1 gång.
Vilket Ramtron device är det ?
1. SPI enheten läser och skriver samtidigt. Om datat kommer efter "kommandot"
så får man skriva ut något dummy data för att få in det.
2. Just *1* instruktionscykel tror jag inte. Hur kom du till det ?
3. Midrange Reference Manual, kanske.
Man notera att databladet enbart beskriver hur SPI fungerar just på PIC.
Det är *INTE* avsett för att lära ut SPI i sig.
Men en snabb search på microchip gav bl.a :
http://ww1.microchip.com/downloads/en/A ... 01006a.pdf
Section 17 i denna :
http://ww1.microchip.com/downloads/en/D ... 33023a.pdf
har lite mer info, speciellt section 17.3.3.
Och när du ända har den framme, printa gärna ut sektion 19, det är en
mycket bättre beskrivning av instruktiossettet än vad som finns i databladen.
EDIT: 33023 *är* alltså "Midrange Reference Manual". Det blev lite otydligt...
1. SPI enheten läser och skriver samtidigt. Om datat kommer efter "kommandot"
så får man skriva ut något dummy data för att få in det.
2. Just *1* instruktionscykel tror jag inte. Hur kom du till det ?
3. Midrange Reference Manual, kanske.
Man notera att databladet enbart beskriver hur SPI fungerar just på PIC.
Det är *INTE* avsett för att lära ut SPI i sig.
Men en snabb search på microchip gav bl.a :
http://ww1.microchip.com/downloads/en/A ... 01006a.pdf
Section 17 i denna :
http://ww1.microchip.com/downloads/en/D ... 33023a.pdf
har lite mer info, speciellt section 17.3.3.
Och när du ända har den framme, printa gärna ut sektion 19, det är en
mycket bättre beskrivning av instruktiossettet än vad som finns i databladen.
EDIT: 33023 *är* alltså "Midrange Reference Manual". Det blev lite otydligt...
Sodjan
"Vilket Ramtron device är det ?"
FM25640G (Köpt på ELFA)
"2. Just *1* instruktionscykel tror jag inte. Hur kom du till det ?"
Tycker mig ha läst något i stil med "data is transfered immidiately after a byte is written to SSPBUF". Hittar det inte nu och det är fullt möjligt att jag läst/minns fel. Nåja, om det tar några (eller många) cykler till spelar ingen roll för den kod jag skrivit. Det viktiga är att jag inte missat att göra något för att starta sändningen.
"Det är *INTE* avsett för att lära ut SPI i sig."
Det har jag förstått. Har satt mig in i SPI på annat håll. Databladet till FRAMet som jag köpt var faktiskt mycket utförligt och beskrev kommunikationen på ett bra sätt.
Jag har dessutom mekat ihop en adapter till FRAMet, som bara fanns i SMD-kapsel, som även den kan vara en felkälla. Mäter dock upp "vettiga" värden på den med multimetern.
Tack så mycket för svaren och länkarna, ska genast tiita på dem. Ser fram emot lite mer detaljerad läsning angående SPI-hanteringen i PIC.
MVH
/Tottish
Edit:
"Men en snabb search på microchip gav bl.a :
http://ww1.microchip.com/downloads/en/A ... 01006a.pdf "
Hittade också den, men den var ju avsedd för PIC18 så jag tänkte att det inte var så relevant men man kanske skulle ta en kik på den med om det fortfarande inte klaffar efter att ha läst det andra dokumentet.
"Vilket Ramtron device är det ?"
FM25640G (Köpt på ELFA)
"2. Just *1* instruktionscykel tror jag inte. Hur kom du till det ?"
Tycker mig ha läst något i stil med "data is transfered immidiately after a byte is written to SSPBUF". Hittar det inte nu och det är fullt möjligt att jag läst/minns fel. Nåja, om det tar några (eller många) cykler till spelar ingen roll för den kod jag skrivit. Det viktiga är att jag inte missat att göra något för att starta sändningen.
"Det är *INTE* avsett för att lära ut SPI i sig."
Det har jag förstått. Har satt mig in i SPI på annat håll. Databladet till FRAMet som jag köpt var faktiskt mycket utförligt och beskrev kommunikationen på ett bra sätt.
Jag har dessutom mekat ihop en adapter till FRAMet, som bara fanns i SMD-kapsel, som även den kan vara en felkälla. Mäter dock upp "vettiga" värden på den med multimetern.
Tack så mycket för svaren och länkarna, ska genast tiita på dem. Ser fram emot lite mer detaljerad läsning angående SPI-hanteringen i PIC.
MVH
/Tottish
Edit:
"Men en snabb search på microchip gav bl.a :
http://ww1.microchip.com/downloads/en/A ... 01006a.pdf "
Hittade också den, men den var ju avsedd för PIC18 så jag tänkte att det inte var så relevant men man kanske skulle ta en kik på den med om det fortfarande inte klaffar efter att ha läst det andra dokumentet.
2. OK, det stämmer. Men SPI clockan kan ju vara betydligt långsammare än
PIC'en clocka (beroende på hur man har konfigurerat SPI), så om det är 1
*instruktionscykel* eller inte beror ju väldigt mycket på. Man annars är det
korrekt att man inte behöver göra något mer än att skriva till SSPBUF.
I fallat med ett FRAM (eller något annat SPI minne) så skriver man ju först
att "kommando" för att läsa minnet. Sedan får man skicka dummy data,
minnet bryr sig inte om vad som kommer in på DI ända tills man kör /CS
hög, vilket avslutar läs operationen och den börjar lyssna på DI igen.
Så man kan läsa ut data från minnet med full SPI hastighet sekvensiellt från
den startadress man angav i läs-kommandot.
> som bara fanns i SMD-kapsel,
Jahaja, där ser man, det var ett tag sedan jag kollade på Ramtron. Trist
om de helt har skippat DIP. Jag har ett antal samples liggandes i DIP,
jag kunde ha skickat över ett att labba med...
> Ser fram emot lite mer detaljerad läsning angående SPI-hanteringen i PIC.
I grunden är ju det som PIC'en gör ganska enkelt. Problemet är istället
att många moderna SPI kretsar är väldigt komplexa (titta t.ex på Maxims
PWM-kretsar för LED drivning, massor av olika register för att få det att
fungera) och det är där problemen ligger. Men, minneskretsar hör sannolikt
till den enklare seriella typen av kretsar....
PIC'en clocka (beroende på hur man har konfigurerat SPI), så om det är 1
*instruktionscykel* eller inte beror ju väldigt mycket på. Man annars är det
korrekt att man inte behöver göra något mer än att skriva till SSPBUF.
I fallat med ett FRAM (eller något annat SPI minne) så skriver man ju först
att "kommando" för att läsa minnet. Sedan får man skicka dummy data,
minnet bryr sig inte om vad som kommer in på DI ända tills man kör /CS
hög, vilket avslutar läs operationen och den börjar lyssna på DI igen.
Så man kan läsa ut data från minnet med full SPI hastighet sekvensiellt från
den startadress man angav i läs-kommandot.
> som bara fanns i SMD-kapsel,
Jahaja, där ser man, det var ett tag sedan jag kollade på Ramtron. Trist
om de helt har skippat DIP. Jag har ett antal samples liggandes i DIP,
jag kunde ha skickat över ett att labba med...
> Ser fram emot lite mer detaljerad läsning angående SPI-hanteringen i PIC.
I grunden är ju det som PIC'en gör ganska enkelt. Problemet är istället
att många moderna SPI kretsar är väldigt komplexa (titta t.ex på Maxims
PWM-kretsar för LED drivning, massor av olika register för att få det att
fungera) och det är där problemen ligger. Men, minneskretsar hör sannolikt
till den enklare seriella typen av kretsar....
Framgång! Har lyckats ta emot data från FRAMet! Använde kodexemplet från dokumentet som Sodjan länkade till ovan. Vet inte vart i min kod som det felade eller om det rent av kan vara att jag använde högsta överförings-hastigheten, till skillnad från exemplet. Jag har i alla fall lyckats göra en läsning av statusregistret i FRAMet. Dock inte riktigt det värde som jag förväntade mig. Nåja, kanske nåt småfel i initieringen av SPI eller ett feltänk av undertäcknad. Det viktiga är att den lever och att min adapter antagligen fungerar som den ska. Hinner tyvärr inte undersöka det hela närmare just nu. Får bli ikväll eller imorgon.
Varför måste man jobba? Ja just ja, för att ekonomiskt kunna stödja sina hobbys. =)
Tack igen Sodjan, du=guld.
Ha en strålande dag!
/Tottish
---------------------------------------------------------------------------------
Update:
Bakslag. Det visade sig att jag inte alls fått någon data från FRAMet. Det var bara mitt terminalprogram som skriver ut h'00' som en punkt. Punkten i ASCII var inte helt olik den data jag väntade mig av FRAMet och jag trodde därför att jag hade lyckats men det visade sig alltså att SSPBUF var tom (h'00') när den lästes. =(
Jag har i alla fall städat upp koden ordentligt, mätt med multimeter och lyckats isolera problemet. Eller åt minstone ett av dom.
FRAMet sänder inte ut någon data. SerialOut på FRAMet håller sig i "Hi-Z". Jag kan alltså styra den som jag vill med ett svagt pullup/pulldown-motstånd trots att jag sänt en OP-code som torde få FRAMet att sända ut data. I databladet för FRAMet står:
"Serial Output: SO is the data output pin. It is driven during read cycles and remains hi-Z at all other times including when HOLD\ is low."
Slutsats: FRAMet godtar inte den OP-code jag sänder.
Klock-linan verkar ticka på som den ska och jag mäter också upp rimliga värden på DataOut från PICen. Alla mätningar har skett med multimeter och "loopad sändning". ChipSelect blir låg innan sändnings-cykeln inleds och blir hög när den slutförts. Allt enligt databladet.
Så: Vad kan det här vara? Fel i min kod på initieringen av MSSP trots att jag gått igenom den _många_ gånger är så klart en möjlighet. Tror inte på felkoppling.
Sodjan: Du råkar inte ha någon gammal kod från din tid med FRAM liggandes som du vet har fungerat? Protokollet lär ju inte ha förändrats nämnvärt antar jag.
Kanske skulle ta och köpa loss några av dina FRAM så jag kunde utesluta min adapter i alla fall. De är ju inte jättedyra och frakt till Oslo lär väl inte bli någon förmögenhet det heller.
MVH
/Tottish
--------------------------------------------------------------------------------
Nu tror jag att det är under kontroll. Lägg inte nån energi på långa svar nu för jag tror det funkar... återkommer....
Jodå! En timme senare så flyter det på som aldrig førr! Bestæmde mig før att testa en sissta møjlighet innan jag gick och lade mig igår. Jag provade det andra av FRAMets två "stødda" SPI-modes (Clock idle state: low) och vips så mætte jag upp en annan potential på SO-pinnen. FRAMet hade alltså tagit emot kommandot!
Några timmars labbande nu på morgonen ledde till att jag fritt kunde skriva och læsa från FRAMet. Vet fortfarande inte vad som gick snett med det førsta "SPI-mode:et" (med klockan låg vid inaktivitet). Jag valde detta mode från børjan eftersom de flesta av databladets bilder var ritade på detta vis. Alla utom exemplet med det andra modet, faktiskt.
Kanske tar och førsøker få igång det andra SPI-modet också i utbildnings-syfte men just nu så kænns det inte så lockande, nær allt funkar som det ska.
Så det var væl den hær tråden det! Jag har lært mig massor och ser dubbelriktad kommunikation via SPI som ett stort framsteg! Tack før att du hjælpt mig att bli en bættre programerare (igen) Sodjan! Insåg just att du ær den enda førutom trådskaparen som varit aktiv i den hær tråden =).
Tack och Hej!
/Tottish
Varför måste man jobba? Ja just ja, för att ekonomiskt kunna stödja sina hobbys. =)
Tack igen Sodjan, du=guld.
Ha en strålande dag!
/Tottish
---------------------------------------------------------------------------------
Update:
Bakslag. Det visade sig att jag inte alls fått någon data från FRAMet. Det var bara mitt terminalprogram som skriver ut h'00' som en punkt. Punkten i ASCII var inte helt olik den data jag väntade mig av FRAMet och jag trodde därför att jag hade lyckats men det visade sig alltså att SSPBUF var tom (h'00') när den lästes. =(
Jag har i alla fall städat upp koden ordentligt, mätt med multimeter och lyckats isolera problemet. Eller åt minstone ett av dom.
FRAMet sänder inte ut någon data. SerialOut på FRAMet håller sig i "Hi-Z". Jag kan alltså styra den som jag vill med ett svagt pullup/pulldown-motstånd trots att jag sänt en OP-code som torde få FRAMet att sända ut data. I databladet för FRAMet står:
"Serial Output: SO is the data output pin. It is driven during read cycles and remains hi-Z at all other times including when HOLD\ is low."
Slutsats: FRAMet godtar inte den OP-code jag sänder.
Klock-linan verkar ticka på som den ska och jag mäter också upp rimliga värden på DataOut från PICen. Alla mätningar har skett med multimeter och "loopad sändning". ChipSelect blir låg innan sändnings-cykeln inleds och blir hög när den slutförts. Allt enligt databladet.
Så: Vad kan det här vara? Fel i min kod på initieringen av MSSP trots att jag gått igenom den _många_ gånger är så klart en möjlighet. Tror inte på felkoppling.
Sodjan: Du råkar inte ha någon gammal kod från din tid med FRAM liggandes som du vet har fungerat? Protokollet lär ju inte ha förändrats nämnvärt antar jag.
Kanske skulle ta och köpa loss några av dina FRAM så jag kunde utesluta min adapter i alla fall. De är ju inte jättedyra och frakt till Oslo lär väl inte bli någon förmögenhet det heller.
MVH
/Tottish
--------------------------------------------------------------------------------
Nu tror jag att det är under kontroll. Lägg inte nån energi på långa svar nu för jag tror det funkar... återkommer....
Jodå! En timme senare så flyter det på som aldrig førr! Bestæmde mig før att testa en sissta møjlighet innan jag gick och lade mig igår. Jag provade det andra av FRAMets två "stødda" SPI-modes (Clock idle state: low) och vips så mætte jag upp en annan potential på SO-pinnen. FRAMet hade alltså tagit emot kommandot!
Några timmars labbande nu på morgonen ledde till att jag fritt kunde skriva och læsa från FRAMet. Vet fortfarande inte vad som gick snett med det førsta "SPI-mode:et" (med klockan låg vid inaktivitet). Jag valde detta mode från børjan eftersom de flesta av databladets bilder var ritade på detta vis. Alla utom exemplet med det andra modet, faktiskt.
Kanske tar och førsøker få igång det andra SPI-modet också i utbildnings-syfte men just nu så kænns det inte så lockande, nær allt funkar som det ska.
Så det var væl den hær tråden det! Jag har lært mig massor och ser dubbelriktad kommunikation via SPI som ett stort framsteg! Tack før att du hjælpt mig att bli en bættre programerare (igen) Sodjan! Insåg just att du ær den enda førutom trådskaparen som varit aktiv i den hær tråden =).
Tack och Hej!
/Tottish
