Hallo Zusammen, ich möchte einen MEGA32 mit SD-Card (einfacher Datenlogger) betreiben. Nun habe ich über AVR-DOS und die Treiber gelesen, dass mindestens ein MEGA128 notwendig ist, da der MEGA32 zu wenig Speicher hat. Ist das richtig und brauch ich gar nicht erst mit dem MEGA32 anzufangen ? Wenn´s doch funktioniert , wo sind die Grenzen bei der Anwendung ? Der 128 ist mir zu groß und zu teuer.
Wenn man nicht gerade in BASCOM programmiert reicht sogar ein mega8 (mit Dateisystem von ELM Chan )...
Gast
#925717
oder mit einem Mega8 ohne Dateisystem - einfach Sektoren schreiben. Das geht mit oder ohne Bascom.
@Benedikt K. ich muss dir Widersprechen, auch in Bascom bekommst man das in einen Mega8 rein, wenn man auf die Speicherfressenden Dateisystemroutinen verzichtet und das ganze "händisch" mittels eigener Sub macht. Geht wunderbar und wenn man sich etwas anstrengt ist sogar noch Platz für einen Bootloader der einem das Gehampel beim Flashen mit dem ISP Abnimmt. :) Ich weiss nicht warum Bascom immer als Synonym für schlechtes Programmieren verwendet wird und auf den Bascom-Usern rumgehackt wird. Hast du Bascom? Wenn nein glaube ich nicht dass du dir ein Urteil bilden Kannst. Zugegeben klar ist in C einiges viel kompakter als in Bascom, aber es gibt auch Programmtechnische Aufgabenstellungen die man in Bascom viel schneller und Einfacher lösen kann als in C. Also Leben und Leben lassen, jeder wie er will :D :D :D Ich behaupe einfach mal dass man alle Problemstellungen sowohl in C als auch in Bascom lösen kann. Stefan
Gast
#925722
Ich bau mir momentan einen solchen Datenlogger mit einem MEGA16 und der Libery von Mikro-Control.de. Ram (1KB) ist ca. 77& ausgelastet. (Du wirst da drüber in diesem Forum eine Beitrag finden wenn du wilst :-)
Stefan Müller wrote: > @Benedikt K. > > ich muss dir Widersprechen, auch in Bascom bekommst man das in einen > Mega8 rein, wenn man auf die Speicherfressenden Dateisystemroutinen > verzichtet und das ganze "händisch" mittels eigener Sub macht. Mit dem Dateisystem von ELM Chan kann man schreiben, lesen usw. Mit einem mega168 reicht der Platz dann auch um Verzeichnisse zu erstellen und alles drum und dran. Mehr als man in der Praxis braucht. Der Zugriff geschieht ähnlich wie beim PC über highlevel Funktionen wie f_open(), f_close(), f_read(), f_write(). Die einzige Anpassungsarbeit besteht darin, die Ports entsprechend einzustellen, also maximal 5 Minuten arbeit. > Ich weiss nicht warum Bascom immer als Synonym für schlechtes > Programmieren verwendet wird und auf den Bascom-Usern rumgehackt wird. Wenn BASCOM es also nicht schaft diese (oder ähnliche) Features in einem mega8/88/168 unterzubringen, dann ist wohl alles gesagt. Klar, BASCOM ist ideal für schnelle und einfache Programme, aber sobald ein Programm größer wird ist halt ein mega128 angesagt. Den größten Controller den ich habe ist ein mega32. Keine Ahnung wiso alle Anfänger immer mit mega128 anfangen.
Ich wollte nicht wissen ob es in C oder Assembler geht oder ob andere libs das das können. AVR-DOS war die Frage
Winfried Zühlke wrote: > AVR-DOS war die Frage Dann rtfm: http://avrhelp.mcselec.com/avr_dos_file_system.htm Kurz überflogen: sollte gehen, wenn man das richtig konfiguriert.
@Benedikt da steht aber auch unter AVR-DOS-Filesystem Requirements: • Hardware: see AN 123 on http://www.mcselec.com/an_123.htm • Software: appr. 2K-Word Code-Space (4000 Bytes) • SRAM: 561 Bytes for File system Info and DIR-Handle buffer • 517 Bytes if FAT is handled in own buffer (for higher speed), otherwise it is handled with the DIR Buffer • 534 Bytes for each File handle • This means that a Mega103 or Mega128 is the perfect chip. Other chips have too little internal memory. You could use XRAM memory too with a Mega8515 for example.
Gast
#925759
> Ich weiss nicht warum Bascom immer als Synonym für schlechtes > Programmieren verwendet wird und auf den Bascom-Usern rumgehackt wird. Es macht einfach Spass. :-) > Zugegeben klar ist in C einiges viel kompakter als in Bascom, aber es > gibt auch Programmtechnische Aufgabenstellungen die man in Bascom viel > schneller und Einfacher lösen kann als in C. Es ist eigentlich relativ uninteressant was nun effizienter ist. Und auch C hat so seine Schwaechen. Aber C ist nunmal der durchgesetzte Standard sobald es um Microcontroller geht. Und da liegt der Vorteil. Egal ob ich heute AVR, morgen M16C, und uebermorgen Dragonball programmiere. Ich kopiere meinen Source einfach rueber und kann immer 50% meiner Programme aus anderen Projekten weiterverwenden und deshalb ist C dann immer ueberlegen. Einfach weil es Arbeit spart. Und wenn ich mal so richtig komplizierte Probleme habe (z.B FFT) dann lasse ich die auch schonmal auf dem PC laufen und teste sie dort in Ruhe mit Testdaten bevor soetwas auf den Controller kommt. > Wenn BASCOM es also nicht schaft diese (oder ähnliche) Features in einem > mega8/88/168 unterzubringen, dann ist wohl alles gesagt. In FAT-Routinen steckt eine Menge Arbeit. Sowas wird sich Bascom wohl nicht erlauben koennen. Es geht nicht davon ob es moeglich ist, nur darum ob es genug Kunden gibt damit die Kasse stimmt. Ausserdem ist das Problem bei fertigen Libaries immer das jeder mit irgendwelchen Ideen ankommt was man da noch einbauen koennte. Und alles diese Ideen sind fuer sich genommen sehr gut, aber alles zusammen sorgen dafuer das es sehr fett, traege und schwer durchschaubar wird. > Keine Ahnung wiso alle Anfänger immer mit mega128 anfangen. Ich wuerde privat immer mit einem dicken Prozessor rummachen. Ob eine Platine die man fuer sich macht 2-3Euro mehr kostet interessiert doch keinen. Dafuer kann man viel entspannter programmieren. Zum Beispiel hat meine Hardware immer noch irgendwo eine I2C-Bus Schnittstelle auf einem Sockel wo ich bei BEdarf ein LCD anstecken kann und wo mir Fehlermeldungen ausgegeben werden. Sowas spart einem viel Zeit. Olaf
• SRAM: 561 Bytes for File system Info and DIR-Handle buffer • 517 Bytes if FAT is handled in own buffer (for higher speed), otherwise it is handled with the DIR Buffer • 534 Bytes for each File handle Wenn ich das zusammenzähle komme ich auf rund 1100 bzw. 1600 Bytes. 2kByte sollten also reichen. Was spricht dagegen, es einfach auszuprobieren ? Beim Übersetzen sollte dann schon ein Fehler kommen, wenn der RAM nicht ausreicht.
@Benedikt Ja Du hast ja recht mit dem Probieren. Wollte halt mal vorher "in die Runde fragen" Trotzdem vielen Dank an Alle
Gast
#925789
... Along with this dissatisfaction goes my conviction that the language in which students are taught to express their ideas profoundly influences their habits of thought and invention, and that the disorder governing these languages directly imposes itself onto the programming style of the students. N. Wirth
Gast
#925790
> Beim Übersetzen sollte dann schon ein Fehler kommen, wenn der RAM nicht > ausreicht. Wenn es ganz und garnicht reicht sicherlich, aber wenn dann nur noch ein paar Byte Stack ueberbleibt und man drei Wochen spaeter feststellt das das eigene Programm klapprig laeuft, ist das irgendwie unschoen. :-) Olaf
Ist klar, aber BASCOM sollte doch anzeigen, wieviel noch frei ist. So 100-200Bytes sollten es schon noch sein, je nach Verwendung von lokalen Variablen.