Hallo Leute, Ich setzte zurzeit ein an größern Projekt. Wo mir langsam an meinem ATMega644 der Arbeitsspeicher ausgeht. Daher habe ich geschaut ob es irgend eine möglichkeit gibt denn Arbeitsspeicher zu erweitern ohne wieder denn Controller tauschen zu müssen. Da fand ich bei reichelt für glaubig 1,55 Euro ein Seriellen SRAM von Microchip mit 512 Kbits(~64 Kbytes), dank des SPI Interfaces das der SRAM unterstützt ist die Ansteuerung am ATMega relativ einfach. Ich habe zwei einfache Funktionen geschrieben mit dem ich ein uint16_t in das SRAM schreiben kann und mit der anderen Funktionen, ein uint16_t von einer Adresse im SRAM lesen kann. Doch im Moment kommen wir zweifel auf. Mein interner RAM vom ATMega ist mit 3,7 kb von 4 kb so gut wie voll. Nun ich sage jetzt mal das ich ein char Array mit 1023 Zeichen anlegen möchte(char irgendwas[1023]). Da würde mein Interne Speicher überlaufen. Nur wie lade ich jetzt dieses char Array in dem externen SRAM? Denn die 1023 in denn SRAM zuschreiben. Und dann die Adresse auslesen und char irgendwas[SRAM_ADRESSE] zu machen. Würde ja kein Sinn da dieses Array immer noch im internen Speicher angelegt werden würde wenn ich ihr grade nix durch einander bringe. Kann mir jemand da mal bitte auf die Sprünge helfen Lg Jan.
Jan N. schrieb: > Kann mir jemand da mal bitte auf die Sprünge helfen Nimm einen größeren µC. Externes SRAM ist - wie Du schon richtig erkannt hast - sehr aufwändig zu programmieren. Dein AVR hat IIRC keinen externen Bus für RAM.
Jan N. schrieb: > Ich setzte zurzeit ein an größern Projekt. Dann bist du an den Grenzen der 8-Bit-Controller angelangt, wenn du viel Arbeitsspeicher brauchst. Weiter gehts dann mit STM32 o.a.
@Jan Niehes (jan_n497) >irgend eine möglichkeit gibt denn Arbeitsspeicher zu erweitern ohne >wieder denn Controller tauschen zu müssen. Zuerst sollte man prüfen, ob man wirklich sinnvoll und sparsam mmit dem vorhandenen Speicher umgeht. Dann kann man einen möglichst pinkompatiblen Controller nehmen, z.B. den ATmega1280 (8kB SRAM) oder gar ATmega1284, der hat satte 16kB SRAM! >Da fand ich bei reichelt für glaubig 1,55 Euro ein Seriellen SRAM von >Microchip mit 512 Kbits(~64 Kbytes), dank des SPI Interfaces das der >SRAM unterstützt ist die Ansteuerung am ATMega relativ einfach. Aber in der praktischen Programmierhandhabung nervig. >Ich habe zwei einfache Funktionen geschrieben mit dem ich ein uint16_t >in das SRAM schreiben kann und mit der anderen Funktionen, ein uint16_t >von einer Adresse im SRAM lesen kann. Die nützen dir wenig. >Nun ich sage jetzt mal das ich ein char Array mit 1023 Zeichen anlegen >möchte(char irgendwas[1023]). Da würde mein Interne Speicher überlaufen. Ja. >Nur wie lade ich jetzt dieses char Array in dem externen SRAM? Du musst dich selber um den ganzen Krümelkram der Verwaltung kümmern. So ein externer Speicher ist nur sinnvoll, wenn man einen größeren Datenblock ins interen SRAM kopiert, bearbeitet und wieder in den externen Speicher schreibt. Macht man Einzelzugriffe auf Daten im externen Speicher, hier über SPI, wird das nervig und langsam.
@Jim Meba (turboj) >hast - sehr aufwändig zu programmieren. Dein AVR hat IIRC keinen >externen Bus für RAM. DIESER AVR nicht, einige haben es. ATMEGA162 ATmega128 ATmega128A ATmega64 ATmega64A ATmega1280 ATmega1281 ATmega2560 ATmega2561 ATmega640
Jim M. schrieb: > Nimm einen größeren µC Hallo, Ja, ich denke das ich denn ATMega1284P nehmen werde, da der Flash Speicher auch langsam an seine grenzen kommt, da ich mit SD Karte, ENC28J60, Temperatursensoren, Lichtsensoren und einem TFT Arbeite. Falk B. schrieb: > Zuerst sollte man prüfen, ob man wirklich sinnvoll und sparsam mmit dem > vorhandenen Speicher umgeht. Ich bin noch mal mein Code durch gegangen von denn 64 Kbyte Flash Speicher habe ich 47,3 KByte belegt. Alles was mit Strings zutun hat also sprintf, tft und SD Funktionen arbeite ich mit pgmspace. Also speichere die Strings im Flash. Ich glaube das mein Problem mehr die globalen Variablen sind. Ich werde jetzt erst mal die Variablen so gut wie möglich zu reduzieren. 250 Bytes habe ich im RAM schon frei bekommen. Falk B. schrieb: > Macht man Einzelzugriffe auf Daten im externen Speicher, hier über SPI, > wird das nervig und langsam. Hmmm, blöd. Lg Jan.
batman schrieb: > Jan N. schrieb: >> Ich setzte zurzeit ein an größern Projekt. > > Dann bist du an den Grenzen der 8-Bit-Controller angelangt, wenn du viel > Arbeitsspeicher brauchst. Weiter gehts dann mit STM32 o.a. An einen Xmega (8Bit) kann ich schnellen RAM im MB Bereich anschließen (zu den zusätzlichen 8-16kB). Er muss nicht gleich auf einen 32bitter umsteigen, das ist sehr sehr oft einfach nicht notwendig - höchstens um Erfahrungen zu sammeln. Code nochmal überdenken und ähnlichen Prozessor nehmen - wurden ja einige ähnliche mit mehr Speicher hier genannt.
@Nils H. (nils_h494) >An einen Xmega (8Bit) kann ich schnellen RAM im MB Bereich anschließen >(zu den zusätzlichen 8-16kB). Jain. Wenn gleich der deutlich schneller und einfacher handhabbar ist als ein externer, serieller Speicher, so ist das trotzdem nur bedingt besser. Beitrag "Re: Viel RAM am kleinen Controller"
Jan N. schrieb: > Jim M. schrieb: >> Nimm einen größeren µC > > Hallo, > Ja, ich denke das ich denn ATMega1284P nehmen werde, da der Flash > Speicher auch langsam an seine grenzen kommt, da ich mit SD Karte, > ENC28J60, Temperatursensoren, Lichtsensoren und einem TFT Arbeite. Wenn Du bei AVR bleiben willst, dann wäre einer mit externem Adress/Datenbus wie zB Mega2560/2561 sinnvoller. Dort kannst Du sehr einfach ein oder zwei externe 32k SRAMs anschließen, und auch das TFT wird durch den Betrieb am Adress/Datenbus sehr viel schneller. fchk
Jan N. schrieb: > Ich setzte zurzeit ein an größern Projekt. Wo mir langsam an meinem > ATMega644 der Arbeitsspeicher ausgeht. Daher habe ich geschaut ob es > irgend eine möglichkeit gibt denn Arbeitsspeicher zu erweitern ohne > wieder denn Controller tauschen zu müssen. Ich würde den Controller tauschen. Ein Mega1284P ist weitestgehend pin- und funktionskompatibel, hat aber viermal soviel SRAM und doppelt soviel Flash (wobei man den ja nicht nutzen muss, wenn man ihn nicht braucht). Änderungen am Programm sind entweder überhaupt nicht erforderlich oder minimal, sogar wenn man in Assembler programmiert, bei C ist es tendenziell nochmal ein Stück weniger, was zu ändern ist, jedenfalls wenn der üblicherweise verwendete C&P-Code von einigermaßen guter Qualität ist... > Da fand ich bei reichelt für glaubig 1,55 Euro ein Seriellen SRAM von > Microchip mit 512 Kbits(~64 Kbytes), dank des SPI Interfaces das der > SRAM unterstützt ist die Ansteuerung am ATMega relativ einfach. Und laaangsaaam. Nö, du fährst mit der Umstellung auf einen 1284P ganz sicher sehr viel besser. Wenn du clever warst und die Versuchsplatine mit einem DIL40-Stecksockel bestückt hast, ist die Umstellung hard- und softwaremäßig insgesamt wahrscheinlich sogar in nur wenigen Minuten erledigt...
c-hater schrieb: > Ich würde den Controller tauschen. Ein Mega1284P ist weitestgehend pin- > und funktionskompatibel, hat aber viermal soviel SRAM und doppelt soviel > Flash (wobei man den ja nicht nutzen muss, wenn man ihn nicht braucht). Ist auf jeden fall schon mal mehr als der 644er. c-hater schrieb: > Wenn du clever warst und die Versuchsplatine > mit einem DIL40-Stecksockel bestückt hast, ist die Umstellung hard- und > softwaremäßig insgesamt wahrscheinlich sogar in nur wenigen Minuten > erledigt... Mein Projekt befindet sich immer noch auf 2 Steckbretten. Da ich die meisten Controller Schaltung erst dort aufbaue, wenn ich dann mit dem Programmieren fertig bin und alles klappt. Entwickle ich ein Schaltplan und löte das ganze auf eine Lochrasterplatine auf. Danke für eurere Antworten! Lg Jan.
@ c-hater (Gast)
>Datum: 15.06.2017 19:44
WOW! fundamental neue Erkenntnisse, die dieser Thread, ja das ganze
Forum noch nie gesehen hat! Was würde der OP nur ohne deinen Beitrag
machen?
> sprintf ....
pfff. Du solltest dich von solchen Monstern loesen.
Die 1,4kB printf sollte man beim Mega-Projekt haben. Für Tiny nehme ich eine 100 Bytes-Sparvariante.
batman schrieb: > Die 1,4kB printf sollte man beim Mega-Projekt haben. Für Tiny nehme ich > eine 100 Bytes-Sparvariante. Hast du einen Link auf den Quelltext?
Scrimpy schrieb: > Hast du einen Link auf den Quelltext? Ist ja alles Open Source, siehe dazu: http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdio/ Ist der aktuelle Trunk von der Libc. Genauer werden dich die Dateien interessieren: - der Wrapper: http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdio/sprintf.c?revision=142&view=markup - sämtliche *printf-Magie: http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdio/sprintf.c?revision=142&view=markup Mit freundlichen Grüßen, N.G.
Im Tiny mit 1-2kB brauche ich von printf() selten mehr als die Zahlen-Konvertierung/Formatierung. Da tuts die hier:
1 | char *itoasc(char *outbuf, int len, i16 val, int base, char pad) |
2 | /** \brief convert numeric value to ASCII string representation
|
3 | *
|
4 | * \param outbuf - output buffer address
|
5 | * \param len - buffer length or target field width for fixed length/padding
|
6 | * \param val - numerical input value
|
7 | * \param base - target base e.g. 2(=binary), 10(=decimal),..
|
8 | * \param pad - padding character or -1 for no padding
|
9 | * \return address of output string within outbuf
|
10 | *
|
11 | */
|
12 | // Notes:
|
13 | // If no fixed field (padding) with is used, <len> should be set to buffer size.
|
14 | // If fixed field with (padding) is used, <len> = output field width,
|
15 | // i.e. buffer size must be at least <len>+1!
|
16 | // No overflow checks done!
|
17 | {
|
18 | unsigned idx = len; // point past end of field/buffer |
19 | bool dopadding=true, minus=false; |
20 | div_t d; |
21 | |
22 | if(pad<0) { dopadding=false; idx--; } // step into buffer space |
23 | else memset(outbuf, pad, len); // else preset field |
24 | |
25 | outbuf[idx--] = '\0'; |
26 | |
27 | if(val<0) { val= -val; minus=true; } |
28 | |
29 | d.quot = val; |
30 | |
31 | do
|
32 | {
|
33 | d = div(d.quot, base); |
34 | outbuf[idx--] = d.rem+( d.rem<10 ? '0' : 'A'-10 ); |
35 | }
|
36 | while(d.quot != 0); |
37 | |
38 | if(dopadding) { |
39 | if(minus) outbuf[0]='-'; |
40 | }
|
41 | else { |
42 | if(minus) outbuf[idx--]='-'; |
43 | outbuf+=idx+1; |
44 | }
|
45 | |
46 | return outbuf; |
47 | }
|
Grundsätzlich zur Überschrift: Nichts muss flüchtig sein. Statisches RAM mit einer kleinen Lithium-Batterie wurde und wird millionenfach verwendet. Es hat auch keine Begrenzug der Schreibzyklen wie EEProms oder Flash. Georg
Geh mal davon aus, dass da, wo SRAM drauf steht, auch SRAM drinnen ist. Wenn die Möglichkeiten zum Speichersparen ausgeschöpft sind, kommst Du wohl nicht um eine "Erweiterung" herum. Natürlich kannst Du den Chip wechseln mit all den Nachteilen, die das mit sich bringt, aber wenn aber nichts gegen den Geschwindigkeitsnachteil spricht, so ist ein serielles RAM kostenmäßig sehr gut und der Platzbedarf ist echt klasse. Einzig zusätzliche Bedingung ist eine aktive oder freie Schnittstelle. Gegen den Geschwindigkeitsnachteil hilft vielleicht auch eine Umorganisation des verwendeten Speichers. Also die Bereiche, die auf'n Quiky stehen ins interne RAM verlagern, und die, die es in Ruhen angehen lassen, ins serielle RAM. Was gerne bei den Optimierung übersehen wird ist die Mehrfachnutzung von Speicher. Hierzu ein einfaches Beispiel: Ein Eingabepuffer braucht oft viel Platz. Dies aber nur wenn Eingaben erfolgen. Also kann dieser, die andere Zeit über, alternativ genutzt werden. Was auch gerne gemacht wird ist, nach dem Motto: "Darf's auch ein Bissel mehr sein", Speicher zu reservieren. Vor allem die schon berühmten "+1".
Blöcke/Seiten in den Arbeitsspeicher Ein/Auslagern je nach Zugriffshäufigkeit. Da gibts doch sicher schon eine MMU-lib für SPI-RAM. :)
Falk B. schrieb: > @ c-hater (Gast) > >>Datum: 15.06.2017 19:44 > > WOW! fundamental neue Erkenntnisse, die dieser Thread, ja das ganze > Forum noch nie gesehen hat! Was würde der OP nur ohne deinen Beitrag > machen? Tja, es gibt Leute, die haben nicht den ganzen Tag Zeit, sich mit Forenthreads zu beschäftigen, die müssen einfach mal richtig arbeiten. Mag schon sein, dass sowas jenseits deiner Erfahrungs- oder gar Vorstellungswelt ist... Wie auch immer: Unter diesen Umständen kann es jedenfalls schonmal passieren, dass man einfach nur auf das OP antwortet, wenn man dazu kommt, es zu lesen, ohne gleich den ganzen Thread zu lesen. Das ist aber wohl nicht schlimm, solange nur die Antwort sachlich korrekt ist. Schlimmstenfalls ist es vollständig redundante Information. Praktisch aber angesichts der üblichen fachlichen Durchschnittsqualität der Threads mindestens Bestätigung korrekter Information und damit ein Beitrag zur Glaubwürdigkeit und Bestätigung des korrekten Lösungswegs, also informationstheoretisch betrachtet immer noch ein Gewinn.
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.