PIC EEPROM und ARRAY

[aerodactyl (Gast)]

Hallo Gemeinde,

ich beiße mir gerade mal wieder die Zähne aus.

PIC 16F690

Bisher hatte ich vor meinen Interruptschleifen ein ARRAY

const char ARRAY[] = {1,2,3,4,....,128};

angelegt, in dem feste Werte standen.

Da eine Interrupt-Routine auf das ARRAY zugreift, muss das Array dort 
stehen.

Nun möchte ich die Basiswerte beim Brennen ins EEPROM schreiben. Mit

#rom 0x2100 = {1,2,3,usw}

funktioniert das auch.

Das Auslesen des EEPROMs bekomme ich auch hin, aber ich bekomme die 
Werte nicht in mein ARRAY rein.
Wenn ich es ohne CONST versuche, geht mir bei 128 Byte das RAM aus.

CONST hatte ich damals gewählt, damit ROM und kein RAM belegt wurde.

Gibt es einen Weg aus dieser Nummer raus, außer einen PIC mit mehr 
"Hubraum"??

Danke für eure Unterstützung.

Gruß

Uwe

[Takao K. (takao_k)]

Du kannst EEPROM nicht als Array auslesen (im sinne eines C Arrays).

Wozu brauchst du denn die Werte im einem Array, brauchst du alle auf 
einmal was ist denn die Zuordnung?

Vielleicht reicht es nur gelegentlich vom EEPROM in ein kleineres Array 
umzuladen.

Ja klar 128 Bytes sind nicht gerade viel.

Du kannst auch das Statement welches ein Array verwendet umschreiben, so 
dass vom EEPROM gelesen wird.

Musst du die Werte auch veraendern?

[Max H. (hartl192)]

aerodactyl schrieb:
> Da eine Interrupt-Routine auf das ARRAY zugreift, muss das Array dort
> stehen.
Als globale Varibale zu deklarieren funktioniert nicht?


Du könntest dir eine Funktion schreiben, die sich beim Lesen Array 
ähnlich verhält, da du von einem const Array schreibst gehe ich mal 
davon aus, dass du nur lesen willst.

unsigned char EE_Array(index)
{
EEADR=index; 
EECON1bits.EEPGD=0;
EECON1bits.RD=1;
return EEDAT;
}

Zugreifen kannst du dann z.B. mit

varaible=EE_Array(5);

P.S. das Funktioniert aber nur, wenn das Array bei Adresse 0 im EEPROM 
beginnt.

[aerodactyl (Gast)]

Erst einmal DANKE für eure Antworten.

In dem ARRAY werden Parameter hinterlegt, die ständig gebraucht werden. 
Deshalb kann ich die nicht bei Bedarf aus dem EEPROM holen.

Ändern muss ich die Werte aber nur gelegentlich. Das wollte ich dann so 
machen, dass die Werte im ARRAY geändert werden und dann auf Befehl hin 
ins EEPROM geschrieben werden.

Ich verstehe auch nicht wirklich, warum mir mein RAM ausgeht. Mein CCS 
meldet mir OHNE Array 50-59% Belegung.


Gruß

Uwe

[Max H. (hartl192)]

aerodactyl schrieb:
> die ständig gebraucht werden.
> Deshalb kann ich die nicht bei Bedarf aus dem EEPROM holen.
Genau dafür wurde das RAM in den µC eingebaut. Wenn du sie nicht aus dem 
EEPROM (und aus dem Flash wahrscheinlich auch nicht) hohlen willst 
bleibt auch nur noch das RAM übrig. Auch wenn es irgendwas gibt um auf 
das EEPROM wie auf ein Array zuzugreifen, dann würde der Compiler den 
EEPROM-Zugriff sicher auch machen, ihn aber vor dir verstecken.

> Ich verstehe auch nicht wirklich, warum mir mein RAM ausgeht. Mein CCS
> meldet mir OHNE Array 50-59% Belegung.
Da wir das Programm nicht kennen, verstehen wir es auch nicht.

[Chris B. (dekatz)]

aerodactyl schrieb:
> Ich verstehe auch nicht wirklich, warum mir mein RAM ausgeht. Mein CCS
> meldet mir OHNE Array 50-59% Belegung.
>

Der 16F690 hat 256 Byte RAM - wo sollen da bei 59% Belegung noch 128 
Byte EEPROM-Daten hineinpassen?

