Problem med MPLab HI Tech C vid byggande av String

[Baloo]

Har nyligen börjat med C efter lite råd härifrån. Allt har gått fint. Håller på med ett program för att lägga text på en 40x2 raders display som ska sättas i mitt brevinkast i dörren.
Har skrivit i ordning alla funktioner för att hantera displayen och har nu börjat med att hantera texten. Jag har ett par texter i programmet och ville kunna kolla hur många tecken det finns i en sträng. Alltså la jag till string.h.

När jag kompilerar är inga fel, men när jag bygger programmet gnäller den på att den inte hittar två words i BANK0.

Kod: Markera allt

/Here is the main program
void main(void)
{
	int StrLength;
	char i, Xpos;
	
	Init();			//Initiate the PIC

	delay_ms(100);
	
	LCDInit();

// Here starts the main program loop
	

	
	StrLength = strlen (TextRowOne);

Felmeddelandet som blir är:
HI-TECH PICC-Lite COMPILER (Microchip PICmicro) V9.60
Copyright (C) 1984-2006 HI-TECH SOFTWARE
Error [593] ; . can't find 0x2 words (0x2 withtotal) for psect "code_ptr" in segment "BANK0"

Kommenterar jag ut raden med StrLength så funkar det. Alltså nåt knas med strlen.

Kod: Markera allt

Memory Usage Map:

Program space:
    CODE                 used    AFh (   175) of   800h words   (  8.5%)
    CONST                used    18h (    24) of   800h words   (  1.2%)
    ENTRY                used     0h (     0) of   800h words   (  0.0%)
    STRING               used     0h (     0) of   800h words   (  0.0%)

Data space:
    BANK0                used    5Bh (    91) of    60h bytes   ( 94.8%)
    BANK1                used     0h (     0) of    50h bytes   (  0.0%)
    COMBANK              used     0h (     0) of    10h bytes   (  0.0%)

EEPROM space:
    EEDATA               used     0h (     0) of   100h bytes   (  0.0%)

ID Location space:
    IDLOC                used     0h (     0) of     4h bytes   (  0.0%)

Configuration bits:
    CONFIG               used     1h (     1) of     1h word    (100.0%)

Summary:
    Program space        used    C7h (   199) of   800h words   (  9.7%)
    Data space           used    5Bh (    91) of    B0h bytes   ( 51.7%)
    EEPROM space         used     0h (     0) of   100h bytes   (  0.0%)
    ID Location space    used     0h (     0) of     4h bytes   (  0.0%)
    Configuration bits   used     1h (     1) of     1h word    (100.0%)

Det här är det jag får ut efter att jag kommenterat ut den raden. Det jag funderar på, eftersom Bank1 är oanvänd. Går det att styra över att den lägger variablerna där efter att Bank0 är full? Går det att i övrigt styra var program osv ska hamna. Har märkt att om man använder const på variabler som inte ska ändras, så hamnar det iaf i ROM-minnet.

Skulle vara tacksam för lite hjälp här.

MVH

/Björne

[sneaky]

Det är bank0 som är "full". Skriv till exempel bank1 int foobar; när du deklarerar en variabel för att placera "foobar" specifikt i bank1.

Jag har för mig att PRO-versionerna skall hantera detta per automatik men jag kan ha fel.

Innan folk hoppar på mig för terminologin, jag vet, jag har ingen aning vad det heter på riktigt.

[Icecap]

Jag tror inte på att problemet är att bank0 är full men då definitionen av "TextRowOne" inte finns med i inlägget är det inte möjligt att svara helt enkelt.

[Baloo]

IceCap: Jag valde att inte ta med mer av koden då det inte var där problemet, enligt mig, låg. Men här är det:

Kod: Markera allt

const char TextRowOne[] = 	"Hár bor" ;		//Text row one, max 40

Ska prova att använda bank1 och se vad som händer. Tack för det tipset Sneaky.

/Björn

/Edit: Fel namn

[Baloo]

Sneaky:

Ditt tips var väldigt användbart och jag har lärt mig något av det. Tack så hemskans mycket. =)

Jag gjorde så här:

Kod: Markera allt

