Aktuell nurze ich einen Atmega328 auf einem Arduino Board mit entsprechendem Bootloader. Der verzögert den Start schon erheblich und für eine besondere Anwendung wäre ich drauf angewiesen das der Chip binnen weniger (max 10) Millisekunden läuft. Der muss nix grosses machen, nur eine Reihe von LEDs ansteuern. Das Problem ist, das dies selten ausgelöst wird und ich die dafür zur verfügung stehende Schaltleitung (12V=, max. 0.5A) nutzen wollte. Ansonsten müsste ich eine eigene Stromversorgung herstellen und mich um Stromsparmodi, aufwachen, etc. kümmern. Ginge zur Not, ist aber nicht so leicht integrierbar. Hatte daher schon überlegt die Ansteuerung mit diskreter Elektronik zu machen, aber das wird dann doch recht aufwendig, weil der Arduino bestimmte Muster erzeugt.
Dann wirf den Bootloader weg und programmier es so rein. Dann werdenm 10 ms ausreichend sein. Oder modifiziere den Bootlader so, dass er nur bei einem Tastendruck (gedrückt beim Anlegend er Versorgungspannung) etwas macht und ansonsten direkt weiter ins Hauptprogramm springt. Am besten ohne dieses mittels CRC oder sonstiges zu Prüfen, denn das dauert dann zu lange. Dann musst Du wohl so oder so einen Programmieradapter haben. Ist der vorhanden? Werner
Angehängte Dateien:
-
Mega328_ClockStartup.PNG
40 KB
Werner schrieb: > Dann werdenm 10 ms ausreichend sein. Das kommt sehr auf die Taktquelle und die Versorgung an. 10ms werden reichen, wenn der Quarz schnell anschwingt, die Versorgungsspannung schnell ansteigt und auch der Rest passt. Aber wie üblich lohnt sich hier ein Blick ins Datenblatt. Hier speziell die Kapitel 15. und 13.2.2. Werner schrieb: > direkt weiter ins Hauptprogramm springt. Am besten ohne dieses mittels > CRC oder sonstiges zu Prüfen Wozu eigetnlich sowas? Ich prüfe keines meiner "Hauptprogramme" in einem µC beim Startup mittels einer CRC. Und ich habe totzdem noch keinen Ausfall. Wer sollte im Zweifelsfall den Prüfer prüfen? Denn der sitzt ja im gleichen Flash...
:
Bearbeitet durch Moderator
Viele Arduinos haben Resonatoren drauf. Dann besteht Hoffnung. Alternativ: Interner Takt.
Der Bootloader muß raus oder deaktiviert werden und den internen RC-Oszillator als Takt.
Lothar M. schrieb: > Werner schrieb: >> direkt weiter ins Hauptprogramm springt. Am besten ohne dieses mittels >> CRC oder sonstiges zu Prüfen > Wozu eigetnlich sowas? Ich prüfe keines meiner "Hauptprogramme" in einem > µC beim Startup mittels einer CRC. Und ich habe totzdem noch keinen > Ausfall. Wer sollte im Zweifelsfall den Prüfer prüfen? Denn der sitzt ja > im gleichen Flash... Ist z. B. im Automotivebereich schon seit Jahrzehnten Usus, um z. B. Bitkipper auf Grund von EMV-Einwirkungen abzufangen - eben so ein Funktionales Sicherheitsthema (auch wenn es damals noch nicht so hieß). Sprich, das Ganze dient der Absicherung gegen Einzelfehler - wenn natürlich der gesamte Flashbereich kompromittiert ist, ist's irgendwann aus. Aber dann ist so etwas ja i. A. nur eine einzelne Maßnahme von mehreren - kommt eben immer auf die Funktionalität, das geforderte Sicherheitslevel usw. an.
Lothar, die zitierte Passage aus dem Datenblatt ist der Schlüssel, vielen Dank! Die "0ms" würden mir schon gefallen :-) Also programmieren über ISP ist angesagt und dabei würde dann die Arduino IDE den Bootloader nicht wieder mit draufschreiben?! Einen ISP-Adapter habe ich jedenfalls, aber noch nie genutzt wenn ich ehrlich bin. Hab immer den Komfort von USB verwendet. Dann ist die Startzeit auch noch dem einschwingen geschuldet und das geht offenbar mit einem RC-Glied schneller als mit einem Quarz (wusste ich auch noch nicht, hätte ich eher umgekehrt vermutet...). Scheinbar muss man ein paar Fuse-Bits umdrehen. Wie man das in der IDE macht muss ich mir noch raussuchen. Meine Anwendung wäre jetzt wohl nicht so timingkritisch das ich unbedingt einen Quarz bräuchte, also könnte ich mit einem intern erzeugten 16MHz Takt gut leben. Ok, ein hauptpunkt für die "lange" Startzeit ist wohl die Betriebsspannung. Die muss stabil sein, was einfach durch warten erreicht wird. Und wenn ich es richtig gelesen habe, wird beim Arduino der Brown-Out ausgeschaltet. Dieser muss dann wohl an, damit der Chip nicht Amok läuft. Da ich ja ohnehin irgendwie aus 12V, 5V machen muss bietet es sich ja an einen Spannungsregler zu nehmen (oder zu entwerfen) der den RESET des Atmega so ansteuert, das dieser erst high wird, wenn die Ausgangsspannung stabil ist und sobald diese absinkt, den Chip entweder stromlos macht, oder wenigstens RESET auf low zieht. Das wäre bei meinem geplanten Einsatz wichtig, denn diesen Zustandswechsel habe ich öfters.
:
Bearbeitet durch User
Olli Z. schrieb: > Also programmieren über ISP ist angesagt und dabei würde dann die > Arduino IDE den Bootloader nicht wieder mit draufschreiben?! Man kann es richtig machen, oder auch eben falsch machen. Hier mal eine Konfiguration für Standalone ATMega328p. evtl wirst du sie noch für deine Zwecke anpassen müssen
Und dann gäbe es da auch noch die Möglichkeit in den 10ms ein Kondensator zu laden der dann den 328p auch lange genug versorgen kann...
Toni Tester schrieb: > Ist z. B. im Automotivebereich schon seit Jahrzehnten Usus Da sag ich jetzt mal besser nichts zu... Oder doch: nicht alles, was im Automobilbereich "Usus" ist, ist auch gut oder sinnvoll. Mir fällt da was zum Thema "Diesel" ein. Sowas scheint dort auch "Usus" zu sein. :-/ > um z. B. Bitkipper auf Grund von EMV-Einwirkungen abzufangen Jetzt kann es aber durchaus sein, dass nicht das Flash korrumpiert wird, weil dort die Ladung ja "gefangen" ist, sondern viel eher, dass ein simples Bit in einem Register umkippt... Olli Z. schrieb: > Dann ist die Startzeit auch noch dem einschwingen geschuldet und das > geht offenbar mit einem RC-Glied schneller als mit einem Quarz (wusste > ich auch noch nicht, hätte ich eher umgekehrt vermutet...). Eigentlich logisch, denn ein Quarz muss erst mal in Schwingung kommen. Dafür reicht einmal "Anschubsen" nicht aus, das muss sachte gehen, sonst kommt zu viel Energie in den Quarz und er schwingt auf ungewollten Frequenzen. Ein Kondensator muss aber nur 1x über die Schaltschwelle des Oszillators geladen werden und kann dann über den Widerstand sofort rückgekoppelt werden.
Olli Z. schrieb: > also könnte ich > mit einem intern erzeugten 16MHz Takt gut leben. Das will ich sehen. :-P
Hans M. schrieb: > Olli Z. schrieb: >> also könnte ich >> mit einem intern erzeugten 16MHz Takt gut leben. > > Das will ich sehen. :-P Kannst Du nicht -wegen der Interferenzen mit der schnellen Atmung.
Ohne Adruino, den kein Mensch braucht, startet mein ATMega32 nach rund 80 µs. Dein 328 sollte bei 8 MHz internem Takt, in etwa die gleiche Zeit benötigen. Das ganze Bootloader Gedöns ist aus meiner Sicht völlig unnötig. Benutze den ISP und gut.
Olli Z. schrieb: > Dann ist die Startzeit auch noch dem einschwingen geschuldet und das > geht offenbar mit einem RC-Glied schneller als mit einem Quarz (wusste > ich auch noch nicht, hätte ich eher umgekehrt vermutet...). Tja: da fehlt dir offensichtlich grundlegende Bildung (allerdings auf Hochschulniveau, das Fehlen dieses Wissens wäre also nur dann schlimm, wenn du eine naturwissenschaftliche Hochschulbildung hättest). Also grobe Daumenformelfassung des Sachverhaltes: Je genauer ein Oszillator sein soll, desto höher muss seine sog. "Güte" sein. Blöderweise hat aber gerade diese Güte auch wieder den Charakter einer Zeitkonstanten, bestimmt also die "Geschwindigkeit", mit der das schwingfähige Gebilde auf Änderungen seiner Umwelt reagieren kann. Eine hohe Zeitkonstante ist hier gut und nützlich bezüglich der Einhaltung der Sollfrequenz, denn die soll ja eben möglichst konstant und unabhängig von Umwelteinflüssen sein. Sie ist aber extrem störend für den Extremfall der Sprungantwort des Systems auf das Zuschalten der Spannung, die zwar einerseits ihren Betrieb überhaupt erst ermöglicht, aber andererseits natürlich die krassest denkbare Änderung für die Umweltbedingungen des Systems darstellt... Also die ganz kurze Fassung: je genauer ein Taktgeber sein soll, desto länger braucht er nach dem Einschalten, bis er so genau ist, wie er sein sollte...
Hallo, Lothar M. schrieb: > Toni Tester schrieb: >> Ist z. B. im Automotivebereich schon seit Jahrzehnten Usus > Da sag ich jetzt mal besser nichts zu... > Oder doch: nicht alles, was im Automobilbereich "Usus" ist, ist auch gut > oder sinnvoll. Mir fällt da was zum Thema "Diesel" ein. Sowas scheint > dort auch "Usus" zu sein. :-/ Tja, gesundes Weniger-Als-Halbwissen reicht anscheinend, um sich eine Meinung zu "Bilden". Von betrügerischen Machenschaften einiger Managements (oder glaubt wirklich jemand, dass dort Entwickler eigenmächtig gehandelt haben?) auf die Unfähigkeit aller Ingenieure eines Industriezweigs zu schließen zeugt schon von einem seltsamen Weltbild. Nur um da 'mal etwas zum Nachdenken zu geben: die ISO 26262 (Funtionale Sicherheit im Bereich Automotive) ist eine Konkretisierung der ISO 61508 (Funktionale Sicherheit von E/EE/PEE-Steuerungen). Beiden gemein sind Empfehlungen zur Absicherung elektrischer und elektronischer Schaltungen in Abhängigkeit der Kritikalität der Anwendung. Und dazu gehört unter anderem auch, sicherheitsrelevante Teile des Flash-Speichers beim Hochfahren und im Betrieb durch Prüfsummen/CRC zu überwachen. >> um z. B. Bitkipper auf Grund von EMV-Einwirkungen abzufangen > Jetzt kann es aber durchaus sein, dass nicht das Flash korrumpiert wird, > weil dort die Ladung ja "gefangen" ist, sondern viel eher, dass ein > simples Bit in einem Register umkippt... Und rate 'mal: genau deswegen ist die Absicherung des Flash natürlich nicht die einzige Maßnahme, die auch im Bereich Automotive durchgeführt wird. Diese gehen von einfachen Redundanzberechnungen über ECC-abgesicherte Speicher (ja, gibt es auch in Controllern, z.B. im TriCore) und mitlaufenden Prozessorüberwachungen (Instruction Set Tests) bis zum Dual-Core Lockstep mit Fehlererkennungslogik. Der Flash kann aber eben auch korrumpiert werden, und daher sollte sein Inhalt - so er sicherheitsrelevant ist - überwacht werden. Ob man das bei einer einfachen Bastelschaltung im Hobbybereich benötigt ist eine ganz andere Frage, die wohl nur der TO für sich beantworten kann. Im Automotive-Bereich ist es jedenfalls sehr sinnvoll: Nimmt man eine übliche Fehlerrate von Flash-Speicher von 1000 FIT pro MB an (variiert je nach Reinheitsgrad des Housing-Materials) und geht man von einer Speichergröße von 1 MB und einer Stückzahl von 1 Mio Steuergeräten aus, so muss man damit rechnen, dass über die Lebensdauer der Fahrzeuge rund zehn Speicherfehler in der Gesamtpopulation je Steuergerät auftreten werden. Wenn davon in 1% der Fälle sicherheitsrelevante Parameter oder Funktionen betroffen wären, so würde man jedes Jahr damit in Deutschland eine Fahrzeugbesatzung töten. Bei inzwischen rund 10 wirklich sicherheitsrelevanten Steuergeräten im Fahrzeug wären das also zwischen 10 und 40 Verkehrstote im Jahr, die durch einen einfachen CRC-Test vermieden werden. Und das nur wegen zufälligen Bit-Kippern (z.B. durch Alpha-Strahlung). Die Absicherung gegen Alterung etc. kommt da noch dazu. Schöne Grüße, Martin
Martin L. schrieb: > Tja, gesundes Weniger-Als-Halbwissen reicht anscheinend Danke für die Ferndiagnose. > Von betrügerischen Machenschaften einiger Managements (oder glaubt > wirklich jemand, dass dort Entwickler eigenmächtig gehandelt haben?) auf > die Unfähigkeit aller Ingenieure eines Industriezweigs zu schließen > zeugt schon von einem seltsamen Weltbild. Meinst du, ein Betriebswirt wäre von alleine auf diese "kreative" Lösung gekommen? > Und dazu gehört unter anderem auch, sicherheitsrelevante Teile des > Flash-Speichers beim Hochfahren und im Betrieb durch Prüfsummen/CRC zu > überwachen. Ich sags ja: wir verwalten uns zu Tode. Wo ist denn in dieser Anwendung hier irgendwas Sicherheitsrelevantes zu sehen? > Nimmt man eine übliche Fehlerrate ... an Man kann schon viel "annehmen", und wenn angenommen jeder der Beiteiligten seine 100% Sicherheit draufschlägt, dann kommt es tatsächlich zu annehmbaren Werten, bei denen jeder erschrickt. > Wenn davon in 1% der Fälle sicherheitsrelevante Parameter oder > Funktionen betroffen wären, so würde man jedes Jahr damit in Deutschland > eine Fahrzeugbesatzung töten. Da ist er wieder, der Konjunktiv. > Bei inzwischen rund 10 wirklich sicherheitsrelevanten Steuergeräten im > Fahrzeug wären das also zwischen 10 und 40 Verkehrstote im Jahr, die > durch einen einfachen CRC-Test vermieden werden. Gut, dass wir das wissen. Wir kommen also ausgehend von angenommenen Werten über den Konjunktiv zu harten Fakten. Denn in dieser simplen Rechnung wird "Speicherfehler" mit "Tod" gleichgesetzt. Das könnte man jetzt nochmal diskutieren. Seis drum: auch wenn solche Tests auch im Flugzeug oder im Auto sinnvoll oder gar nötig sind, man muss sie nicht wie sauer Bier überall anpreisen und einbauen.
:
Bearbeitet durch Moderator
Hallo! Es geht hier darum wie man einen Atmega möglichst verzögerungsfrei starten kann und das ist, glaube ich umfänglich beantwortet werden. Dafür von mir vielen Dank! Bitte keine Diskussionen mehr über Autombiltechnik und sonstiges. Erstellt Euch dafür einen eigenen Thread und da könnt ihr dann weiterspielen "Ich bin schlauer als Du". Ist schon manchmal ein Markplatz der Eitelkeiten hier...
Olli Z. schrieb: > Hallo! Es geht hier darum wie man einen Atmega möglichst > verzögerungsfrei starten kann und das ist, glaube ich umfänglich > beantwortet werden. Dafür von mir vielen Dank! > > Bitte keine Diskussionen mehr über Autombiltechnik und sonstiges. > Erstellt Euch dafür einen eigenen Thread und da könnt ihr dann > weiterspielen "Ich bin schlauer als Du". Ist schon manchmal ein > Markplatz der Eitelkeiten hier... Schön, dass du deine Antworten erhalten hast.. Aber du hast keinerlei Recht zu bestimmen, wer hier was sagt, und was hier gesagt wird. Keinerlei! Null Komma gar nicht. Verstanden? Suche dir mal bitte jemanden, welcher dir den Kopf wieder gerade rückt.
Martin L. schrieb: > Und dazu gehört unter anderem auch, sicherheitsrelevante Teile des > Flash-Speichers beim Hochfahren und im Betrieb durch Prüfsummen/CRC zu > überwachen. Ich bin mir ziemlich sicher, dass Du damit offtopic bist. Wenn Du über Sicherheit in/um µCs diskutieren möchtest, öffne bitte einen eigenen Thread.
Arduino F. schrieb: > Aber du hast keinerlei Recht zu bestimmen, wer hier was sagt, und was > hier gesagt wird. Bestimmen kann er das zwar nicht, trotzdem war die Erinnerung, beim Thema zu bleiben, durchaus angebracht. Abeschweifungen vom eigentlichen Thema können einen Thread durchaus derart zerfasern, dass nur noch Chaos übrigbleibt, weil alle durcheinander quatschen. Hier geht es darum, die Startzeit eines ATMega328p (mit Arduino-Bootloader) zu minimieren.
Hallo, sorry für das kapern des Threads, aber als Vollzeit-Functional Safety Manager im Automobilsektor mit mehr als 10 Jahren Erfahrung fand ich die pauschalen, abfälligen Bemerkungen von Lothar bezüglich der Methoden im Automobilsektor jenseits von grenzwertig, auch wenn ich seine Fachkenntnis auf anderen Gebieten schätze. Was die anderen Punkte angeht: Glaube mal, Lothar, dass ich alle Konjunktive mit entsprechend harten Fakten hinterlegen kann. Und dass auch ich die Sinnhaftigkeit für Ollis Projekt in Frage gestellt habe, hast Du wohl auch überlesen. Und weil ich es nicht lassen kann: Auch wenn dieser Thread über ein anderes Thema ging, so wurde von Lothar doch eine valide Frage gestellt (warum überhaupt CRC), die von Toni korrekt beantwortet wurde, was allerdings von Lothar als falsche Antwort dargestellt wurde. Meiner Meinung nach lebt ein Forum davon, dass solche Fehler korrigiert werden (zugegeben: von mir vielleicht zu emotional), damit die anderen Forenteilnehmer keine Falschinformationen bekommen. Schöne Grüße, Martin
Frank M. schrieb: > Hier geht es darum, die Startzeit eines ATMega328p (mit > Arduino-Bootloader) zu minimieren. Das Thema ist allerdings abgefackelt. Bis zum Ende durchgekaut. (wie mir scheint) Machmal sinds die Nebenthemen, welche mehr Erkenntnis bringen, als die vorausgehende Trivialfrage. Ich persönlich, finde es interessant, wie man solche Blackboxen stabilisiert. Gebe aber zu, dass für mich die Integrität des EEPROM Inhaltes höhere Priorität besitzt, denn da kann ein BrownOut recht leicht einen Schreibvorgang größerer Datenmengen unterbrechen. Die Startzeiten eines AVR haben für mich keinen Mehrwert. Das Thema habe ich auch vor Jahren mal durchgearbeitet. Das reicht.
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.