Mehrere AVRs an einen Bus

[Florian]

^^ *ohne Worte*

[Frank]

Zum Hardware-I2C: Gibts da fertige(und dokumentierte) Routinen für AVR-GCC, die man irgendwo 'runterladen kann?

Die Frage ist durchaus berechtigt. Es gibt im Internet auch viele Bibliotheken welche I2C-Funktionen integriert haben. Etwas schwieriger ist es Bibliotheken mit dem hardware I2C-Bus (also TWI) zu finden.
Aber dürfte es inzwischen auch geben. Vielleicht kann ja mal einer der C-Experten hier was zu sagen. Finde es schade das immer wieder zur C-Programmierung aufgerufen wird und User dann mit den Fragen allein gelassen werden.

Übrigens ist die Master-Programmierung nicht so sehr komplex, hier spielt es kaum eine Rolle ob der Hardware I2C oder eine Software-Implementierung benutzt wird. Schwieriger ist es mit der Slave-Programmierung, da ist der Hardware I2C des AVR sehr empfehlenswert.
Allerdings ist es sehr schwierig Code im Netz zu finden, so das man sich da auch etwas Mühe geben muss. Da der Slave-Code doch mit etwas Aufwand verbunden ist, wird er derzeit noch gut von den jeweiligen Programmierern gehütet.

Gruß Frank

[Hellmut]

Eine Frage die periphere hier her passt. Ich plane in meinem Segelboot neben der RN-Control auch 3 der 2-fach Fahrtreglerkarten von stupsi für Getriebemotore >10A einzusetzen und diese sollen per I2C mit der RN-Control verbunden sein. Wie gehe ich am sinnvollsten vor um im System beim Testen und Debuggen nicht nur Code in die RN-Control, sondern auch in die mega jeder 2-fach-Fahrtreglerkarte zu schreiben. Bei Parametern ist wohl das EEROM der geeigneste Speicher da der flash nicht zu häufig überschrieben werden kann, oder wie liegen hier die Grenzen?
Idealer weise müßte die RN-Control über die ISP-Schnittstelle der mega8 diese programmieren? Also daten vom PC erhalten und durchreichen?

[recycle]

Bei Parametern ist wohl das EEROM der geeigneste Speicher da der flash nicht zu häufig überschrieben werden kann, oder wie liegen hier die Grenzen?

"Nicht allzu häufig" ist relativ. Die Anzahl der Schreib-Lösch Zyklen steht gleich auf der ersten Seite im Datenblatt.
Beim ATMega16 sind 10.000 für den Flash- und 100.000 für den EEProm Speicher angegeben.
Mit Daten die du selber in den Controller hochladen willst, wirst du da wohl bei beiden Speicherarten nicht so schnell Probleme bekommen.

Idealer weise müßte die RN-Control über die ISP-Schnittstelle der mega8 diese programmieren? Also daten vom PC erhalten und durchreichen?

Vierlleicht klappt das ja mit Bootloadern und Programmierung über die serielle Schnittstelle .
Ich meine ich hätte neulich irgendwo gelesen, dass es in Bascom Befehle gibt mit denen man relativ einfach "Software-UARTS" simulieren kann.

Damit könnte das RN-Control dann an der seriellen Schnittstelle Programmcode entgegennehmen und über irgendwelche anderen Pins und Software-UART an die entsprechenden Sub-Controller weitergeben.
Allerdings müsste man dem RN-Controll dann irgendwie klarmachen an welchen Sub-Controller er den Code weitergeben muss und wenn das RN-Control selber auch über die serielle Schnittstelle programmiert werden soll wird es wohl noch komplizierter.

Soweit ich das verstanden habe, wartet ein Bootloader auf eine bestimmte Daten-Sequenz um zu unterscheiden, ob es nur serielle Daten sind oder neuer Programmcode.
Wenn diese Sequenz für die verschiedenen Controller unterschiedliche ist oder eine zusätzliche Adresse enthält, könnte ich mir schon vorstellen, dass man dieselben Daten an alle Controller schickt und nur der richtige fühlt sich angesprochen.

Dafür müsste man aber nicht nur die Bootloader selber anpassen, sondern auch die Programmiersoftware auf dem PC.