bank1 char TextBuff[80];		//Buffer to manipulate text

En buffert som förut då låg i bank0 kan ligga i Bank1, den fyller hela. Då ligger den inte i vägen.

En annan fundering då, hur använder man sig av minnesareorna String och Entry? Går det att allokera dessa manuellt på något sätt?

/Björn

[bos]

Jag valde att inte ta med mer av koden då det inte var där problemet, enligt mig, låg.

Men det vet ju inte vi, eller hur?

När du ber om hjälp kan du inte utelämna saker som du själv tror att det inte har med saken att göra. De flesta på forumet har tröttnat på gissningsleken; att gissa vilken typ en viss variabel är, och liknande, så det säkraste är att ta med allt på en gång.

Ett annat tips är att skriva vilken PIC du använder, för Hitechs kompilator beter sig olika beroende på artitektur. Manualen bör berätta mer om psect:arna String och Entry - jag själv har aldrig hört talas om dem.

[Baloo]

Bos: Ja, det var en miss att inte skriva vilken processor det var jag jobbar med. 16F690 i det här fallet.

Nej självklart vet ju inte Ni det, men det var ju inte heller det som var problemet. Det löstes ju oxå väldigt smidigt av det svar jag fick av Sneaky. =)

/Björn

[sodjan]

Vad säger Hitech dokumentationen om Error [593] ?

[bos]

En väldigt bra grundregel för att få hjälp med buggletande i kod är att visa minsta möjliga körbart exempel, som reproducerar felet i fråga. Koden du visade i urinlägget innehöll bara en halv main() utan någon väsentlig variabeldeklaration (mer än de lokala). Då är det rätt svårt att extrahera någon vettig information.

Ett annat bra tips är att skriva dina egna strängfunktioner. Det är matnyttigt när man börjar med C, för när det gäller utveckling till mikrocontrollers så har man inga stora marginaler för "fulkod".

Här har du ett exempel på en strlen:

Kod: Markera allt

unsigned char mystrlen(unsigned char *str) {
  unsigned char i;
  for (i = 0; *str++; i++) {}

  return i;
}

> Vad säger Hitech dokumentationen om Error [593] ?

"See message (491)."

[sodjan]

Var hittade du det (jag hittar inte dokumentationen)
och vad säger Error 491 ?

[bos]

Fel 491 är nog ganska skrämmande läsning för en nybörjare, men det finns på sida 282 i "HI-TECH C for PIC10/12/16 User's Guide" (DS51865A):

(491) can’t find 0x* words for psect "*" in segment "*" (Linker)

One of the main tasks the linker performs is positioning the blocks (or psects) of code
and data that is generated from the program into the memory available for the target
device. This error indicates that the linker was unable to find an area of free memory
large enough to accommodate one of the psects. The error message indicates the
name of the psect that the linker was attempting to position and the segment name
which is typically the name of a class which is defined with a linker -A option.
Section 3.7.1 “Compiler-generated Psects” lists each compiler-generated psect and
what it contains. Typically psect names which are, or include, text relate to program
code. Names such as bss or data refer to variable blocks. This error can be due to
two reasons.

First, the size of the program or the program’s data has exceeded the total amount of
space on the selected device. In other words, some part of your device’s memory has
completely filled. If this is the case, then the size of the specified psect must be
reduced.

The second cause of this message is when the total amount of memory needed by the
psect being positioned is sufficient, but that this memory is fragmented in such a way
that the largest contiguous block is too small to accommodate the psect. The linker is
unable to split psects in this situation. That is, the linker cannot place part of a psect at
one location and part somewhere else. Thus, the linker must be able to find a contiguous
block of memory large enough for every psect. If this is the cause of the error, then
the psect must be split into smaller psects if possible.

To find out what memory is still available, generate and look in the map file, see
Section 2.7.8 “-M: Generate Map File” for information on how to generate a map file.
Search for the string UNUSED ADDRESS RANGES. Under this heading, look for the
name of the segment specified in the error message. If the name is not present, then
all the memory available for this psect has been allocated. If it is present, there will be
one address range specified under this segment for each free block of memory. Determine
the size of each block and compare this with the number of words specified in the
error message.

