n'abend zusammen,
das meiste steht schon im betreff ... ich brauche mehr (arbeits)speicher
als mein pic zur verfügung stellt (2kb)
jetzt muss ich wohl externen speicher anhängen (kann auch eeprom sein).
von microchip direkt gibts serielle eeproms und rams
es gibt welche mit I²C, und welche mit SPI
meine frage is jetzt:
wie kann ich datenstrukturen wie arrays structs etc. EINFACH mit C im
externen speicher ablegen, und daraus lesen?
also wie realisiere ich sowas wie:
int meinarray[20];
meinarray [2]=42;
x= meinarray[2];
für externen speicher.... mich interessierts ja einen feuchten kericht
wo der mir da was speichert... ich will mein array irgendwo auf dem
externen speicher und auch mit ner variable wieder drauf zugreifen.
ich hab gesehen dass es folgendes auf der microchip seite gibt:
IBIS Model - 25xx1024 Devices
Verilog Model - 25xx1024 Devices
was soll ich denn damit anfangen ... letzteres enthält z.b. ne .v datei
... das scheint sowas ähnliches zu sein wie eine bibliothek, aber was
mach ich damit?
dann is noch die frage: bei spi und i²c gibts irgend eine taktrate ...
z.b. können einige i²c eeproms 400kHz bis 1MHz. was bedeutet das?
wenn ich irgendwo nen schwingquarz mit 7Mhz hab, was muss ich dann
softwaremäßig einstellen um den speicher zu betreiben?
herrjeh, beim pc ist das doch so einfach: ramriegel mit wenig raus,
ramriegel mit viel rein, geht.
speicherschorsch schrieb:> das meiste steht schon im betreff ... ich brauche mehr (arbeits)speicher> als mein pic zur verfügung stellt (2kb)
Wäre es nicht einfacher, einen dsPIC30 mit mehr RAM zu verwenden?
> wie kann ich datenstrukturen wie arrays structs etc. EINFACH mit C im> externen speicher ablegen, und daraus lesen?
Programmgesteuert rauskopieren und wieder einlesen. Ein direkter Zugriff
auf seriell angeschlossenen Speicher ist nicht möglich. Also:
copy_ram_to_extern(&variable, 0x12345, 32);
copy_extern_to_ram(0x12345, &variable, 32);
Wobei du diese Funktionen selbstredend selber (ab)schreiben darfst.
Externes EPROM/RAM ist bei diesen Controllern ein bisschen wie eine
Festplatte beim PC. Nicht direkt als Variable adressierbar, sondern man
muss über Zugriffsfunktionen lesen/schreiben.
> und auch mit ner variable wieder drauf zugreifen.
Direkt? Dann ist dein Controller zu klein. Punkt.
> IBIS Model - 25xx1024 Devices> Verilog Model - 25xx1024 Devices> was soll ich denn damit anfangen ...
Nichts. Ist nicht für dich gedacht.
Camel Coder schrieb im Beitrag #1706411:
> externen speicher kann ich nie nicht so einfach verwenden wie meinen> internen ram.
Korrekt. Nicht bei den dsPIC30. Auch nicht parallel. Es gibt in anderen
Controller-Familien Typen, die extern parallel angeschlossenes RAM
unterstützen und dies direkt adressierbar machen. Aber es gibt m.W.
nirgends Controller bzw. C-Compiler, die externen seriellen Speicher
im Programm direkt ohne explizite Zugriffsfunktionen ansprechbar machen.
> also sowas wie ein array auf externem e³prom speichern und darus lesen> ist schlicht nicht möglich?
Nicht direkt per a[i], sondern nur über Zugriffsfunktionen wie
read_byte(i).
also mal angenommen ich hätte ein array von structs:
struct irgendwas{
unsigned int teilvonirgendwas;
int anderesteilvonirgendwas;
}
irgendwas vieleirgendwasse [12];
wie speichere ich das extern, und wie rufe ich das extern auf?
Wie schon erwähnt: Eine einzelne "struct irgendwas" ist im RAM und zwei
zu schreibende Funktionen kopieren deren Inhalt von/in den 12 Plätzen
des externen Speichers.
Versuch doch erstmal festzustellen, warum Du soviel RAM benötigst.
Bei der MC-Programmierung geht man normaler Weise völlig anders vor, als
bei der PC-Programmierung.
Man überlegt sich genau, welche Variablen ständig gebraucht werden. Alle
anderen Variablen werden nur solange angelegt, wie man sie benötigt.
Man nimmt daher vorzugsweise lokale Variablen, d.h. am Ende der
benutzenden Funktion werden sie automatisch ungültig und die nächste
Funktion kann den freigewordenen RAM benutzen usw..
Insbesondere Textausgaben werden erst erstellt, wenn sie benötigt werden
und nach der Ausgabe sofort wieder gelöscht.
Ältere MCs hatten daher oft nur 128 Byte RAM.
Bei den AVRs gibt es z.B. den ATmega1284 mit 16kB RAM.
Einige MCs haben auch ein Memory-Interface, z.B. der ATmega162 kann bis
zu 64kB externen SRAM anschließen. Der Compiler kann ihn ganz normal wie
interen RAM benutzen, nur der Zugriff dauert einen Zyklus länger.
Peter
ich bin auch schon dran zu überlegen wie ich die variablengröße
minimiere ... oder eben doch externen speicher benutze ... wegen
ziemlichem zeitdruck ist das aber alles irgendwie ... naja
aber danke mal soweit für die hilfe.
kann mir vllt noch jemand tipps geben wie ich geeignete bibliotheken
finde für die serielle übertragung?
ist i²c einfacher zu implementieren oder spi?
was ich finde ist irgendwie immer nicht das was ich brauche...
speicherschorsch schrieb:> ist i²c einfacher zu implementieren oder spi?
SPI. Und wenn du dafür eine Bibliothek brauchst, dann sehe ich schwarz
für das Projekt. Dass EEPROM nur begrenzte Schreibzyklen kann, und dafür
ausserdem recht lang braucht, ist dir hoffentlich bekannt. RAM oder FRAM
könnte sinnvoller sein.
Noch sinnvoller ist es freilich, mit weniger Daten auszukommen. Oder,
weil softwareseitig am einfachsten, innerhalb der gleichen Familie einen
Controller mit ausreichend RAM zu verwenden (dsPCI30F6013: 6KB).
Was für ein Compiler benutzt du, C30?
wenn ja, guck mal hier rein:
\Microchip\MPLAB C30\src\peripheral_30F_24H_33F\include
vielleicht gibt es was passendes für dich.
Hermann U. schrieb:> Was für ein Compiler benutzt du, C30?> [...]> vielleicht gibt es was passendes für dich.
da gibts sowohl eine i2c bib als auch eine spi ... muss mir die erst
noch genauer anschauen, aber ich denk bissl was werd ich schon damit
anfangen können ... is halt nicht direkt auf speicherverwaltung
zugeschnitten
A. K. schrieb:> SPI. Und wenn du dafür eine Bibliothek brauchst, dann sehe ich schwarz> für das Projekt.
deswegen weil ich so doof bin und überhaupt bibliotheken benutzen will?
oder weils keine passenden gibt?
>> Dass EEPROM nur begrenzte Schreibzyklen kann, und dafür> ausserdem recht lang braucht, ist dir hoffentlich bekannt. RAM oder FRAM> könnte sinnvoller sein.
ich bin am schwanken zwischen eeprom und ram, ... die begrenzten
schreibzyklen sind mir bewusst, dass eeprom 'langsam' ist weiß ich
mittlerweile auch, allerdings nicht genau was das bedeutet ... hängt
doch sowieso alles an der langsamen seriellen schnittstelle?
dann ist halt der punkt dass eeprom nicht flüchtig ist... wie groß der
vorteil ist kann ich aber noch nicht abschätzen.
>> Noch sinnvoller ist es freilich, mit weniger Daten auszukommen.
deswegen mach ich am besten nen neuen fred auf ... das passt thematisch
wohl nich ganz...
> weil softwareseitig am einfachsten, innerhalb der gleichen Familie> einen Controller mit ausreichend RAM zu verwenden (dsPCI30F6013: 6KB).
nen anderen controller kann nicht nehmen: 6kb sind auch zu wenig,
außerdem würds zu lange dauern nen neuen zu bekommen samt board ... und
da macht mein studienarbeitsbetreuer nich mit nehm ich an.
speicherschorsch schrieb:> deswegen weil ich so doof bin und überhaupt bibliotheken benutzen will?> oder weils keine passenden gibt?
Weil es so einfach ist.
> dann ist halt der punkt dass eeprom nicht flüchtig ist... wie groß der> vorteil ist kann ich aber noch nicht abschätzen.
FRAM ist auch nicht flüchtig, dafür entfällt die Schreib/Löschzeit und
die Schreibzyklen sind faktisch nicht begrenzt.
> nen anderen controller kann nicht nehmen: 6kb sind auch zu wenig,
An wieviel Gigabyte dachtest du denn? Irgendwann wird's halt absurd.
> nen anderen controller kann nicht nehmen: 6kb sind auch zu wenig,
Wieviel RAM brauchst du? hast du schon mal nachgerechnet. Ich meine es
gibt bei C30 optimierungs- Einstellungen. Und Sie bringen einiges an
Optimierung, hast du schon mal versucht, vielleicht brauchst du dann
kein RAM mehr. :-)
ich hab z.b. daten von einem RFID Tag ... das sind ca. 600bit (im worst
case 1024bit)
von diesen Tags habe ich 20 stück, deren daten ich speichern will, also
12000bit sprich 1500byte, und damit ist ja mein 2kb RAM schon fast voll,
im worst case übervoll.
dazu kommen noch 4 puffer für senden und empfangen von 2 uarts ... bei
denen kann ich noch nicht ganz einschätzen wie groß die sein müssen. im
zweifelsfall doppelt so groß wie ein datensatz. also zusammen ca.
512byte
damit bin ich voll am anschlag mit dem ram ... und dann kämen eigentlich
noch 'normale' kleinere variablen dazu ...
gut, 6kb würden reichen, aber ich kann einfach keinen anderen µC nehmen.
auf jeden fall mal danke für eure hilfe, ich werd mich zum thema spi
speicher und optimierte speicherverwaltung schlaumachen ....
hilfreiche links sind natürlich gern gesehen.
gruß
speicherschorsch schrieb:> von diesen Tags habe ich 20 stück, deren daten ich speichern will
Fürs nur Speichern gibts unbegrenzt FINO-Speicher (first in, never out).
Wichtig ist daher zu überlegen, ob, wann und wie lange Du welche Daten
benötigst.
Werden die Daten nur selten eingelesen, kann man sie auch im Code-Flash
ablegen.
Peter
