Hallo, ich vermute, die Antwort lautet nein, weil ich nichts in dieser Richtung gefunden habe. Um aber sicher zu gehen hier die Frage: Gibt es den Atmega1284 vom Speicher her auch eine Nummer größer, z.B. als Atmega2564? (bei meinem Projekt wird der Programmspeicher langsam knapp, weil so viele externe Daten benötigt werden)
Nein, 1284 ist da das Ende der Fahnenstange. Eventuell einen externen EEPROM oder Flash benutzen für derartige Daten? Beim RAM-Ausbau ist der 1284 ja eher erste Liga.
Frank schrieb: > wird der Programmspeicher langsam knapp Mit Programmspeicher würde man den Flash bezeichnen, aber warscheinlich meinst du das RAM, also den Arbeitsspeicher?
Wenn es um mehr RAM geht könnte man den ATMega2560 mit externen RAM ausstatten. Der hat ein "External Memory Interface".
Danke für die schnellen Antworten! Es geht um den Programmspeicher, in dem auch Daten abgelegt sind. Das RAM ist völlig ausreichend. Damit ist meine Frage auch schon beantwortet, noch mal Danke an Euch!
Frank schrieb: > Es geht um den Programmspeicher, in dem auch Daten abgelegt sind. Na dann passt der ATMega2560 ja ganz gut oder?
Arduinoquäler schrieb: > Na dann passt der ATMega2560 ja ganz gut oder? Schaue ihn mir grade an. Der kann aber maximal 16MHz, wenn ich das richtig sehe (ich brauche 20MHz).
Frank schrieb: > Schaue ihn mir grade an. Der kann aber maximal 16MHz, wenn ich das > richtig sehe (ich brauche 20MHz). Sieht so aus. Wofür meinst du, 20 MHZ zu brauchen? Hast du WIRKLICH so hohe Anforderungen oder ist eher dein Konzept nicht so gut?
SPI-Flash, deutlich fixer als ein EEPROM (meisst I²C) Beliebig groß verfügbar
Der Programmspeicher ist 16 Bit breit. Mit dem 64 Bit Programmzähler kann man also maximal 128k Byte Programmspeicher adressieren. Beim ATmega2560 haben sie diese Hürde durch ein zusätzliches Bit ausserhalb des Programmzählers überwunden. Allerdings ist das umständlich anzuwenden und wirkt sich negativ auf die Performance aus (zusätzlich zu der 16MHz Beschränkung). Dieses Konstrukt erinnert mich sehr stark an die Speicher-Erweiterungen in PC's, als das direkt adressierbare Limit 1 Megabyte war. Mein Tipp: Wenn du mit 128kB Programmspeicher nicht mehr auskommst, dann wechsle zu waschechten 32bit Controllern. Es gibt da einige, die von der Komplexität und Funktionsumfang nahtlos an den ATmega1284 anschliessen. Zum Beispiel der STM32F103VE. Zum Üben würde ich Dir ein Nucleo64-F103RB Board (mit 128kB) empfehlen. Das liefert eine gut dokumentierte solide Grundbeschaltung sowie einen Programmieradapter mit USB-UART, den du auch zum Programmieren anderer STM32 Controller wiederverwenden kannst. Alles, was du damit lernst, kannst du 1:1 auf die grösseren STM32F103 Modelle anwenden. Die Chips der STM32F103 Reihe sind sogar zueinander binärkompatibel. Schau Dir das an, um einen ersten Eindruck zu bekommen: http://stefanfrings.de/stm32/index.html
Der läuft auch mit 25 MHz, probiere es einfach aus. Übertakten ist in dem Bereich bis 30 MHz fast immer möglich. Wenn der interne Oszillator nicht mit dem angeboten Quartz will, dann halt mit einem externen Quarzoszillator - das läuft... Für gewerbliche und/oder sicherheitsrelevante Themen natürlich eher nicht. Bei mir laufen 50% meiner Projekte so über Jahre stabil.
Hier hast du eine Übersicht über die STM32F103 Serie: https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html -- Falls sich wieder jemand über STM32 Jünger beklagen will: Ich empfehle diesen, weil er (abgesehen vom ESP8266) der einzige ist, den ich benutzt habe. Ich bin damit so zufrieden, dass ich mir andere Alternativen nicht angeschaut habe. Zweifellos gibt es auch andere Marken mit guten Produkten. Ich möchte niemanden daran hindern, sie auch die anzuschauen.
Uwe D. schrieb: > Bei mir laufen 50% meiner Projekte so über Jahre stabil. Die anderen laufen hoffentlich nicht instabil.
Uwe D. schrieb: > Der läuft auch mit 25 MHz, probiere es einfach aus. ATmega2560? Würde ich meine Hand nicht dafür ins Feuer legen. Der ist vom Design her ziemlich alt (älter noch als ATmega1280 etc.). Wenn die Performance wirklich nicht reicht, würde ich auch zu einem ARM greifen.
Stefanus F. schrieb: > Der Programmspeicher ist 16 Bit breit. Mit dem 64 Bit Programmzähler > kann man also maximal 128k Byte Programmspeicher adressieren. > Also der PC ist ebenfalls 16Bit breit, den Rest würde ich teilen...
Stefanus F. schrieb: > Uwe D. schrieb: >> Bei mir laufen 50% meiner Projekte so über Jahre stabil. > > Die anderen laufen hoffentlich nicht instabil. Die anderen 50% sind nicht übertaktet. Manchmal macht Stromsparen Sinn :-).
Uwe D. schrieb: > Also der PC ist ebenfalls 16Bit breit, den Rest würde ich teilen... Beim ATMega2560? 24Bit breit! (intern mögen davon nur 22 Bit genutzt werden) Zumindest werden soviel Bit, 3Byte, bei einem Call auf dem Stack abgelegt.
Stefanus F. schrieb: > Mit dem 64 Bit Programmzähler > kann man also maximal 128k Byte Programmspeicher adressieren. Also die 64 Bit finde ich schon faszinierend. Und sooooovieeeel auf einem Mikrokontroller .... ;-)
Uwe D. schrieb: > Mit dem 64 Bit Programmzähler > kann man also maximal 128k Byte Programmspeicher adressieren. Sorry, soll sollte natürlich "16 Bit Programmzähler" heissen.
Uwe D. schrieb: > Also der PC ist ebenfalls 16Bit breit, den Rest würde ich teilen... Arduino Fanboy D. schrieb: > Beim ATMega2560? 24Bit breit! Zitat aus dem Datenblatt: "The ATmega640/1280/1281/2560/2561 Program Counter (PC) is 15/16/17 bits wide, thus addressing the 32K/64K/128K program memory locations."
Stefanus F. schrieb: > Sorry, soll sollte natürlich "16 Bit Programmzähler" heissen. Wieso, "64 Bit Programmzähler" klingt doch schick. Da weiss man einfach mehr (64 ist ja mehr als 17) als die anderen.
Stefanus F. schrieb: > Zitat aus dem Datenblatt: "The ATmega640/1280/1281/2560/2561 > Program Counter (PC) is 15/16/17 bits wide, thus addressing the > 32K/64K/128K program memory locations." Wie auch immer... Beim Push/Pop des PC werden 24Bit transportiert. Alleine das ist schon der Grund, dass der 2560 in der Praxis ein paar Prozent langsamer ist, als z.B. ein ATMega328P, bei gleichem Quarz. Als Zusätzliche Bremse kommt das Trampoline Verfahren hinzu. Daten aus dem Flash fischen, braucht auch immer ein bisschen länger.
Stefanus F. schrieb: > Falls sich wieder jemand über STM32 Jünger beklagen will: Ich empfehle > diesen, weil er (abgesehen vom ESP8266) der einzige ist, den ich benutzt > habe. Ich bin damit so zufrieden, dass ich mir andere Alternativen nicht > angeschaut habe. Du solltest Dir ernsthaft mal wengistens andere STM32 ansehen und nicht ständig Oldtimer empfehlen. Die STM32F103 Reihe ist jetzt über 10 Jahre alt, die stammen aus der Zeit als ST mit den Dingern gerade erst anfing. Das Datenblatt das ich von denen gerade von der ST Seite gezogen und geöffnet habe ist von Mai 2015 (ST32F103xF STM32F103xG). Das ist in etwa vergleichbar mit ATMEGA8 / ATMEGA16 zu ATMEGA88PA / ATMEGA164PA. Kann man machen, aber irgendwie legt man sich damit nur Steine in den Weg. Stefanus F. schrieb: > Es gibt da einige, die von der Komplexität und Funktionsumfang > nahtlos an den ATmega1284 anschliessen. > Zum Beispiel der STM32F103VE. Und das halte ich für eine völlig bescheuerte Aussage. Der Knackpunkt ist doch nicht, dass die Dinger ähnlich viele Timer haben. Der Knackpunkt ist, dass jede andere Architektur in die man sich neu einarbeten will erstmal komplett fremd ist. Das fängt bei der Struktur der Datenblätter an, zieht sich über die Includes in die Funktionseinheiten und wie man diese letztlich benutzt und was für Features diese im Detail haben. Grausam ist auch die Tendenz immer weniger in die Datenblätter zu packen weil es ja "fertige" Treiber für alles vom Hersteller gibt. Das einzige was man (zunächst) weitgehend ignorieren kann ist der Core an sich, denn um den kümmert sich ja der Compiler. Es gibt auch XMEGA, AVR32 und ATSAM um mal beim gleichen Hersteller zu bleiben, aber selbst die XMEGA sind ein ganz anderes Gemüse als die AVR. Mich hat eine technische Notwendigkeit (CAN-FD) dazu bewegt mich in die ATSAMC21 und ATSAME51 einzuarbeiten. Und das ist ein langer steiniger Weg an dessen Ende ich noch lange nicht bin, aber diese Investition hat sich für mich schon in mehrfacher Hinsicht bezahlt gemacht, zu ähnlichen Preisen wenn nicht sogar niedriger bekomme ich jetzt sehr viel mehr Peripherie, Speicher und Rechnenleistung in verschiedenen Ausbaustufen und in Gehäuse von 32 Pins bis 100 Pins (oder gar 120 beim E51). Gerade die ATSAMx5x sind ein riesen Zoo bis hoch zum E54 mit Ethernet. Also ja, wenn man an die Grenzen der bisher genutzen Controller-Plattform kommt und diese zudem langsam in die Jahre kommt, auf jeden Fall mal umschauen was es denn noch so gibt! Aber man wechselt doch nicht von einem toten Pferd auf ein Ex-Rennpferd das kurz vor dem Ende ist. Natürlich ist es verlockend wenn man das fast tote Pferd praktisch geschenkt bekommt (Bluepill) und gerade ST ist am lautesten dabei deren Produkte unter das Volk zu bringen. Aber manchmal kann sich geschenkt auf lange Sicht als sehr teuer erweisen. Und der Wechsel tut auf jeden Fall weh, da muss man durch. Ganz neue Familien wie zum Beispiel die ATSAMD51/ATSAME51 sind auch mit Vorsicht zu genießen, im ersten Schuss sind die Errata noch am längsten. Von den ATSAMD51/ATSAME51 müsste dieses Jahr die B Revision kommen die etliche der ersten Bugs fixen dürfte.
Ich habe den STM32F103 ausprobiert, weil er für mich in dem gewünschten Format (Passend für Steckbrett+Lochraster) leicht und günstig zu bekommen ist. Ich habe die nötige Doku problemlos gefunden und alle Fragen wurden hier im Forum rasch geklärt. Für meine 5 Basteleien pro Jahr habe ich keine Lust, immer dem neuesten Modell hinterher zu laufen. Man muss ja auch erst einmal lernen, damit umzugehen. Die Motivation dazu wird erst kommen, wenn die bereits vorhandenen Chips aus meiner Bastelkiste für irgendeine Anwendung schlecht geeignet sind oder wenn ich sie nicht mehr kaufen kann. Noch werden praktisch alle AVR und die gesamte STM32F103 Serie produziert. Selbst nach deren Abkündigung kann man sie noch viele Jahre lang problemlos in kleinen Mengen kaufen. Deine Einschätzung bezüglich toter Pferde kann ich daher nicht teilen. Nachdem du vom STM32F103 und einigen anderen abgeraten hast, welchen würdest du denn konkret als Nachfolger zum ATmega1284 empfehlen?
Frank schrieb: > (bei meinem Projekt wird der Programmspeicher langsam knapp, > weil so viele externe Daten benötigt werden) Wenn sich die Daten einigermaßen gut komprimieren lassen (z.B. Bild- oder Tondaten), dann könnte man damit vielleicht ein bisschen einsparen. Hängt aber davon ab, um was es eigentlich geht.
Als aktuellen Nachfolger des STM32F103 sehe ich den STM32F303, den es auch als Nucleo Board gibt.
Stefanus F. schrieb: > Nachdem du vom STM32F103 und einigen anderen abgeraten hast, welchen > würdest du denn konkret als Nachfolger zum ATmega1284 empfehlen? Wenn man nur einen Hammer hat, sieht jedes Problem aus wie ein Nagel. Mein Hammer der Wahl wäre gerade der ATSAMC21, das bedeutet aber noch lange nicht, dass der zum Problem des Threadstarters passt. Der Speicher wird knapp und 20MHz sollen es sein, mehr wissen wir doch gar nicht. Vielleicht sind 5V Betrieb notwendig (das Design läuft jetzt ja offensichtlich auf 5V), vielleicht sind die Pins knapp, vielleicht darf es auch mehr Peripherie sein. Der ATSAMC20G18A-AU könnte der richtige Ersatz sein, so mit 256k FLASH, 5V und Cortex M0+ bis 48MHz, vielleicht aber auch nicht, weil ein TQFP 48 mit 0,5mm Pitch für den Threadstarter nicht lötbar ist. Vielleicht wäre der ATSAMC20E18A-AU eine gute Wahl, weniger Pins aber fast die gleichen Features in einem TQFP 32 mit 0,8 mm Pitch. Vielleicht besteht die unmittelbar einfachste Lösung des Problems aber auch darin einen externen FLASH Baustein an den ohnehin schon vorhandenen SPI mit anzuklemmmen.
Rudolph R. schrieb: > das bedeutet aber noch > lange nicht, dass der zum Problem des Threadstarters passt. Ganz recht, deswegen würde ich es begrüssen, wenn der Frank mal erzählt, welche Eigenschaften sonst noch notwendig oder wünschenswert sind. Dann können einige Mitglieder sicher etwas passendes empfehlen.
Weg mit dem Troll. Die Info gibt es aus erster Hand auf der Micochip webseite.
планар эпытахзыал троль schrieb: > Die Info gibt es aus erster Hand auf der Micochip webseite. Nein, doch, ooh! Nur hat Microchip hunderte im Programm, da kann eine Diskussion schon bei der Orientierung helfen. Und STM ist ja nur einer von vielen, die Bäume für den Wald liefern.
Wie gesagt soll eine Menge 'Plunder' (Grafikdaten) in den Programmspeicher. Weil das System ansonsten schon steht und läuft, werde ich jetzt schauen, wie Daten eingspart werden können. Hätte es einen Atmege2564 gegeben, hätte ich mir die Mühe gespart und wäre einfach umgezogen. STM32 progge ich schon länger, will mir aber die Portierung sparen. Danke für eure Hilfe!
Frank schrieb: > Wie gesagt soll eine Menge 'Plunder' (Grafikdaten) in den > Programmspeicher. Was sollen Grafikdaten im Programmspeicher? Die gehören doch nur auf's Ausgabegerät! Also: SD-Card. Billigste Lösung, um solchen Schrott mal eben nachzuladen. Ist (bei sinnvoller Programmierung) nichtmal sehr viel langsamer, als würde es aus dem Flash des Controllers geholt werden, insbesondere dann nicht, wenn sowieso der Pfad zum Ausgabegerät der limitierende Faktor in der Gesamtkonstruktion ist...
c-hater schrieb: > Was sollen Grafikdaten im Programmspeicher? Die gehören doch nur auf's > Ausgabegerät! Solange man die "Grafik"-Anwendung nicht kennt kann man viel behaupten wenn der Tag lang ist.
Frank schrieb: > STM32 progge ich schon länger, will mir aber die Portierung sparen. Dann war die ganze Mühe rund um 32bit Controller unnötig. Sage so etwas nächstes mal bitte gleich im Eröffnungspost. Um bei 8bit AVR zu bleiben kann man dann nur noch die Xmega Controller empfehlen. Wenn du Glück hast, musst du nur die Initialisierung der Taktquelle hinzufügen. > SD-Card. Billigste Lösung, um solchen Schrott mal eben nachzuladen. Leider auch die unzuverlässigste Lösung - sollte man bedenken. Falls das für Frank kein Problem ist, unterstütze ich diesen Vorschlag.
Bewunderer schrieb: > c-hater schrieb: >> Was sollen Grafikdaten im Programmspeicher? Die gehören doch nur auf's >> Ausgabegerät! > > Solange man die "Grafik"-Anwendung nicht kennt kann man viel > behaupten wenn der Tag lang ist. Sondern wohin? Das schreit förmlich nach SD-Card oder externem EEPROM. Ich nutze zum Puffern auch externen seriellen RAM, das bissel Overhead...
Der Programmspeicher ist immer vorhanden, einfach zu benutzen und hat deterministisches Timing, im Gegensatz zu externen Lösungen - insbesondere SD-Karten. Heißt: Das Gerät ist billiger, zuverlässiger und energiesparsamer, wenn man den vorhandenen Flash nutzt. Außerdem ist eine 8 GB SD-Karte mit FAT32 irgendwie bescheuert, wenn man einfach nur ein paar Hintergrundbilder und UI-Elemente zeichnen muss. Aber gut, wer's braucht...
Bewunderer schrieb: > Solange man die "Grafik"-Anwendung nicht kennt kann man viel > behaupten wenn der Tag lang ist. Nö, das kann man sogar behaupten, ganz ohne die konkrete Anwendung zu kennen. Denn allenfalls gehören sie noch in's RAM (um daran rumzupfriemeln), aber niemals in den Programmspeicher. Der ist (wie der Name schon sagt) eigentlich für Code gedacht. Die Nutzung für konstante Daten ist OK, solange genug Platz dort ist (im konkrekten Fall ja offensichtlich nicht mehr). Triviale Logik, das sollte jeder Programmierer beherrschen...
Stefanus F. schrieb: >> SD-Card. Billigste Lösung, um solchen Schrott mal eben nachzuladen. > > Leider auch die unzuverlässigste Lösung Inwiefern unzuverlässig? Das ist doch Unsinn. Solange die SD-Card nur gelesen wird, ist sie genau so zuverlässig wie der Flash eine µC, von Kontaktproblemen mal abgesehen. Und die äußern sich bei Grafikdaten halt nur durch "strange" Grafik, beeinflussen die Funktion aber ansonsten nicht. Also sehr unkritisch und obendrein kinderleicht zu diagnostizieren.
S. R. schrieb: > Außerdem ist eine 8 GB SD-Karte mit FAT32 irgendwie bescheuert, wenn man > einfach nur ein paar Hintergrundbilder und UI-Elemente zeichnen muss. Niemand, aber wirklich absolut niemand zwingt dich, ein Filesystem in einer RO-Anwendung überhaupt zu benutzen, ein Blockdevice tut's genauso. Aber selbst wenn man das aus Komfortgründen tut: Dann gibt's halt nur eine einzige (sequentielle) Datei in diesem FS. Deren Inhalt kannst du dir als Image eines virtuellen Flash-Chips vorstellen... Gerade dafür ist FAT übrigens richtig gut, denn solange es nur eine einzige Datei gibt, macht es schon von alleine alles richtig für diese Anwendung...
c-hater schrieb: > Inwiefern unzuverlässig? Es kommt häufig vor, dass die gerade gekaufte SD im SPI Modus nicht funktioniert, während eine andere geht. Eigentlich sollten alle gehen. Wenn man dazu einen schlechten Pegelwandler verwendet, wie es zahlreiche extra für Arduino angepriesene Adapter tun, ist selbst mit kompatiblen Karten unzuverlässige Funktion zu befürchten. Wurde hier ja such schon oft genug berichtet. > Solange die SD-Card nur gelesen wird Klar davon war ich ausgegangen.
Stefanus F. schrieb: > Es kommt häufig vor, dass die gerade gekaufte SD im SPI Modus nicht > funktioniert, während eine andere geht. Das ist dann ein Grund zur Wandlung: Die Karte erfüllt die SD-Spezifikation nicht. Da gibt es für den Verkäufer keinerlei Ausflüchte. Für den Käufer ist es nervig und zeitfressend, aber kostenneutral. Wo ist das Problem? > Wenn man dazu einen schlechten Pegelwandler verwendet, wie es zahlreiche > extra für Arduino angepriesene Adapter tun Wen interessiert schon irgendwelcher Arduino-Dreck? Höchstens Arduidioten...
c-hater schrieb: > Wo ist das Problem? Waren Umtauschen kostet Zeit und Geld. Oft sogar mehr, als der eigentliche Warenwert. Wenn du das oft genug im selben Laden machst, verkaufen Sie Dir nichts mehr oder zicken beim Umtausch zunehmend. > aber kostenneutral. Von wegen. Schlimmstenfalls muss ich einen neuen Karton besorgen, dann ein bahn Ticket kaufen, um zur Post zu fahren, dort 20 Minuten anstehen, und noch ein Ticket für die Rückfahrt kaufen. Der Versand kostet je nach Ziel-Land ca. 4 bis 15 Euro, mit Versicherung noch mehr.
Stefanus F. schrieb: > Waren Umtauschen kostet Zeit und Geld. Oft sogar mehr, als der > eigentliche Warenwert. Wenn du das oft genug im selben Laden machst, > verkaufen Sie Dir nichts mehr oder zicken beim Umtausch zunehmend. Allerspätestens in dieser Situation würde wohl jeder intellektuell Normalbegabte eine andere Quelle für seine SD-Karten wählen... Du nicht?
Arduino Fanboy D. schrieb: > Beim Push/Pop des PC werden 24Bit transportiert. Klar, weil man 3 Byte pushen muss, um 17 Bits zu speichern. :)
c-hater schrieb: > Das ist dann ein Grund zur Wandlung: Die Karte erfüllt die > SD-Spezifikation nicht. Falls es eine Mikro-SD-Karte ist: für die ist der SPI-Modus nicht vorgeschrieben.
c-hater schrieb: > Allerspätestens in dieser Situation würde wohl jeder intellektuell > Normalbegabte eine andere Quelle für seine SD-Karten wählen... Das mag sein. Ein ordentlich intellektuell ausgestatteter Mensch würde hingegen anfangen, die Lösung zu hinterfragen. Du nicht?
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.