Was braucht ein Mega8 zum Flash daten brennen

[Hellmut]

Hallo Freunde

Hier eine Detailfrage. Was fehlt damit ein mega8 selber Daten in seinen Flashspeicher brennen kann? Die megaxx haben ja eine ISP-Schnittstelle "on chip". Sind es bestimmte Versorgungsspannungen? Es müßte doch möglich sein das ein megaxxx Controller falls erforderlich mit externer Hardware in seine eigene ISP-Schnittstelle schreibt und darüber sein Flash brennt.

[Frank]

Dazu braucht man nix! Der AVR hat Befehle um sich selbst beschreiben zu können. Besondere Spannungen sind nicht notwendig. Ist eine reine Software-Angelegenheit.
Die Bootloader machen davon gebrauch, siehe https://www.roboternetz.de/phpBB2/vi...ght=bootloader

Gruß Frank

[Hellmut]

Aha, also kann der mega164 im lcd-Display über den I2C bus daten an den RN-Control senden, und der RN-Control diese Daten weiter über den I2C bus an einen der mega8 in den Fahrtreglern vom stupsi, welcher diese dann in sein Flash brennt. Richtig Frank?

[Frank]

Ja das ginge so. Ich nehme an du meinst die große Motorsteuerung von Stupsi. Warum sollte er es in Flash brennen. Es wäre doch einfacher wenn er die Daten im eeprom ablegt (er nutzt ja auch einen AVR).
Aber du solltest sehen ob es nicht sinnvoller ist alle Daten zentral auf dem Steuerboard abzulegen. Aber beides geht

[Hellmut]

Hallo Frank

damit Leser mein System in der jetzigen Definitionspase verfolgen können und um Denkfehler bei mir zu bemerken möchte ich hier quasi einen Baubericht fortführen.

Zwecks Fehlereingrenzung möchte ich bei meinem "schwimmenden Roboter" Funktionen die zusammengehören auch von der Implementation einkapseln und in Analogie zur objekt orientierten Programmierung Methoden definieren die von der zentralen Steuereinheit, der RN-Control mit dem mega32, angesprochen werden. Ich spreche hier von einem Subsystem.

Zum gegenwärtigen Zeitpunkt sind folgende Subsysteme bekannt:

1. Zentraleinheit
Die Zentraleinheit implementiert mit einer RN-Control mit dem mega32 hat die Aufgabe die Anweisungen des Benutzers aufzunehmen und die Ausführung an die beteiligten Subsysteme zu delegieren.
Weiterhin hat es die Aufgabe Daten der Subsysteme aufzunehmen und für die Abfrage durch Benutzer aufzubereiten.
Es hat auf Grund der Rückmeldedaten der Subsysteme die Überwachungsdaten auswerten und bei Problemen eine "fail safe Reaktion" einzuleiten.
Last, but not least, meldet es auf dem Display die wichtigsten Kendaten zum Gesamtsystem und der Subsysteme. Auf Befehl des Benutzers kann es unter Verwendung der im eigenen lokalen Speicher abgelegten Parameter Detail Status bericht liefern.

Die Befehle des Benutzers kommen zur Zentraleinheit entweder über den Empfänger der Fernsteuerung, welche die Zentraleinheit laufend scanned,
oder
über das Subsystem Display. Das Subsystem Display hat Tasten für die Befehlseingabe und wird per I2C und/oder Datenfunk mit der Zentraleinheit verbunden. Das Subsystem Display kann die Zentraleinheit "wecken".

[Hellmut]

2. Das Subsystem Display:
Das Subsystem Display besteht aus einem Grafik-LCD Display, einem Folientasten-I/F, einem mega124modul mit I2C I/F und einer Datenfunk Sende-und Empfangseinheit.
Das Display Subsystem, kurz DSS, kann das System Boot aus dem Standby-Modus wecken. Durch das Drücken einer Taste am DSS durch den Benutzer wird das Boot aus dem Standby Modus geweckt und ein erster Systemcheck pflegt die Parameter, das Grafik Display erhält die gepflegten Parameter vom Zentralsystem und meldet in einem Grobdiagramm den Status der Komponenten und bietet dem Benutzer eine Auswahl an Anweisungen an die durch Drücken der Tasten aktiviert werden können.
Jetzt kann der Benutzer durch die einzelnen Subsysteme gehen, das DSS sendet entsprechende Codes an die Zentraleinheit, die Zentraleinheit meldet die aktuellen Werte der Parameter ans DSS zurück. Der Benutzer kann so jedes Subsystem austesten und konfigurieren und sieht auf dem Display die Rückmeldungen. Das ist zum Trimmen und Einstellen der Mechanik in einem Segelboot entscheidend.
Ohne die DSS und Ihre Funktionen wäre ein Schiffsmodel in der Praxis am Ufer nicht einsatzklar zu machen und die Komplexität für den Benutzer nicht beherrschbar.
Hier Beispiele: Wenn der Mast mit den Segeln in den Rumpf gesteckt wird, die sogenannte Rigg, so werden die Schote, das sind die Seile die alles verspannen oder die Steuerung der Segel ausführen, mit der Mechanik verbunden. Hier ist auf Vorpannung, Segeleinstellung, usw. zu trimmen. In einer Controller gesteuerten Umgebung müßen die "Null-Stellungen" angefahren werden, die Steuerparameter entsprechend kalibriert werden, müßen Verstellwege gefahren und eingestellt werden. Hierzu muß man über die Tasten der DSS die Fahrtregler feinfühlig steuern können, die Positionsangaben aus den Inkrementalwertgebern angezeigt werden und kalibriert werden. Ohne eine vernünftige Software geführte Unterstützung am Ufer ohne PC nicht machbar ohne DSS.

Die DSS öffnet aber mit der Funktion der bidirektionalem Datenfunkverbindung ganz neue Möglichkeiten durch Anzeige der Telemetriedaten am Display und der Möglichkeit Interaktiv mit dem Segelboot zu kommunizieren. Das Steuern des Segelbootes soll aber sinnvoller Weise traditionell über die Fernsteuerung erfolgen.