Fujitsu SofTune C-problem, nu har jag gått sur... *LÖST*

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
Användarvisningsbild
Icecap
Inlägg: 26650
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Fujitsu SofTune C-problem, nu har jag gått sur... *LÖST*

Inlägg av Icecap »

Fujitsu FFMC16-LX MB90F583CA µC

Har ett projekt där jag måste överstiga 64k gränsen för programminne och då RAM finns i ett begränsat område bör det hela röra sig om den minnesmodell man i C kallar MEDIUM, alltså att data (RAM) befinner sig inom en given 64k block och att programmet befinner sig i ROM som sprids över 2 st 64k blockar.

Inget konstigt som sådan om det inte var för att det finns många texter som ska kunde skrivas ut till LCD'n. Utskriftrutinen till LCD fungerar perfekt och har gjort det länga, den består i en rutin som skriver ut en byte till LCD'n, skakar styrsignaler osv.

För att skriva ut strängar gör jag helt enkelt såhär:

Kod: Markera allt

void Send2LCD(char* Data)
  {
  while(*Data) Send_LCD_Char(*(Data++));
  }
Detta fungerar utmärkt och har gjort det genom tiderna. Jag har även testat att deklarera den såhär:
void Send2LCD(__far char* Data)
utan att det gjorde någon skillnad.

Ska det skrivas ut strängar som är fasta har jag varit tvunget att definiera dom i assembler då jag inte hittade något sätt att göra det i C som inte lämnade kvar en 32-bit pointer i RAM. Resultatet blev ju att det förvisso fungerade - men att RAM tog slut och det vill jag ju inte.

Alltså kommer det effektivt sett att bli så att jag har ett större antal texter (17,5kB) av typen:
Först har jag filer med texterna i formen:
const char Something_US[] = "Bla";
const char Something_UK[] = "Bla";
const char Something_DK[] = "Bla";
const char Something_FI[] = "Bla";
const char Something_SW[] = "Bla";
const char Something_FR[] = "Bla";
const char Something_SP[] = "Bla";
const __far char* SomeTextName[] = {Something_US, Something_UK[], Something_DK[], Something_FI[], Something_SW[], Something_FR[], Something_SP}; Denna tabell är alltså en tabell med pekare till dessa texter.

Varje text finns i 7 språk varför de ska kunde indexeras och totalt rör det sig om kanske 160 olika texter, var isär på 8 språk, det blir alltså en del. Men det finns plats i minnet för dessa samt program.

Om jag skriver ut något i RAM med sprintf till en buffer visas det alldeles fint med Send2LCD() men ska jag printa ut en ROM-text blir det skit av det hela. Alla texter är terminerat rätt med EOL (0x00) osv men ta mig tusan om programmet medger att jag kan hämta data från ROM! RAM befinner sig mellan 0x000000 och 0x0017FF medan ROM (flash) ligger på 0xFE0000 - 0xFFFFFF och jag känner inte för att börja med en massa trick för att kopiera från ROM till RAM i ASM för att sedan skriva ut skiten.

Så är det någon som har lite erfarenhet av Softune och hur fan man ska lösa detta problem?

Nu ska jag först se om jag kan skriva ut pekarens värde (ska ju vara en adress pekare) när jag i själva verket försöker skriva ut en ROM-text men är det någon med råd kan ni ju skriva under tiden.

EDIT: Jaha, nu klarnar det en aning... Adressen till ROM-texten är 0x00000000... Ska klura mer.
Senast redigerad av Icecap 29 oktober 2012, 22:12:56, redigerad totalt 1 gång.
dangraf
Inlägg: 530
Blev medlem: 9 juni 2003, 15:30:56
Ort: göteborg

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av dangraf »

Jag har ingen erfarenhet av större textmassor men funderar på om det inte går att komprimera texterna på något vis.

En eventuell lösning skulle vara att man gör ett script som har texten som input parameter och därefter genererar indexerade tabeller för att få ner textmassan..

Ofta innehåller ett språk upprepade ord.
t.ex

"Ät mer gröt"
"Ät mindre gröt"
"Gröt äter man"
1: Ät
2: mer
3: gröt
4: mindre
5: äter
6: man

mening 1: [1 2 3]
mening 2: [1 4 3]
mening 3: [3 5 6]

Det hela beror såklart på texten och hur man väljer att spara meningarna. Om man ska ha en 32 bitars pekare till varje litet ord kommer bara ord över 4 bytes att frigöra minne.
Men man skulle kunna lägga orden i "chunkar" så att man får en 32 bitars räknare med 8 el 16 bitars offset.

Detta kommer bli ganska rörigt det är därför jag förseslåt att man gör någon form av script som genererar text-kompirimeringen så att man slipper sätta sig in i systemet och flytta alla index om man råkat glömma en bokstav eller av annan anledning vill ändra på texterna i efterhand.
Användarvisningsbild
Icecap
Inlägg: 26650
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av Icecap »

Den lösning är ingen lösning alls!

Problemet är inte att packa in texterna + program i 64k när jag har 128k tillgängligt, det är att skriva ut de texter som finns i flash-minnet.

EDIT: Jag håller på att läsa igenom C programmeringsmanualen om just detta, sedan ska jag se om det går att skapa en C-deklaration som inte skapar dessa pekare i RAM, just nu är mitt enkla testcase ett problem på detta vis.
Användarvisningsbild
SeniorLemuren
Inlägg: 8427
Blev medlem: 26 maj 2009, 12:20:37
Ort: Kristinehamn

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av SeniorLemuren »

