Hi-Tech begränsningar av arrays.

[Zajber]

Jag vet att Sodjan kommer att ställa någon smart följdfråga nu men jag choor.

Jag håller på att skriva ett enkelt program på en Pic 16f88 med Hi-Tech C och Mplab som ska skicka data till en 433.92MHz sändare, som sedan tas emot av några fjärrstyrda el-uttag. Typ Nexa, fast inte just Nexa. Jag stöter på problem när jag deklarerar den datasträngen som skall skickas som en char-array enligt;

Kod: Markera allt

char ch1_a_1[] 		= {1,1,1,1,1,0,1,1,1,1,0,1};
char ch1_a_0[] 		= {1,1,1,1,1,0,1,1,1,1,1,0};

char ch1_b_1[] 		= {1,1,1,1,1,1,0,1,1,1,0,1};
char ch1_b_0[] 		= {1,1,1,1,1,1,0,1,1,1,1,0};

char ch1_c_1[]		= {1,1,1,1,1,1,1,0,1,1,0,1};
char ch1_c_0[]		= {1,1,1,1,1,1,1,0,1,1,1,0};

char ch1_d_1[]		= {1,1,1,1,1,1,1,1,0,1,0,1};
char ch1_d_0[]		= {1,1,1,1,1,1,1,1,0,1,1,0};

Som sedan går till denna funktion:

Kod: Markera allt

void send_cmd(char cmd[]){

char i,j;

for(j=0;j<=4;j++){

	for(i=0;i<=11;i++){

		nolla();

		switch(cmd[i]){
			case 0:
				nolla();
			break;

			case 1:	
				etta();
			break;
		
			default:
			break;

			}
	}
	nolla();
	__delay_ms(10);
}
}

Det märkliga är som följer, om jag deklarerar 4st variabel-arrays så funkar detta klockren, signalen kommer ut på benet som det ska. Men Inte med 5 eller fler. När jag kompilerar den med 6st variabler (3 sub-kanaler med av och på) så går det inte. Då kommer det bara en massa nollor på utgången.
Försöker jag deklarera det med hela 8st variabler så får jag kompileringsfel:

Kod: Markera allt

Error   [1253] double.c; 55. could not find space (110 bytes) for auto/param block

Även fast jag har "massor" med utrymme kvar på pic:en.

Varför muppar sig Hi-Tech fast det finns minst 50% kvar att nyttja på pic:en?

Jag kommer förmodligen att skriva om detta med några for-loopar nu när jag ser ett mönster i hur signalen skickas, men jag fattar ändå inte varför detta händer.

[JustNeed]

Spontant, utan att ha vana av Hitech så skulle jag gissa på att det är slut på plats i just den rambanken.
Kan man växla rambank att deklarera variabler i i Hitech eller gör den sånt automatiskt?

[AndLi]

Om det nu är ram som är slut är det enklast att lagra det hela smartare...
Det är väldigt ineffektivt att lagra 1 bit i 8 bitar.
Jag hade valt att lagra det i varsin 16 bit variabel. (om nu inte de första 4 bitarna alltid ska vara ett)

så uint16_t ch1_a_1 0x0FBD; (där spara vi 10 bytes)

sen är det bara att göra en forloop som bitroterar en mask och kollar den bitten och kallar din nolla/etta funktion.

och const deklarerar man sen ch1_a_1 så har vi sparat 2 bytes ram till..

edit: eller så const deklarerar du bara dina variabler så borde de inte hamna i ram (med reservation för att jag aldrig kört HiTech C och inte Pic sen 2000...)

[Zajber]

Jodå, det är inte så utrymmeseffektivt att spara enkla bitar i char:s.

Men tro på fan, jag deklarerade dom som konstanter globalt och nu funkar det. Bra tips.

Hade varit smidigt att kunna göra bool-array:er dock.

[sneaky]

En väldigt gammal tråd men det kanske fortfarande har en viss relevans:
http://forum.htsoft.com/all/showflat.ph ... age/0/vc/1

[sodjan]

> Jag vet att Sodjan kommer att ställa någon smart följdfråga nu men jag choor.

Vad betyder "men jag choor" ?

Hur som helst, det hela har ju som redan nämnts till största delen
med lagring av dina ettor och nollor att göra. Dina 8 arrayer tar
väl upp 96 bytes RAM (?). För att lagra 12 bytes med information.
Alltså 84 bytes direkt i soptunnan. Riktigt korkat, minst sagt.

> Även fast jag har "massor" med utrymme kvar på pic:en.

Hur vet du det ?
Och är det av rätt typ ? Och på rätt plats ?
Har du stämt av med MAP filen ?

> men jag fattar ändå inte varför detta händer.

Jag har aldrig använt HiTech-C, men en efter snabb koll i dokumentationen
så verkar det vara ganska vettigt dokumenterat. Det finns ganska utförliga
kapitel kring psects och så vidare. Det är lite oklart vad du menar med "fattar inte",
är det något i dokumentionen som är oklart ? Det kan det ju vara, jag kollade
ju som sagt bara lite snabbt...

