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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.