Ich glaube es wäre einfacher und praktischer die seriellen Anschlüsse von allen Controllern zentral an eine Stelle zu legen und da dann entweder für jeden einen eigenene Stecker oder einen Umschalter anzubringen.
Beim seriellen Anschluss sind es ja nur 3 Leitungen pro Controller und man kann die seriellen Anschlüsse dann ausser zum Programmieren auch gleich zum debuggen verwenden.

[Hellmut]

Hallo recycle

Du hast schon recht, das Flash und der EEROM haben wahrscheinlich hinreichend häufige Wiederbeschreibbarkeit. Betreff des Themas Parameterübergabe habe ich mich nicht richtig verständlich gemacht. Sorry.
Hier gelten 2 verschiedene Szenarios:
1. Entwicklungsumgebung:
Standort Werkstatt daheim. Hier ist der PC der mit ausreichend seriellen und parallelen Schnittstellen versehen innerhalb von PonyProg Programme und Daten zu den diversen Controllern runterladen und ins Flash brennen kann in dem man einfach die serielle und die parallele Schnittstelle die PonyProg beim I/F zum megaxx anspricht umkonfiguriert und so das richtige Ziel-Subsystem anspricht. Gleichfalls ist es hier lösbar Datentabellen im Flash, im EEROM oder im SRAM zu pflegen.

Die diversen Controller steuern die diversen mechanischen und elektronischen Vorrichtungen.

Der kritische Teil nach meinem Befürchten ist aber der Betrieb im Feld, sprich am Seeufer, der natürlich in der Werkstatt programmiert, getestet und verbessert wird. Deshalb erläutere ich hier unter Punkt 2:

2. Zielumgebung:
In der Zielumgebung ist kein PC vorhanden, dort ist das Segelboot mit einem I2C Bus welcher das Segelboot mit der Steuereinheit in der Hand des Benutzers verbindet. Die Steuereinheit ist ein LCD-Display mit Tasten, einem mega124 und einem I2C I/F welches es mit der RN-Control und ihrem I2C Bus verbindet. Jedes der Subsysteme inkl. der LCD-Displayeinheit haben natürlich eine eigene Adresse an diesem I2C-Bus.
Über den I2C Bus kann der mega124 im LCD-Display, der Steuereinheit, als Busmaster, jedes der Systeme am I2C-Bus adressieren und Daten überspielen. Die Frage aber ist, wie stelle ich sicher das die überspielten Daten beim Empfänger nicht flüchtig gespeichert werden?

Ein für meine Lösung erschreckendes Szenario wäre das ich die RN-Control um diverse parallele Schnittstellen erweitern muß um so zwischen der RN-Control und jedem megaxx eine ISP-Verbindung bereit zu stellen! Das wären im Fall meines Segelbootes 5 solche parallele Schnittstellen mit 5 ISP-Kabeln die zu 5 ISP I/F der jeweiligen megaxx der Subsysteme führen!

Der mega124 würde also auf Grund der Benutzereingaben über die Tasten am LCD-Display Daten per I2C-Bus an die RN-Control senden, die RN-Control würde diese Daten im SRAM Zwischenlagern und dann die geeignete Verbindung in einer Sterntopologie, RN-Control Zentral, Subsysteme und LCD-Display in Sterntopologie per Zusatzboard an der RN-Control mit 5 parallelen Schnittstellen das ISP-I/F des betreffenden Controllers ansprechen und die Daten in der im Flash abgelegten Tabelle des jeweiligen megaxx der Subsysteme aktualisieren. Muß das so sein?

Gibt es eine Möglichkeit einen megaxx Controller über sein eigenes im eigenen Flash liegendes Programm in sein eigenes Flash eigenständig Daten die er z.B. im Sram gepuffert hat, zu brennen? Wenn ja, so entfiele die Notwendigkeit die ISP-Verbindungen zwischen der RN-Control zu den diversen Subsystemen zu implementieren. Die jeweiligen megaxx würden selber ihre Daten im eigenen Flash aktuallisieren.

[Gottfreak]

Gibt es eine Möglichkeit einen megaxx Controller über sein eigenes im eigenen Flash liegendes Programm in sein eigenes Flash eigenständig Daten die er z.B. im Sram gepuffert hat, zu brennen?

