PIC16F628A - data past niet in RAM

Ik ben bezig met een simpele DDS LFO die gebruikmaakt van een PIC16F628A. Uiteraard heb ik hiervoor een aantal lookup-tables gemaakt voor de verschillende waveforms. Ik heb nu een sinus, een zaagtand (ramp-up) en een blokgolf erin zitten. Elke lookuptable heeft 25 samples (chars). Als ik dit compile wordt er 48,2% van de dataspace gebruikt. Echter, wanneer ik een vierde lookup-table toevoeg, krijg ik ineens de melding van de HI-TECH compiler:

Error [1254] double.c; 55. could not find space (100 bytes) for data block

Wat ik nogal vreemd vind, bij drie lookup-tables wordt er (bijna) de helft gebruikt, maar wanneer ik dan een vierde tabel toevoeg past het ineens niet meer? Kan het niet komen doordat PICs gebruik maken van banks in het geheugen? Of wordt dit gewoon door de compiler geregeld? Wie helpt me uit de brand? :)

Ik ken die PIC en compiler niet hoor, maar kun je die compiler niet zo ver krijgen dat hij die tabellen in het flash zet in plaats van in RAM? Ik neem tenminste aan de je ze in run-time niet hoeft te veranderen.

Probeer het keyword const eens. Dan weet ie dat de waardes niet veranderen en het in program memory (rom) mag.

Klopt, maar dat is geen probleem voor een lookup table.

Je moet volgens mij voordat je ook maar iets met die data gaat doen eerste de data in het RAM zetten. Kost wat extra processingtime maar het scheelt heel veel RAM.

Ik doe hetzelfde als ik veel verschillende strings heb, voor op een LCD.
http://shibuvarkala.blogspot.com/2009/02/how-to-use-rom-for-storing-da…

Edit: waarom gebruik je lookuptables voor een waveform? Dat kan toch perfect met een functie? De zaagtand en blokgolf zeker weten, en de sinus ook wel met math.h library.

[Bericht gewijzigd door Neen op (19%)]

de blokgolf en zaagtand kun je inderdaad eenvoudig berekenen. Voor de zaagtand zou je kunnen kijken naar het Bresenham lijn algoritme, en voor de sinus naar het Bresenham circle algoritme.

Hmm... wel interessant dit projectje.

DDS LFO betekent? ... Low Frequency Oscillator..?

Hoe verzorg je de timing? Ik neem aan dat je instelbare frequenties hebt.

Lijkt me leuk om ook zo'n ding te maken.

Ik heb ook eens ooit zoiets gemaakt, zelfde melding denk ik... het er toen constanten van gemaakt zoals RoelA eerder al zei, geen problemen meer mee gehad.

static const unsigned char

en ineens had ik RAM geheugen te over!
(die static is normaal niet eens nodig)

Ah, met const ervoor werkt het idd. Heb nu maar 8% RAM gebruikt :) Alleen dan blijft de vraag nog, hoe het kan dat ie (schijnbaar) maar 50% van de data-space kan gebruiken...

Op 12 augustus 2009 19:50:40 schreef Neen:
Hmm... wel interessant dit projectje.

DDS LFO betekent? ... Low Frequency Oscillator..?

Hoe verzorg je de timing? Ik neem aan dat je instelbare frequenties hebt.

Lijkt me leuk om ook zo'n ding te maken.

Het is idd een low frequency oscillator. Ik ben bezig om een tremolo (gitaar-effect) te bouwen, hierbij moduleer je het volume van het gitaarsignaal met (meestal) een sinus. Maar mijne kan dan dus ook met een zaagtand etc. moduleren.

Nu heb ik eigenlijk maar ooit 10 minuten met hi-tech gewerkt, maar maakt hij geen .map file aan? Waarin je dus precies kunt zien welke variable en functie op een stukje geheugen staat?

Iedere moderne compiler maakt zoiets :)

Op 12 augustus 2009 20:27:35 schreef JER00N:
Ah, met const ervoor werkt het idd. Heb nu maar 8% RAM gebruikt :) Alleen dan blijft de vraag nog, hoe het kan dat ie (schijnbaar) maar 50% van de data-space kan gebruiken...

De RAM van de meeste PICs is niet aaneengesloten. Het kan dus zijn dat de compiler geen 100 aaneengesloten bytes RAM meer kan vinden, maar wel nog 3 keer 50 bytes (als hij op die manier zou zoeken).

Ook: weet je zeker dat de versie van de compiler die jij gebruikt alle RAM kan benutten?

Op 12 augustus 2009 21:55:28 schreef Wouter van Ooijen:
[...]

De RAM van de meeste PICs is niet aaneengesloten. Het kan dus zijn dat de compiler geen 100 aaneengesloten bytes RAM meer kan vinden, maar wel nog 3 keer 50 bytes (als hij op die manier zou zoeken).

Ook: weet je zeker dat de versie van de compiler die jij gebruikt alle RAM kan benutten?

Dat zou het inderdaad kunnen verklaren ja (weet niet hoe ik dit kan controleren).

De compiler is de HI-TECH C compiler die meegeleverd wordt met MPLAB. Het is wel de Lite-versie, maar ik kan er niet uit afleiden dat je maar een bepaald deel van het RAM kan gebruiken (het is geen demo-versie of zo).

int sin()
{
   static s16 x=0x4000;
   static s16 y=0;

   x -= y >> 5;
   y += x >> 5;
   return y;
}

Deze geeft geloof ik zo'n 128 samples van de sinus met waardes tussen -0x4000 en +0x4000.... Als je de shift kleiner maakt, wordt ie iets grover en minder nauwkeurig. Hoef je ze niet op te slaan in een tabel....
Even getest... na ongeveer 200 waardes begint ie overnieuw. Zal wel ongeveer 64*PI zijn.

[Bericht gewijzigd door rew op (12%)]