Psects containing code can be reduced by using all the compiler’s optimizations, or
restructuring the program. If a code psect must be split into two or more small psects,
this requires splitting a function into two or more smaller functions (which may call each
other). These functions may need to be placed in new modules.

Psects containing data may be reduced when invoking the compiler optimizations, but
the effect is less dramatic. The program may need to be rewritten so that it needs less
variables. Section “If the default linker options must be changed, this can be
done indirectly through the driver using the driver -L- option, see
Section 2.7.7 “-L-: Adjust Linker Options Directly”. If you use this option, always
confirm the change appears correctly in the map file.” has information on interpreting
the map file’s call graph if the compiler you are using uses a compiled stack. (If the
string Call graph: is not present in the map file, then the compiled code uses a hardware
stack.) If a data psect needs to be split into smaller psects, the definitions for variables
will need to be moved to new modules or more evenly spread in the existing
modules. Memory allocation for auto variables is entirely handled by the compiler.

Other than reducing the number of these variables used, the programmer has little control
over their operation. This applies whether the compiled code uses a hardware or
compiled stack.

For example, after receiving the message:

Can’t find 0x34 words (0x34 withtotal) for psect text
in segment CODE (error)
look in the map file for the ranges of unused memory.

UNUSED ADDRESS RANGES
CODE 00000244-0000025F
00001000-0000102f
RAM 00300014-00301FFB

In the CODE segment, there is 0x1c (0x25f-0x244+1) bytes of space available in one
block and 0x30 available in another block. Neither of these are large enough to accommodate
the psect text which is 0x34 bytes long. Notice, however, that the total amount
of memory available is larger than 0x34 bytes

[blueint]

Sprider inte PIC kompilatorer ut segmenten där det finns ledigt utrymme självmant ..?
(påminner om en viss processor familj som oavsett 8/16/32 bit mode bara kan arbeta med ett 64 kB segment åt gången .. CS:IP )

Med ovanstående text så borde man kunna dra slutsatsen att om man delar upp strängen så skulle det kunna fungera. Förutom att trimma ner kodstorleken rent allmänt.

T.ex:

Kod: Markera allt

const char TextRowOne_0[] =    "Hár " ;      //Text row one, max 40
const char TextRowOne_1[] =    "bor" ;       //Text row one, max 40

StrLength = strlen (TextRowOne_0) + strlen (TextRowOne_1);

Samt t.ex

Kod: Markera allt

SkrivLCD(TextRowOne_0); SkrivLCD(TextRowOne_1);

[sodjan]

OK, det jag igentligen undrade var om Baloo har läst förklaringen till
felmeddelandet och (i så fall) vad det gav för ytterligare frågor ?
Som jag tolkade det så hade Baloo inte (ens) läst förklaringen, men
det kanske jag missförstog...

[bos]

Sprider inte PIC kompilatorer ut segmenten där det finns ledigt utrymme självmant ..?

Out-of-the-box gör inte PICC det. Jag själv har aldrig haft problem med det (än) så jag har inte behövt leta reda på hur man gör. Manualen är stor och tjock men väldigt ofta är den på skyhögt teknisk nivå som kräver svart bälte i kompilatorkurser för att förstå, så saker som kan ses som triviala kräver en hel del läsande för att greppa. Det är lite synd.

Synd är också att Hitechs support är rätt anala av sig. Senast i veckan kontaktade jag dem och frågade om hur man går till väga för att funktionsprofilera. Svaret jag fick var "det finns stöd för detta. hur man gör står i manualen", utan någon som helst hänvisning till sida, paragraf eller nyckelord att söka på.

Om man enbart ser på deras supportavdelning så känns det som 3500 spänn (standardversionen) kastade i sjön, men bortsett från den avdelningen så är kompilatorn överlägsen konkurrenterna.

[Baloo]

Jodå, nog hade jag läst manualen och med den vetskapen så tänkte jag att det finns säkert någon som snabbt kan se enkelt utan att påpeka att man ska läsa manualer, att man inte lagt tillräcklig med information, att folk är trötta på att folk inte letat osv osv osv. Sneaky svarade, perfekt. Tack igen Sneaky