Selbst wenn 50% angezeigt werden, kann es durch Runden bei der 
Speicherplatzberechnung sein, daß bereits 129 Byte RAM belegt sind - 
also auch keine 128 Byte mehr frei sind.

[Uwe (Gast)]

Hallo mal wieder,

ich habe mir nun einen 16F1829 bestellt, der 1k RAM hat, pinkompatibel 
zum 16F690 ist und alles an board hat, was ich so brauche.

Zum Testen habe ich erst einmal ein Zwergenprogramm geschrieben, um die 
Sache mit dem ARRAY im RAM auszuloten. Prompt bin ich wieder auf Dinge 
gestoßen, die ich nicht verstehe und fpr mich unlogisch sind.

main()

{

unsigned int i = 0;
unsigned int test_1 [128];



for (i=0;i<128;i++)
{
iest_1[i] = i;
}

}

Compilieren geht. Max 17% RAM belegt.

Wenn ich das Programm laufen lasse, werden 72 Eimer gefüllt, danach wird 
im WATCH Fesnster RESTRICTED MEMORY angezeigt.

Nehme ich 2 Arrays mit je 64 Eimern (for() hat dann natürlich auch nur 
64 Zyklen), wird eines gelüllt, das 2. nur bis zum 8. Eimer, danach ab 
Adr. 07F wieder RESTR. MEM.

Tausche ich die ARRAYs in der Deklaration, wird immer das 2. ARRAY 
begrenzt.

Nehme ich aber 2 ARRAYs mit 80 Eimern und fülle Sie je nur bis 64, ist 
alles paletti. Beide werden sauber bis in Zelle 64 beschrieben, ohne ins 
RESTR.MEM. zu kommen.

Für mich ist das unlogisch und nicht erklärbar. Was mache ich falsch?
1 ARRAY mit 128 Zellen wäre mir am Liebsten, könnte aber auch mit 2 
Arrays leben.
Ich fürchte aber, wenn ich jetzt noch Programmtext reinschreibe, dass 
dann wieder alles anders ist.

Wo mache ich den Fehler?
Muss ich das 128 Zellen ARRAY in einen bestimmten Adressbereich 
schieben, damit es funktioniert? Wenn ja, wie geht das?

Ich nutze CCS PCM in der aktuellsten Version und MPLAB 8,9?

Gruß

Uwe

[Chris B. (dekatz)]

Uwe schrieb:
> Hallo mal wieder,
>
> ich habe mir nun einen 16F1829 bestellt, der 1k RAM hat,....
> ........

Das RAM des 16F1829 ist auf mehrere RAM-Bänke verteilt, wobei maximal 80 
Bytes pro Bank ZUSAMMENHÄNGEND! zur Verfügung stehen. Da hilft auch kein 
verschieben etc....

> Ich nutze CCS PCM in der aktuellsten Version und MPLAB 8,9?
>

Wenn der CCS keine "Speicherbankübergreifende Arrays" unterstützt (was 
ich mangels Kentniss dieses Compilers nicht weiss), dann kannst du es 
nur über 2 getrennte Arrays machen.

Ausweg: Die aktuelle Entwicklungsumgebung MPLABX und den Compiler XC8 
istallieren (beide "free"). Der XC8 kann bei den "enhanced mid-range" 
PIC Arrays über die Speicherbankgrenzen hinweg verarbeiten (wenn auch 
nicht besonders schnell).

[aerodactyl (Gast)]

Hallo Chris.
Vielen dank fuer deine Antwort. Jetzt ist mir das klar.
Wo steht das geschrieben?

An alle CCS Kenner: Gibt es da was, um doch ein 128er Array zu nutzen?

Gruß

Uwe

[Chris B. (dekatz)]

Datenblatt des PIC16F1825/1829 Seite 28...29: Memory map banks 0-7 und 
8-15: der größte zusammenhängende RAM Bereich ist in Bank0 mit 96 Bytes.

Und im "XC8 Compiler User guide".

[Uwe (Gast)]

Moin zusammen,

ich glaube, mein MPLAB verarscht mich.

Wenn ich 2 mal 64er Arrays anlege und dan noch ein weiteres, wird wieder 
ein Problem an dem 2. Array sichtbar. Es werden 10 Zellen weniger 
gefüllt und das Watch Window meldet wieder bei mehreren Zellen 
"Restricted Memory".

