Hallo Leute, ich stehe mal wieder vor einen programmiertechnischen Problem: Folgendes soll realisiert werden: Ich habe einen LED Streifen mit 60 digitalen LEDs. Dafür brauche ich für jede LED 3 Werte(RGB). Diese werden einmalig über die serielle Schnittstelle von einem PC übertragen und sollen dann in den Flash geschrieben werden. Bei 3 Werten pro LED wären das 180 Byte. Da es auch mal mehr led werden können möchte ich die Werte nicht im EEPROM speichern sondern im Flash, da größer und trotz Programm noch mehr Platz. Der spätere Zugriff auf die Daten hab ich mir so vorgestellt das ich einen Zeiger auf die ersten Daten habe und dann den Zeiger in einer Schleife immer um eins bzw. um drei erhöhe und den Wert der jeweiligen LED zuordne. Jetzt ist nur die Frage wie so ein Aufbau einer solchen Struktur oder Array abläuft? Eigentlich wenn die Daten immer an der gleichen Stelle im Flash liegen brauche ich nur eine Variable mit der Startadresse aber der Compiler legt die Daten wohl dahin wo er es für richtig hält habe ich gelesen. Kann mir jemand bei einer grundlegenden Lösungsfindung helfen? Wie würdet ihr das machen? Vielleicht denk ich ja auch falsch. Grüße Christian
Welcher Controller? Ist EEPROM wirklich nicht groß genug? Meist hat man ja > 1 kB. Die meisten Controller können den Flashspeicher des Applikationsbereichs nur aus dem Bootloader-Bereich programmieren. Das heisst du musst einen Bootloader programmieren, der über die serielle Schnittstelle auf die RGB Werte wartet und im Flash ablegt. Im EEPROM kannst du hingegen zu jeder Zeit schreiben, was die Sache natürlich einfacher macht und es sich evtl. auch lohnt 50 Cent mehr für einen Controller auszugeben, der eben mehr EEPROM bereitstellt.
Verrätst du uns auch, welchen Prozessor du verwenden willst? Im Prinzip ist dein Ansatz machbar, allerdings in den meisten Fällen nur mit erheblichen Klimmzügen. Mit dem EEPROM wird es einfacher.
Georg G. schrieb: > Verrätst du uns auch, welchen Prozessor du verwenden willst? Sorry, aber meine Glaskugel ist zur Wartung, deshalb muss ich diese Frage auch stellen. > Im Prinzip ist dein Ansatz machbar, allerdings in den meisten Fällen nur > mit erheblichen Klimmzügen. Bei den meisten PICs ist das recht unkompliziert möglich. Habe ich selbst schon ein paar Mal so gemacht. Man sollte nur beachten, dass sich Programm und Daten nicht in die Quere kommen. Im Datenblatt ist die Vorgehensweise beschrieben. Allerdings sollte man beachten, dass der Flash nicht für sehr häufige Schreibvorgänge geeignet ist. In dem Fall wäre ein gepufferter SRAM oder aber ein FRAM die bessere Wahl. Für mehr Infos brauchen wir mehr Infos...
@Chris Tian (chris0086) >Ich habe einen LED Streifen mit 60 digitalen LEDs. >Dafür brauche ich für jede LED 3 Werte(RGB). >Diese werden einmalig über die serielle Schnittstelle von einem PC >bertragen und sollen dann in den Flash geschrieben werden. >Bei 3 Werten pro LED wären das 180 Byte. Da es auch mal mehr led werden >können möchte ich die Werte nicht im EEPROM speichern sondern im Flash, >da größer und trotz Programm noch mehr Platz. Warum? Das EEPROM ist groß genug. >Der spätere Zugriff auf die Daten hab ich mir so vorgestellt das ich >einen Zeiger auf die ersten Daten habe und dann den Zeiger in einer >Schleife immer um eins bzw. um drei erhöhe und den Wert der jeweiligen >LED zuordne. Logisch, das nennt man Array. >Jetzt ist nur die Frage wie so ein Aufbau einer solchen Struktur oder >Array abläuft? So wie jeder Variablenzugriff in C oder ASM. > Eigentlich wenn die Daten immer an der gleichen Stelle im >Flash liegen Nein, das kann man in C nicht garantieren. Muss man auch nicht. >Kann mir jemand bei einer grundlegenden Lösungsfindung helfen? Mach es nicht unnötig kmoliziert. Den Flash aus der Anwendung heraus schreiben ist beim AVR eher aufwändig, das macht eigentlich nur ein Bootloader. Nimm einen AVR mit ausreichend großem EEPROM und gut, dort kann man problemlos reinschreiben und wieder lesen. Wenn du WIRKLICH sehr viele, VARIABLE Daten ablegen willst, nimm einen externen EEPROM mit I2C oder SPI, die gibt es im kleinen SO8 Gehäuse für wenig Geld, 24Cxx ist dein Freund. Noch einfacher ist, die Daten als KONSTANTEN direkt im Flash abzulegen, dann musst du auch nix downloaden. Muss das WIRKLICH variabel sein?
Danke für die ganzen Beiträge und Anregungen. Das ich eine AVR verwende und gerade den atemga16 auf mein Board gesteckt habe schrieb ich bereits. Dieser hat leider nur 512Byte EEPROM. Für die 60 LED würde das reichen ja, aber ich möchte Später auch Stripes mit 5m Länge anschließen und da brauch man bereits 900 Byte für eine Lichtkonfiguration. Jetzt wollte ich gern bis zu 7 Konfigurationen abspeichern... Okay wenn ihr schreibt, dass das im Flash blöd ist dann werde ich wohl zu einem externen EEPROM greifen müssen welches genug Platz bietet. Oder vielleicht eine Speicherkarte? Habt ihr sonst noch Hinweise zur effizienten Datenablage und schnellem Auslesen? Die unterschiedlichen Konfigurationen werden nur sporadisch geändert. Aber das muss schon dynamisch passieren können und deswegen kann ich das nicht als Konstanten anlegen. Grüße Christian
:
Bearbeitet durch User
Chris T. schrieb: > Habt ihr sonst noch Hinweise zur effizienten Datenablage und schnellem > Auslesen? In einem seriellen EEPROM (8-Beiner) hast du unendlich viel Platz, warum also viele Gedanken über eine Kompression machen? Einfach ein mehrdimensionales Array und gut ist. Und wozu brauchst du "schnelles Auslesen"? Kopier dir den aktuellen Datensatz ins RAM und verwende ihn von dort. Im Übrigen: 900Bytes seriell lesen ist in Millisekunden erledigt. Wie oft / wie schnell willst du das Muster ändern?
Alternativ denk doch mal darüber nach eine SD Karte einzubinden, da könntest die Werte direkt im PC eintragen.
Chris T. schrieb: > Das ich eine AVR verwende und gerade den atemga16 auf mein Board > gesteckt habe schrieb ich bereits. Dieser hat leider nur 512Byte EEPROM. Dann steck' halt einen Mega1284P. Der ist 100% pinkompatibel und weitgehend (allerdings natürlich nicht vollständig) softwarekompatibel. Schon hast du 4k EEP. Für ordentlich geschriebene C-Programme sollte in aller Regel ein neuer Build des Programms unter Anpassung einiger Symbole reichen. Bei Asm muss man zwar relativ wahrscheinlich manuell Hand anlegen, dafür wäre es aber in Asm auch überhaupt kein Problem, den Flash für sowas zu nutzen, wie es dir vorschwebt. Alles hat halt seine Vor- und Nachteile...
Hi, ich verstehe nicht so ganz, wieso das im Flash blöd sein soll. Daten einlesen ins Ram, zum Bootloader springen, dort Daten schreiben und passendes Flag im Eeprom setzen - Reset. Dann den nächsten Schwung Daten einlesen, jetzt ab der nächsten Adresse in den Flash usw... Das ist auch nicht komplizierter oder eher einfacher als einen externen Flash oder Eeprom zu schreiben und zu lesen, wenn man beides noch nie gemacht hat. Das Schreiben in den Flash sind nur ein paar Befehle und kann man sich von existierenden Bootloadern abkupfern. Als dummen Workaround zum lesen aus dem Flash: Man legt sich im Compiler Tabellen an mit den Daten und schaut einfach im Hex-File nach, wo der die hinpackt. Die ersetzt man dann einfach per "Bootloader". Aber selbst mit Bascom geht das garantiert eleganter. Warum das allerdings so riesige Arrays sein müssen würde mich auch mal interessieren. Was ist da so speziell dran, daß der Mega das nicht on the fly selbst erzeugen kann? Du erzeugst die Muster ja auch irgendwie, kann der µC das nicht auch selbst? Dann brauchst Du vielleicht nur ein Parameter für die Muster und fertig. Gib doch mal ein Beispiel. Gruß, Norbert
@ Norbert S. (norberts) >ich verstehe nicht so ganz, wieso das im Flash blöd sein soll. >Daten einlesen ins Ram, zum Bootloader springen, dort Daten schreiben >und passendes Flag im Eeprom setzen - Reset. Eben das! >Dann den nächsten Schwung Daten einlesen, jetzt ab der nächsten Adresse >in den Flash usw... AUA! >Das ist auch nicht komplizierter oder eher einfacher als einen externen >Flash oder Eeprom zu schreiben und zu lesen, Bitte? Ist heute Unlogik-Tag?
Hi, Dann klär mich doch bitte auf, was daran so schlimm sein soll? Falk B. schrieb: > Eben das! Ja was denn? Am Flag im Eeprom erkennt er wo es weitergehen soll. Sicher kann man auch einfach wieder an die Adresse springen, wo der nächste Datensatz eingelesen wird. Ich lasse mich ja gerne belehren, wo ist das Problem? Natürlich muß man aufpassen, daß man sich nicht das Programm selbst überschreibt. Dinge falsch machen war aber ja noch nie gut. Falk B. schrieb: > Bitte? Ist heute Unlogik-Tag? Ich habe beides gemacht und erlaube mir das vergleichen zu können. Ich bin ja sachlichen Argumenten immer offen aber die sehe ich in Deinem Beitrag leider nicht. Ich habe gerade einen Tiny861 am Wickel, der hat gar keinen Bootloaderbereich, dafür kann er sich jederzeit überall in den Flash schreiben. Das was angeblich nie bei AVR-8-Bittern ging. Datenblatt Kapitel 17. Damit wäre das noch einfacher und man kann Interrupts nutzen. Gruß, Norbert
@ Norbert S. (norberts)
>Dann klär mich doch bitte auf, was daran so schlimm sein soll?
Der normale Mensch, allen voran ein Anfänger, hat keine Lust auf solche
Stunts. Ein normaler EEPROM Zugriff, intern oder extern, kann als ganz
normale Funktion geschrieben werden und auch so behandelt werden. Keine
wilden state machines mit dauernden Neustarts etc.
Hi, na das klingt doch schon sachlicher und da magst Du teilweise Recht haben. Externes Eeprom oder Flash und es gibt eine Bib für seine IDE - das ist natürlich einfacher. Muß er nur den externen Speicher dranklemmen (und vorher besorgen!). Externen Speicher selber ansteuern ist aber viel Einarbeitung, da ist das mit dem internen Flash echt einfacher (ich würde zusehen, wie ich aus dem Bootloader wieder in den normalen Code komme ohne Reset). Klar, das ist ein Stunt aber doch nicht so abwegig wie sich Deine Antwort liest. Können wir uns darauf einigen? Vielmehr würde ich nochmal hinterfragen, warum man für LED-Stripes solche Monstertabellen braucht und das nicht im Programm mit ein paar Parametern erzeugt. Da fehlt mir die Phantasie was das sein soll. Gruß, Norbert
@ Norbert S. (norberts) >Externen Speicher selber ansteuern ist aber viel Einarbeitung, Übertreib mal nicht, per I2C oder SPI ist das eher eine Fleißaufgabe bzw. eine schöne Übung für ANfänger mit moderatem Schwierigkeitsgrad. > da ist >das mit dem internen Flash echt einfacher (ich würde zusehen, wie ich >aus dem Bootloader wieder in den normalen Code komme ohne Reset). Du hast viel zu sehr den Hackerblick. Anfänger sind mit deutlich einfacheren Sachen schon SEHR gefordert! >Klar, das ist ein Stunt aber doch nicht so abwegig wie sich Deine >Antwort liest. Können wir uns darauf einigen? Sicher. >Vielmehr würde ich nochmal hinterfragen, warum man für LED-Stripes >solche Monstertabellen braucht und das nicht im Programm mit ein paar >Parametern erzeugt. >Da fehlt mir die Phantasie was das sein soll. Lichtmuster, Lichtübergänge, whatever. Im Zeitalter der 5 Euro USB-Sticks mit vielen GB braucht man so eine Frage kaum noch zu diskutieren. Er will es, er kriegt es!
Falk B. schrieb: > Übertreib mal nicht, per I2C oder SPI ist das eher eine Fleißaufgabe > bzw. eine schöne Übung für ANfänger mit moderatem Schwierigkeitsgrad. Hab ich ja gemacht. Finde ich ätzend sowas aber vermutlich genau weil es eben eine Fleißaufgabe ist. Ist vielleicht auch Geschmackssache. Falk B. schrieb: > Du hast viel zu sehr den Hackerblick. Anfänger sind mit deutlich > einfacheren Sachen schon SEHR gefordert! Tja, dann bin ich eben ein "Hacker" der mit Bascom unterwegs ist ;-) Arduino nutzt er ja offensichtlich nicht mit M16 auf dem Steckbrett, also kann er doch auch mal in die Tiefe gehen, wenn er denn möchte... Falk B. schrieb: > Lichtmuster, Lichtübergänge, whatever. Im Zeitalter der 5 Euro > USB-Sticks mit vielen GB braucht man so eine Frage kaum noch zu > diskutieren. Er will es, er kriegt es! Nö, er kriegt Hilfe, machen muß er schon selber. Vermutlich aber nur irgendwelche Lichtmuster, Sinusverläufe der Farben die Durchwandern oder was weiß ich. Irgendie muß er die Tabellen ja auch erzeugt haben und das sicherlich nicht von Hand Wert für Wert. Das kann der Mega auch (behaupte ich mal). Also soll er einen externen Speicher nehmen, größeren µC mit entsprechendem Eeprom, internen Flash mit dem Stunt per Bootloader oder die Muster selbst erzeugen. Hat alles seine Vor- und Nachteile und aufgrund fehlender Info über die weiteren Randbedingungen kann man das so nicht beurteilen was nun der günstigste Weg ist. Gruß, Norbert
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.