Förklaringen till error 1253 är: "The code generator could not find space in RAM
for the psect that holds auto and parameter variables."
Lite bakgrund till det inträffade finns bl.a i "3.4.1.1 AUTO VARIABLES".
Och sen allt det andra med psect och olika direktiv o.s.v.

> Hade varit smidigt att kunna göra bool-array:er dock.

Jag vet inte om det löser det, men har du kollat "3.3.3 Bit Data Types and Variables" ?

> jag deklarerade dom som konstanter globalt och nu funkar det.

Vilket de borde ha varit från början. De *är* ju konstanter, eller hur ?
Utan "const" kan inte HiTech veta det och allokerar upp samma mängd
RAM och lägger till kod för att initiera alla värden med startvärderna.
Med "const" skrivs de bara in i Flash som det är.

[stekern]

Hade varit smidigt att kunna göra bool-array:er dock.

Ta och läs på om bit-fält så ska du se att det går

[dangraf]

Jag funderar fortfarande på vaför du får en del fel.
error 1235: beror på minnes brist som jag förstått det.

Detta gick tydligen att gå runt genom att sätta arrayerna som konstanter alternativt att lagra 12 bitar i en 16bit variabel istället för en 12bit array som kommer dra mindre minne.

Men varför du får fel när du har 5 el fler arrayer utan att detta genererar felmeddelanden av kompilatorn verkar fortfarande underligt. Har du testat mplabs simulator och stegat genom koden i C (och ev kikat lite på assembel koden)?


Om du vill använda bit arrayer så är det inte så väldgit svårt


uint16 data1 = 0x0A5F; ( 0000.1010.0101.1111)

uint16 mask 0x0001;
uint8 i;
for(i=0;i<12;i++)
{
if( data1 & mask) // kollar om det finns en "1a" i din data där "1an" finn i masken.
{ // du kommer alltså att läsa ut byte-strängen bakifrån och framåt
etta();
}else
{
nolla();
}
mask = mask<<1; // flyttar 1an i masken ett steg åt vänster. 0x0001 >>1 == 0x0002
}

[Icecap]

dangraf: felet kom av att deklarationen var så att det lades i RAM. Vid att deklarera dom som const blev det just en ROM-tabell som det finns gott om plats för. Så felets orsak är kristallklar och utredd.

Sedan finns det olika sätt som är mer eller mindre effektiva för att använda de data som ska finnas, det är en annan sak.

[bos]

0x0001 >>1 == 0x0002

Tvärtom: 0x0001 << 1 == 0x0002. 0x0001 >> 1 = 0x0000.

[dangraf]

Oj, skrev rätt i koden men fel i kommentaren, Sorry.
Jag förstår fortfarande inte vad felet är med ram-minnet.
låt säga att 1 page = 256 bytes.
Om man fyller ram-minnet med t.ex 120 bytes så fungerar det medan om man fyller det med 180 bytes så fungerar det inte.. Fyller man det över 256 får man ett kompilerings fel.
Flyttar man all data från ram-minnet till program-minnet med hjälp av const så minskar man det använda ramminnet och plötsligt fungerar det. Vad är det jag missat?

[Icecap]

Du har missat att kretsen inte hade den mängd RAM som krävdes.

[dangraf]

Nu börjar jag bli riktigt förvirrad
Det står i inlägget att det finns minst 50% ram kvar. kompileringsfelet som uppkommer beror på platsbrist i just en rambank som jag förstått det. kretsen har mer än 1 rambank. Min fråga är varför koden kompilerar men exeveras felaktigt. Den kan väl knappast kompilera och köra koden ifall minnet är helt slut?

[Icecap]

Ett array kan tydligen inte korsa en bankgräns helt enkelt.

Du verkar inte fatta detta med const kontra variabler, vad är problemet?

[sodjan]

Det flera här tydligen inte fattar är att det inte är den totala mängden
minne (eller mängden minne i en viss bank) som är intressant.

Det som gäller är mängden minne i den den av minnet som kompilatorn/länkaren
använder för det specifika behovet ("psect"). Storleken på dessa är inte dynamiska
utan sätts i början på länkningen, och sedan får man felet om man passerar
denna gräns. Storleken kan dock justeras med direktiv till länkaren.

Och detta fall talade ju verktygen också om det, vilket redovisades tidigt i tråden :

>>>> The code generator could not find space in RAM
>>>> for the psect that holds auto and parameter variables.

Så det där om att PIC'en har "50% minne kvar" är komplett ointressant !
Så svaret är helt helt enkelt, lär er hur verktygen fungerar !!

Jag har också i ett tidigt inlägg redovisat de rellevanta delarna av dokumentationen
där detta beskriv. RTFM !