Ich habe dann mal ein 128er Array angelegt und vollgeschrieben. 
Natürlich wieder Fehlermeldungen im Watch Window.

Ich habe dann mal das gante Array ins EEPROM geschrieben. Und siehe da, 
alle Zellen wurden geschrieben und sogar mit den richtigen Werten. Das 
zufällige Auslesen einiger Zellen im EEPROM förderten auch wieder die 
richtige Zahl zu Tage.
Auch wenn ich weitere ARRAYs anlege und die wieder im WATCH was an 
meinem 128er "abknabbern", werden immer alle Zellen geschrieben.

Ich hatte vor einem halben Jahr schon mal den Schritt auf MPLAP X 
versucht, bin aber nicht mit der Bedienung warm geworden. Als Hobbyist 
bin ich dann bei 8.92 geblieben.

Kennt jemand das Phänomen? Ist das ein Bug in 8.92 mit den neueren PICs?

Gruß in die Welt

Uwe

[Max H. (hartl192)]

> ich glaube, mein MPLAB verarscht mich.
Das liegt eher am Compiler als an der IDE...

[Frank K. (fchk)]

Ich würde einfach zu größeren PICs greifen. Entweder PIC18 oder PIC24. 
Auch bei PIC24 gibt es mit den PIC24F(V)xxKAxx und PIC24FxxKLxx kleine 
Typen, und die sind deutlich angenehmer zu programmieren, weil es keine 
Banks gibt, der C30/XC16 sich um das Einblenden des Program Flashes in 
den Datenadressbereich kümmert (also kein rom bzw ram Keyword wie beim 
C18 nötig), und die Peripherie ist auch teilweise besser.

PIC16 würde ich nur noch bei Projekten verwenden, bei denen es um 
größere Stückzahlen geht. Für Einzelstücke lohnt es eigentlich nicht 
mehr.

fchk

PS: die meisten modernen PICs haben kein eingebautes EEPROM mehr, weil 
die dafür erforderlichen Halbleiterprozesse nicht kompatibel sind. Das 
betrifft alle Hersteller. Aber für einen 24AA64 oder 93LC86 im SOT23-5 
ist immer noch Platz.

[aerodactyl (Gast)]

Hallo Max,

ich denke, der Compiler ist OK.

Ich kann ja alle 128 Werte ins EEPROM schreiben und auch wieder 
herausholen. Nach dem Herausholen werden auch ALLE 128 Werte korrekt und 
in den richtigen Zellen platziert.

@Frank
Ich werde nächstes Jahr mal mit den 18ern beginnen. Mein Compiler kann 
die 18er+höher leider nicht und für die "größere Version" von CSS bin 
ich noch zu geizig :-)

Werde wohl doch noch mal einen Versuch mit MPLAB X unternehmen .......

Gruß

Uwe

[Chris B. (dekatz)]

aerodactyl schrieb:
> Hallo Max,
>
> ich denke, der Compiler ist OK.
>
> Ich kann ja alle 128 Werte ins EEPROM schreiben und auch wieder
> herausholen. Nach dem Herausholen werden auch ALLE 128 Werte korrekt und
> in den richtigen Zellen platziert.
>

Nein, der Compiler ist (offensichtlich) nicht OK.

Das EEPROM hat einen durchgehenden Adressbereich und damit nichts mit 
dem Aufbau des RAM in Bänken (und den damit verbundenen Problemen) zu 
tun!

[aerodactyl (Gast)]

Hallo Chris,

aber warum scheint dann alles zu funktionieren und nur die Anzeige im 
MPLAP ist "durch den Wind" ?

Wenn der Compiler eine Macke haben sollte, würden doch Daten fehlen .... 
(mein bescheidenes Verständnis dazu).

Gruß

Uwe

[Chris B. (dekatz)]

aerodactyl schrieb:
> Hallo Chris,
>
> aber warum scheint dann alles zu funktionieren und nur die Anzeige im
> MPLAP ist "durch den Wind" ?
>
> Wenn der Compiler eine Macke haben sollte, würden doch Daten fehlen ....
> (mein bescheidenes Verständnis dazu).
>
> Gruß
>
> Uwe

