> Jag tror inte jag kan läsa och skriva data till programminne på en PIC16F877 ?
Right.
Och vad tror du att kapitlen som heter
"Reading the FLASH Program Memory" och
"Writing to the FLASH Program Memory"
handlar om ???
> Jag får kolla om det går att lösa i C med microC och låta kompilatorn gör jobbet.
Vilket "jobb" ?
Spela upp ljud med en PIC
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
> >Vilket "jobb" ?
> Att slippa läsa de kapitlerna du just nämner!
Lathet har aldrigt bidragit till att få något att fungera...
Spelar ingen roll vilket verktyg du använder, du kommer inte
långt utan att först tillbringa ett par timmar/dagar med att studera
och *FÖRSTÅ* databladet för det processor du tänker använda.
Om du inte (även om det krävs en hel del svett) till slut förstår
databladet, så är detta tyvärr nog ingenting för dig.
Sen, visst, om du hittar en C-kompilator som har inbyggt stöd för
Flash read/write, jag har inte en aning om hur det är med det,
så kanske det kan underlätta.
Om den inte har det, så får du ju i alla fall göra exakt samma sak
i C-koden som från assembler. Och då har du så att säga inte vunnit
något på att byta verktyg (i detta avseende).
Slutligen, angående mitt "dåliga ironiska svar"...
Tja, om du lägger upp bollen på straffpunkten, så är det svårt att
låta bli att klippa till...
> Att slippa läsa de kapitlerna du just nämner!
Lathet har aldrigt bidragit till att få något att fungera...
Spelar ingen roll vilket verktyg du använder, du kommer inte
långt utan att först tillbringa ett par timmar/dagar med att studera
och *FÖRSTÅ* databladet för det processor du tänker använda.
Om du inte (även om det krävs en hel del svett) till slut förstår
databladet, så är detta tyvärr nog ingenting för dig.
Sen, visst, om du hittar en C-kompilator som har inbyggt stöd för
Flash read/write, jag har inte en aning om hur det är med det,
så kanske det kan underlätta.
Om den inte har det, så får du ju i alla fall göra exakt samma sak
i C-koden som från assembler. Och då har du så att säga inte vunnit
något på att byta verktyg (i detta avseende).
Slutligen, angående mitt "dåliga ironiska svar"...
Tja, om du lägger upp bollen på straffpunkten, så är det svårt att
låta bli att klippa till...
Jag betvivlar inte alls att du kan detta område på dina fem fingrar. Men det betyder inte att du har kan svara hur som helst utan att få mothugg. Lat? Om du inte har märkte något så kan jag meddela att fick du ett ironisk svar tillbaka vid förra inlägget.
Byta verktyg? Jag har aldrig gjort något större projekt i varken i microC eller assembler tidigare. Så mycket nytt för mig och hoppades nu att få hjälp i detta forum?
Jo, det finns rutiner för Flash_read, Flash_whrite. I vilket kapitel det står under får du själv ta reda på.
mvh
Soolo
Byta verktyg? Jag har aldrig gjort något större projekt i varken i microC eller assembler tidigare. Så mycket nytt för mig och hoppades nu att få hjälp i detta forum?
Jo, det finns rutiner för Flash_read, Flash_whrite. I vilket kapitel det står under får du själv ta reda på.
mvh
Soolo
> I vilket kapitel det står under får du själv ta reda på.
Jag uttalade mig i generella termer, jag har ingen anledning
att studera dokumentationen för microC. Jag bara noterade vad
som kan vara bra att se upp för när man gör det. Men finns det
läsrutiner för Flash, så bör dom väl fungera, antar jag...
Jag uttalade mig i generella termer, jag har ingen anledning
att studera dokumentationen för microC. Jag bara noterade vad
som kan vara bra att se upp för när man gör det. Men finns det
läsrutiner för Flash, så bör dom väl fungera, antar jag...
-
JimmyAndersson
- Inlägg: 26586
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Lyfter upp den här tråden igen.
Någon som provat detta? (dvs BTc.)
Jag har inte testat än och inte heller hittat någon kod för att läsa av tabellen från asm-filen som skapas med programmet. Men det borde väl fungera ungefär såhär:
1) Kör en timer med samma hastighet som wav-filen.
2) Vid varje timer-interrupt så läser man av bit för bit i byten som RETLW lägger i W. Denna bit skickas till en utgång.
Rätt?
Någon som provat detta? (dvs BTc.)
Jag har inte testat än och inte heller hittat någon kod för att läsa av tabellen från asm-filen som skapas med programmet. Men det borde väl fungera ungefär såhär:
1) Kör en timer med samma hastighet som wav-filen.
2) Vid varje timer-interrupt så läser man av bit för bit i byten som RETLW lägger i W. Denna bit skickas till en utgång.
Rätt?
En sak som kan vara bra at tänka på.
När man genererar ljud på detta sätt genom att mata ut en "bit"
med jämna mellanrum så antar jag att det är rellativt viktigt
att bitarna kommer i en jämn ström.
D.v.s att om det skulle bli en liten extra fördröjning var 8'de
bit (eller 14'de eller 16'de om de läses från Flash), så skull det
kanske ge en störning (brum, brus eller "knäpp") i ljudet.
Så man bör nog skriva timer ISR'en på ett sådant sätt att *nästa*
bit alltid är färdig och kan matas ut direkt när interruptet inträffar.
D.v.s att man alltid har samma fördröjning mellan interrupt och att
biten på I/O pinnen uppdateras. Sedan låter man ISR'en plocka
fram nästa bit för nästa interrupt innan man gör retfie...
Om man gör tvärtom, d.v.s börjar ISR'en med att leta reda på biten,
så blir det svårare att få en jämn bit-ström utan "glitches" på pinnen.
När man genererar ljud på detta sätt genom att mata ut en "bit"
med jämna mellanrum så antar jag att det är rellativt viktigt
att bitarna kommer i en jämn ström.
D.v.s att om det skulle bli en liten extra fördröjning var 8'de
bit (eller 14'de eller 16'de om de läses från Flash), så skull det
kanske ge en störning (brum, brus eller "knäpp") i ljudet.
Så man bör nog skriva timer ISR'en på ett sådant sätt att *nästa*
bit alltid är färdig och kan matas ut direkt när interruptet inträffar.
D.v.s att man alltid har samma fördröjning mellan interrupt och att
biten på I/O pinnen uppdateras. Sedan låter man ISR'en plocka
fram nästa bit för nästa interrupt innan man gör retfie...
Om man gör tvärtom, d.v.s börjar ISR'en med att leta reda på biten,
så blir det svårare att få en jämn bit-ström utan "glitches" på pinnen.
Kollar på länken:
http://www.romanblack.com/picsound.htm
Man ser långa följder av 1'or och långa följder av 0'or...
Skulle ju säkert kunna komprimeras mera.
http://www.romanblack.com/picsound.htm
Man ser långa följder av 1'or och långa följder av 0'or...
Skulle ju säkert kunna komprimeras mera.
Är det långa sekvenser av 0:or och 1:or så går det säkert att komprimera. Prova t.ex RLL-kodning. Principen är rätt enkel. Istället för att tala om hur varje bit skall vara (0 eller 1) så innehåller datan antalet 0:or resp. 1:or mellan omslagen. T.ex en byte för nollor, en byte för ettor en för nollor o.s.v. Eftersom varannan bit skall vara 0 och varannan 1 så behövs egentligen inte den informationen utan bara längden på varje sekvens.
Sedan är det vissa saker man måste ta hänsyn till. T.ex att längsta sekvensen av 0 eller 1 måste gå att representera som det tal man lagrar (t.ex byte) eller får man lösa det på något annat sätt.
Sedan är det vissa saker man måste ta hänsyn till. T.ex att längsta sekvensen av 0 eller 1 måste gå att representera som det tal man lagrar (t.ex byte) eller får man lösa det på något annat sätt.
> Man ser långa följder av 1'or och långa följder av 0'or...
Var då ?
Och vad är "långa" ?
För att köra en RLL så bör det vara så pass långa sekvenser att
det blir *mindre* utrymme efter kodningen. Dessutom kan BTc bitströmmen
se ut precis hur som helst, så jag ser inte hur man praktiskt skulle kunna
separare en "längd-markör" från vanlig "BTc-data".
En *textfil* som enbart innehåller "1" eller "0" är naturligtsvis en helt annan sak.
De kan normalt komprimeras kraftigt...
Var då ?
Och vad är "långa" ?
För att köra en RLL så bör det vara så pass långa sekvenser att
det blir *mindre* utrymme efter kodningen. Dessutom kan BTc bitströmmen
se ut precis hur som helst, så jag ser inte hur man praktiskt skulle kunna
separare en "längd-markör" från vanlig "BTc-data".
En *textfil* som enbart innehåller "1" eller "0" är naturligtsvis en helt annan sak.
De kan normalt komprimeras kraftigt...