So eine Möglichkeit kenne ich nicht. Da du aber über diese Verbindung wahrscheinlich nicht richtig programmieren(ich weis ja nicht, was deine Display-Einheit kann) sondern nur Parameter einstellen willst, bietet sich tatsächlich das EEPROM an. Da kannst du Parameter, die über den I2C-Bus (zur Laufzeit)geändert werden, abspeichern und nach jedem Reset wieder auslesen(viele Entwicklungsumgebungen bieten sogar die Möglichkeit, Variablen direkt im EEPROM zu deklarieren.).

[Hellmut]

Hallo Gottfreak

Ich verwende Bascom, ich gehe davon aus das geht. Ich hab schon vermutet das es auf den EEROM hinausläuft. Übrigens, völlig richtig, es sind nur Parameter. Danke

[Frank]

Ich würde auch zum EEprom raten.
Ich weiss nicht genau was du für Daten sicherst, aber manchmal kann man Kompromisse machen. Bei einem meiner letzten Projekte hab ich Daten immer nur periodisch im Eeprom abgelegt. Da sich die Daten mehrfach am Tag geändert haben, wollte ich nicht jedesmal das EEprom neu beschreiben, sondern habe dies nur bei jedem zwanzigsten EIntrag gemacht. Dadurch ist der Datenverlust zumindest beschränkt.

Gruß Frank

[Hellmut]

Hallo Frank

Die Fahrtregler verwende ich um Segel zu betätigen, sowie um Deckaufbauten zu bewegen. Bei allen diesen Funktionen ist es wichtig am Seeufer, bevor man das Boot zu Wasser lässt, alle Einstellungen zu justieren, da beim Zusammenbau alle Schote, also Seile/Schnüre, die den Mast fixieren und die Segel steuern nicht wieder exakt die Position haben wie beim letzten Mal. Somit definiert man wieder die Referenzpositionen und bestimmt die Verstellbereiche. Da ich hier die 3 Impulse der Inkrementalwertgeber auswerte um Positionen anzufahren oder mit auswerte um technische Defekte im Betrieb zu erkennen, müßen die Parameter welche die verschiedenen Funktionen in ihrer Ausführung bestimmen angepaßt werden. Außerdem ist das ein iterativer Prozeß bei dem man ständig trimmt und verbessert. Auch muß man Funktionstests ausführen um dabei die Parameter zu optimieren. Diese Freiheit ist für die Akzeptanz am See entscheidend. Ein Verlust dieser Daten im Betrieb kann das Segelboot zum kentern und zum Wassereinbruch führen, sowie durch die Kraft der eingesetzten Dunkermotoren das Boot zerstören. Das verlangt die Daten nicht flüchtig zu speichern. Ja, um alle diese Justagen am Seeufer ohne PC durchzuführen ist ein LCD-Display mit Tastenfeld ideal.

Allerdings plane ich, wenn die Funktionen über einen physikalisch vorhandenen I2C-Bus zwischen LCD-Display und Boot funktionieren, diese Schnittstelle durch Funkübertragung zu ersetzen. Jetzt wird das LCD-Display zum mächtigen Fernwirkinstrument, sowie zum idealen Werkzeug als Multifunktionsdisplay welches erlaubt das Boot zu jedem Zeitpunkt vom Ufer aus durch die gesendeten Telemetriedaten zu überwachen und interaktiv abzufragen, sowie von Ferne zu programmieren. Die Möglichkeiten für den Schiffsmodellbauer sind einfach gigantisch und würden bei Schleppern, oder Kriegsschiffmodellen, welche umfangreiche Sonderfunktionen haben tolle Möglichkeiten eröffnen.

[muraad]

Hab grad ne Seite mit C Bibliotheken gefunden, die sehr interessant sind.
http://www.procyonengineering.com/avr/avrlib/

"I2C Serial Interface Function Library
This library provides the high-level functions needed to use the I2C serial interface supported by the hardware of several AVR processors. The library is functional but has not been fully tested yet and is still expanding. Thanks to the standardization of the I2C protocol and register access, the send and receive commands are everything you need to talk to thousands of different I2C devices including: EEPROMS, Flash memory, MP3 players, A/D and D/A converters, electronic potentiometers, etc."

Da gibts sogar was für GPS, IDE/ATA, Graphik LCD usw. Die Seite ist überhaupt sehr interessant hab sie grad erst gefunden.
Muraad