Und ich dachte es funkteoniert nicht
WAS genau funkteoniert den jetzt bzw. nicht?
Reden wird jetzt von Arrays im RAM oder im EEPROM.
Das 128 Werte ins EEPROM geschrieben und wieder gelesen werden können 
ist schon klar und der Compiler kann das sicher.
Im ersten und folgenden Postings ging es darum Daten aus dem EEPROM zu 
lesen und diese ins RAM zu schreiben  - und das KEIN Array im RAM mit 
128 Byte angelegt werden kann/konnte.......
Und - hast du das nur Simuliert oder schon mal auf Realer Hardware 
laufen lassen?

Wen es nur am Simulator getestet wurde, das ist MPLAB 8.92 mit 
"akteulleren" Controllern ohnehin mit Vorsicht zu geniessen. Das letzte 
MPLAB 8.xx Update liegt schon 2 Jahre zurück weil MPLAB nicht mehr 
weiterentwickelt wird......

[aerodactyl (Gast)]

Mist, ich hätte doch einen neuen Fred aufmachen sollen ......


Das ich ein 128er Array nicht mehr in den 16F690 reinbekam ich logisch 
und das habe ich auch verstanden.
Da meckerte mein Compiler rum, dass nicht genug RAM vorhanden sei (was 
ja auch logisch war, aber ich hatte nicht mehr auf dem Radar, dass der 
690 nur 256 Byte hat.

Daher bin ich auf den 16F1829 gekommen, der pinkompatibel ist und alles 
an Bord hat, was ich so brauche.

Mit dem 1829 kann ich locker mein 128er Array anlegen und den Code auch 
compilieren, ABER mein Watch Window zeigt mir an, das Teile im 
Restricted Memory liegen.

Darum habe ich alle Daten, die ich ins Array geschrieben hatte, einfach 
mal ins EEPROM geschrieben (was ich ja auch später mal machen will).
Dort tauchten alle 128 Daten richtig auf.
Wenn ich die Daten wieder vom EEPROM ins Array zurücklese, und mir dann 
einzelne Zellen auslese (auch die, die im Restr. Mem. liegen), sind die 
Daten an den entsprechenden Stellen korrekt.

Daher bin ich der Meinung, dass der Compiler schon alles richtig macht, 
aber das MPLAP das ARRAY im Watch Window nicht richtig darstellt.

Real gebrannt habe ich den PIC noch nicht, da der 1829 eine andere 
Programmierspannung braucht und ich meinen Brenner noch nicht umgebaut 
habe.

Hoffe, ich konnte das nun aufklären.

Gruß

Uwe

[Frank K. (fchk)]

aerodactyl schrieb:

> Real gebrannt habe ich den PIC noch nicht, da der 1829 eine andere
> Programmierspannung braucht und ich meinen Brenner noch nicht umgebaut
> habe.

Brenner sind so was von 80'er. Hol Dir ein PICKit 3, damit kannst Du 
alle alktuellen PICs programmieren UND debuggen (also Single Step, 
Variablen anschauen etc etc). Das Original kostet 50€, beim Chinamann 
gibts Nachbauten für 20€.

fchk

[Chris S. (schris)]

Bei ccs ware es gewesen 16f
#ROM 0x2100={0x01,0x02...

Für eeprom gibt es auch interne Funktionen.
Man sollte sich wirklich Beispiele ansehen oder das manual durchsehen.

[aerodactyl (Gast)]

Chris S. schrieb:
> Bei ccs ware es gewesen 16f
> #ROM 0x2100={0x01,0x02...
>
> Für eeprom gibt es auch interne Funktionen.
> Man sollte sich wirklich Beispiele ansehen oder das manual durchsehen.

Hallo Chris,

wie ich ins EEPROM schreiben und wieder lesen kann, ist mir schon klar. 
Das habe ich auch schon mit anderen PICs gemacht.
Das werde ich beim 16F1829 auch hinbekommen, ganz sicher ;-)

Auch wie ich Daten ins ROM schreiben kann, ist mir bewusst.

Ich möchte nur die anscheinende Diskrepanz zwischen dem, was mit das 
Watch Window im MPLAP anzeigt, und das was mir das EEPROM Window zeigt, 
verstehen.


@Frank
PICKit 3 werde ich mir demnächst mal zulegen. Danke für den Hinweis.


Gruß

Uwe