Finns det inte möjligheter till en liknande lösning i Softune som, som jag använde i microC?

Kod: Markera allt

//**************** RAM Saver LCD Text ************************
const char txt1[] = "Motor test";
const char txt2[] = "One rev. Right  ";
const char txt3[] = "One rev. Left   ";
const char txt4[] = "Motor Ok.       ";
.
.
.
.
char msg[17]; //declare array set 16 bytes of RAM aside for copying into

// copy const to ram string
char * CopyConst2Ram(char * dest, const char * src){
char * d ;
d = dest;
for(;*dest++ = *src++;)
;
return d;
}
.
.
.Lcd_Out_CP(CopyConst2Ram(msg,txt2));
}
Användarvisningsbild
Icecap
Inlägg: 26650
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av Icecap »

Det finns knappast någon anledning till att kopiera från ROM till RAM för att sedan skriva ut, under kopieringen har jag ju tillgång till varje byte och kan då likaväl skriva ut den direkt.

Jag har testat lite och skrev följande:

Kod: Markera allt

const char TestText1[] = "Text 1";
const char TestText2[] = "Text 2";
const char TestText3[] = "Text 3";
const char TestText4[] = "Text 4";

const char* TestText[] = {TestText1, TestText2, TestText3, TestText4};
Detta leder till att TestText[] skapar en tabell i RAM, den tabell är då 16 bytes stor och innehåller en pekare till varje text - och det är ju precis vad jag vill undvika. Och det som är konstigast är att tabellen ju först finns i ROM och sedan, vid start, kopieras från ROM till RAM. Då varje text refereras med en pointer till deras plats i ROM och då det fungerar bra att läsa därifrån direkt finns det alltså INGEN anledning till att kopiera från ROM till RAM alls.
Användarvisningsbild
SeniorLemuren
Inlägg: 8427
Blev medlem: 26 maj 2009, 12:20:37
Ort: Kristinehamn

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av SeniorLemuren »

Ja klart att bygger du en hel sträng av alla texter så blir det ingen vinst. I mitt fall kopieras ju bara (ex. const char txt1[]) från ROM till char msg[17] just när den skrivs ut, sedan hamnar nästa text i samma variabel för att skrivas. På det viset ligger det ju aldrig mer i RAM än vad som just skrivs på displayen för tillfället.
Användarvisningsbild
Icecap
Inlägg: 26650
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av Icecap »

Men nu verkar jag ha fått tag i något!

Kod: Markera allt

const char TestText1[] = "Text 1";
const char TestText2[] = "Text 2";
const char TestText3[] = "Text 3";
const char TestText4[] = "Text 4";

const char* const TestText[] = {TestText1, TestText2, TestText3, TestText4};
Denna ovanstående definition skapar inte en tabell i RAM, bara synd att det har hänt något med mitt testsystem så jag inte kan se resultatet just nu.
Skillnaden är alltså i den del med fet skrift:
const char* const TestText[] = {TestText1, TestText2, TestText3, TestText4};
dangraf
Inlägg: 530
Blev medlem: 9 juni 2003, 15:30:56
Ort: göteborg

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av dangraf »

jaha, jag missförstår väl problemet som vanligt.

Hur tänkte du att man ska använda sig av 16bits-adressen när minnesarean behöver 17 bitar för att man ska nå allt? det låter inte rimiligt

Sedan förstår jag inte heller varför pekarna hamnar i ramminnet. Skriver man dem som "const char" brukar de hamna i flash-minnet direkt för mig.
Ytterligare en sak som är oklar är vad som inte fungerar och vad som fungerar.. Du säger att om du använder dig av 32 bitar fungerar det men minnet blir fullt. Nu blir inte minnet fullt men det blir skit av allt. Är det för att du trixat med längden på adresserna eller är det för att du lagt allt i flash som const?

jag skulle börjat med att debugga programmet. Tittat i map-filen exakt på vilken adress i flash som texten ligger på och därefter följt koden och sett att det är just den adressen som stegas upp.
kan det vara en cast som går fel eftersom du deklarerar dina variabler som "const" men det syns inte i programmet som du kallar på?
/d
Användarvisningsbild
Icecap
Inlägg: 26650
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Re: Fujitsu SofTune C-problem, nu har jag gått sur...

Inlägg av Icecap »

Jag har kanske varit otydlig. CPU'n kan adressera 2MB, den har 128kB FLASH (ROM) mellan 0x00FE0000 och 0x00FFFFFF.

const char TestText1[] = "Text 1"; // Sparas direkt i FLASH
const char TestText2[] = "Text 2"; // Sparas direkt i FLASH
const char TestText3[] = "Text 3"; // Sparas direkt i FLASH
const char TestText4[] = "Text 4"; // Sparas direkt i FLASH

const char* TestText[] = {TestText1, TestText2, TestText3, TestText4}; // Denna tabell sparas såklart i ROM men kopieras till RAM vid den startrutin som ingår i Start.asm. Den innehåller alltså 4 st 32-bit pekare till platser i minnet och det är ju korrekt, problemet är att den sparar det i RAM. Men då tabellen ju skapas i ROM och kan läsas utan problem (som en __far char*) direkt från ROM finns det ju ingen jävla anledning att kompilern ska kopiera det till RAM - och den delen har jag ju löst nu.

EDIT: YES!!! Efter att ha testat en hel del ändrade jag till slut minnesmodellen till LARGE (för gud vet vilken gång) och nu fungerar det!
Skriv svar