mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Viele µCs seriell verbinden


Autor: Michael Klenner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich möchte eine Sensorkette aufbauen. Die einzelnen Sensoren bekommen 
jeweils einen kleinen µC, ich dachte an Atmel ATTINY... Es sollen also 
kleine Module werden, die in einer Kette mit möglichst wenig Leitungen 
verbunden werden sollen. Dazu soll die Platine an der einen Seite eine 
Steckverbindung zum vorigen Modul und an der gegenüberliegenden Seite 
eine Steckverbindung zum nächsten Modul haben.

Ich wollte mir nun einen µC heraussuchen mit UART und dann jeweils RxD 
als Eingang vom vorigen Modul und TxD als Ausgang zum nächsten Modul 
beschalten. Ansonsten würde nur noch die Spannungsversorgung 
durchgeschleift. Jedes Modul würde die von RxD kommenden Daten einfach 
an TxD weiterleiten und zusätzlich die eigenen Daten anfügen. Dazu 
müsste man natürlich einen kleinen Puffer vorsehen und aufpassen, dass 
die maximal mögliche Datenrate nicht überschritten wird. Jedes Modul 
müsste seine Daten in ein Protokoll packen und mit einer "Herkunfts-ID" 
versehen.

Am liebsten wäre es mir, wenn sich die Kette selbst konfigurieren 
könnte. Also sprich, die Module schauen sich in ihrer Nachbarschaft um, 
finden heraus, welches das erste ist, und konfigurieren sich 
entsprechend eine ID für die Kommunikation anhand ihrer physikalischen 
Reihenfolge. Eine Idee, wie man das Protokoll gestalten könnte?

Die Krönung wäre dann, wenn man sogar noch ein Softwareupdate aller 
Module hinbekommen könnte, indem man den Programmer an den Anfang der 
Kette anschließt.

Was meint ihr, wäre sowas umsetzbar? Wichtig wäre mir, dass die Module 
einfach und klein bleiben. Klar könnte man vorhandene Schnittstellen wie 
CAN etc. nutzen, aber ich möchte den hardwareseitigen Aufwand so gering 
wie möglich halten.

Vor dem Programmieren habe ich keine Angst.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit UART gibts nur einen ATtiny, aber der hat keinen ADC.

Vielleicht das hier:

Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)"


Peter

Autor: Der Daniel (derdaniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dich mal nach I2C alias TWI um, das sollte relativ viel können.

Autor: qwerty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmmm im Prinzip ja. Ich würde das allerdings einfacher lösen:
Die µP hintereinander, den TxD vom einen an den RxD vom anderen,
ist noch OK. Protokoll mit "anhängen" ist suboptimal.
Einfacher jeder µP hat seine eigene ID. Der Master am Anfang
sendet eine Anfrage mit ID, die wir solange weitergereicht bis
der adresierte µP "gefunden" ist. Der µP ersetzt die Anfrage durch
seine Antwort (mit Adresse) und diese Antwort wird durch den
Rest der Kette an den Master zurückgereicht. Der Master wertet
die Antwort aus, nächste Anfrage. usw. Damit kommt man mit
definierten (kurzen) Stringlängen aus.
Nur die "Kette" hat einen Nachteil:
Wenn ein Mitglied ausfällt, warum auch immer, geht nix mehr.

Besser RS485, alle parallel schalten.
Derjenige, der dran ist belegt den Bus.
Rest wie gehabt: Master sendet Kommando, Slave antwortet.
Einfach, wirkungsvoll.

Ich habe beides schon erfolgreich eingesetzt,
mir sagt Lösung 2 eindeutig besser zu.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas in der Art habe ich auch vor, nur will ich die Module per I²C 
parallel schalten, was den Nachteil hat, dass man darüber nicht 
adressierbaar machen kann. Deshalb mache ich eine oder evtl 2 Leitungen 
Seriell durch. Der Master sendet einen Impuls und der erste setzt seine 
Adresse auf 1, der nächste auf 2 usw. Somit kann man beliebig viele (bis 
254) Module in beliebiger Reihenfolge (will mehrere verschiedene machen) 
zusammenschalten. Ist der letzt erreicht, sendet er die anzahl an den 
Master und der geht dann die Adressen durch um zu speeichern, welches 
Modul unter welccher Adresse zu erreichen ist.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier eine Anwendung, welche die Adresse in jedem Chip 
decrementiert. Ist die Adresse 0, ist der Chip gemeint.
So benötige ich keine unterschiedliche Konfiguration in den Chips.


Gruß

Jobst

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe genau einen solchen Aufbau für eine Anwendung mit LED-Strips 
verwendet. Alledings habe ich dafür ATmega8 verwendet.

Die Kommunikation läuft dabei allerdings nur vom Master aus ab. Jeder µC 
decrementiert die ID um 1, bei 0 ist dann das Ziel erreicht, wie weiter 
oben beschrieben.
Weiterhin habe ich die µC mit einem Bootloader versehen, der ist etwas 
modifiziert, so das er einfach das Signal weiterreicht wenn er selber 
nicht gemeint ist. Funktionieren tut das auf jeden Fall ganz gut.

viele Grüße

Aike

Autor: Ingolf Geißler (harpax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo in die Runde.


Das aktive Durchreichen von Daten an den nächsten µC fände ich unschön.
- fällt ein µC in der Kette aus, sind alle dahinter liegenden tot
- je weiter vorn der µC ist, desto mehr muß er Arbeiten
   o unnötiger Stromverbrauch
   o eventuell "Stille-Post"-Probleme
- je weiter hinten das Ziel, desto größer die Antwortzeit

Schöner würde ich eine Parallel-Schaltung aller Module finden.
- jedes Modul hat eine eindeutige ID
- nur wenn ID passt, gibt es eine Antwort
- dadurch garantierte Antwortzeiten
- passt ID nicht, kann µC in Stand-by gehen, aufwecken mit Rx-Interrupt
- Rundruf (z.B. an ID0) möglich - ID1 nach 1ms, ID2 nach 2ms usw.
- Ausfall eines Empfängers stört nicht den Rest
- mit etwas Hühnerfutter auch "1-wire" möglich
   o Leitung mit Pull-up
   o alle Rx parallel dran
   o pro Tx eine Diode -> Pegel kann nur "runtergezogen" werden
   -> Als Ergebnis sind nur 3 Leitungen nötig
   -> µC könnte auch Richtigkeit SEINER gesendeten Daten selbst prüfen
      er empfängt ja seine eigenen Daten

Nachteil der Parallelisierung:
- pro Modul an Tx eine Diode (oder Schutzwiderstand)
- pro Modul muß eine eindeutige ID hinterlegt sein

Diese 2 Nachteile würden aber (in meinen Augen) durch Stromersparnis, 
Ausfallsicherheit und Geschwindigkeit der Datenübertragung mehr als 
kompensiert.


Gruß...Harpax

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingolf Geißler schrieb:
> pro Modul muß eine eindeutige ID hinterlegt sein

Das war bei mir der Nachteil, dass ich mich entschieden habe "beides" 
(grundsätzlich parallel, seriell zum identifizieren) zu benutzen. Aber 
auch nur, weil ich 1. keine Lust habe, die Adressen jedes mal manuell zu 
programmieren, 2. Ich verschiedene Arten an Modulen habe und 3. Ich 
wissen will, welches Modul an welcher Stelle kommt. Wenn ich 15 Module 
nebeneinander habe und will ein Modul an 2. Stelle einfügen, müsste ich 
14 Module neu Programmieren, nur weil die Adresse um 1 hochgeht. So 
initialisiere ich einfach und alles ist gut.

Man könnte auch die Weiterleitung extra (µC-Unabhängig) machen, mit 
einem Glied, dass x Millisekunden wartet. In den Millisekunden kann der 
µC seine Adresse einstellen und diese dem Master senden. Die anderen 
Module, die noch nicht dran waren hören mit und merken sich, wieviele 
Module sich schon gemeldet haben. Wenn die Flanke an der seriellen 
Verbindung ist, weiß das Modul an welcher Stelle es ist und sendet es. 
Sollte der µC ausfallen, kann er nicht senden, die anderen Module zählen 
nicht hoch und das serielle Signal wird druch die externe Wartezeit 
trotzdem durchgelassen. Und bei einem Kabeldefekt kann man halt nichts 
machen, ob parallel oder seriell.


Allerdings, wenn du diese Flexibilität nicht brauchst und nur einmal 
eine feste Kombination hast, würde ich die µCs auch mit der passenden 
Adresse programmieren und dann ist gut.


Ingolf Geißler schrieb:
> Stromersparnis

Da weiß ich jetzt nicht, was da groß an Stromersparnis ist. Was meinst 
du damit?


Ingolf Geißler schrieb:
> Geschwindigkeit der Datenübertragung

Das serielle wäre ja nur zum Initialisieren. Die Datenübertragung selbst 
(Befehle, Antworten etc.) sind ja trotzdem parallel.

Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe vor einiger Zeit mal sowas gemacht. Die Kommunikation lief über 
IIC. Es konnten bis zu 250 SLAVES an den Bus gekoppelt werden. 
Zusätzlich zu den IIC-Leitungen habe ich noch eine sog. CTRL-IN und 
CTRL-OUT Leitung spendiert.
Vom MASTER geht der CTRL-OUT an die CTRL-IN von irgendeinen SLAVE 
(zumeist der erste in der "Kette"). Wenn der MASTER die CTRL-OUT Leitung 
setzt (ACTIVE L), dann reagiert der erste SLAVE auf das nachfolgende 
IIC-Telegramm. Dieses Telegramm ist ein Adressierungs-Telegramm und 
weist dem SLAVE die Adresse zu. Nach erfolgreichem Quittieren, setzt 
dieser SLAVE dann seinerseits seine CTRL-OUT Leitung und diese geht dann 
an die CTRL-IN vom nächsten SLAVE. Der MASTER sendet ein weiteres 
Addressierungstelegramm usw. Nachdem somit alles SLAVES adressiert sind, 
kann die eigentliche Kommunikation starten (Normalbetrieb). Der MASTER 
weiss jetzt genau, wie viele SLAVES vorhanden sind - und wenn ein SLAVE 
eingefügt oder entnommen wird, kann dieser auch wieder adressiert 
werden. Der MASTER erkennt zudem, ob überhaupt noch alle SLAVES 
vorhanden sind, indem er ein Pseudo-Telegramm sendet, auf welches nur 
der letzte SLAVE in der Kette antwortet, denn wenn ein SLAVE aus der 
Kette resettet, ist seine CTRL-OUT Leitung inaktiv. Dies erkennen alle 
nachfolgenden SLAVES und reagieren nicht mehr auf Telegramme. Zusätzlich 
sind noch weitere Maßnahmen integriert, die dem MASTER Informationen 
über den Zustand aller SLAVES anzeigen - aber das geht jetzt zu weit und 
ist wahrscheinlich auch nicht gefragt.

Gruß
TK

Autor: Jörg F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum kannst du nicht 3 oder 4 Portpins (je nach erforderlicher 
Adresszahl) opfern, die du dann zur binären Einstellung der ID von 
extern (mittels Lötbrücke) verwendest. Dann brauchst du nicht die 
Controller unterschiedlich zu programmieren.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mir für sowas auch schon mal gedanken gemacht, für ein Projekt, 
was noch auf meiner TODO-Liste steht.

Jörg F. schrieb:
> Warum kannst du nicht 3 oder 4 Portpins (je nach erforderlicher
> Adresszahl) opfern, die du dann zur binären Einstellung der ID von
> extern (mittels Lötbrücke) verwendest. Dann brauchst du nicht die
> Controller unterschiedlich zu programmieren.

dazu bräuchte man gar nicht so viele Port Pins, eigentlich nur zwei.
einen eingang und einen Ausgang. die jeweils mit dem nächsten verbunden 
werden.
die Initialisierung sieht so aus:

der hinterste µC in der Kette wird dauerhaft per Jumper gesetzt.
der Master fragt nun per Uart "init 0"
alle µCs, die noch nicht initilaisiert wurden schauen, ob ihr eingang 
aktiv ist.
der µC mit gejumperten Eingang merkt sich die 0 als ID und setzt den 
Ausgang zum nächsten in der Kette und schickt Antwort "init 0 done"
alle µCs, die noch nicht initilaisiert wurden schauen, ob ihr eingang 
aktiv ist.
der mit aktiven Eingang setzt den Eingang des Nächsten und schickt "init 
1 done"
usw

wird der Eingang des Masters gesetzt schickt der wieviele insgesamt 
intialisert wurden

Es kann auf allen µCs das selbe Programm laufen und jeder sich abhängig 
von seiner Position anders verhalten.

eigentlich bräuchte man hierfür noch nicht mal einen Master.

Autor: Ingolf Geißler (harpax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,


@ich (Gas)
Mit Stromersparnis meinte ich folgendes:

(Parallelschaltung)
Im Grundzustand (also niemand sendet) sind alle Sensor-Module (Slaves) 
im Stand-by.Erst wenn der Master eine Zieladresse sendet, werden alle 
Slaves durch Rx-Interrupt kurz aufgeweckt. Alle nicht angesprochenen 
Slaves legen sich wieder hin. Nur der angesprochene Slave antwortet und 
legt sich danach zu sein Kumpanen.


(Serien-Schaltung)
Master sendet Adresse des Ziel-Slaves an den 1. Slave. Dieser wacht auf. 
Er fühlt sich nicht angesprochen, also muß er seinerseits selbst zum 
Master für den 2. Slave werden. Er setzt das Telegramm ab und legt sich 
dann hin. Irgendwann ist das Telegramm bis zum Ziel-Slave durchgereicht 
und er antwortet. Nun geht die ganze Sache wieder zurück.
(Hab ich das System so richtig verstanden?)

Also System "Stille-Post".
- die Antwort von Slave-x dauert x-mal länger als bei Slave-1
- beim Stromverbrauch ist er 2*x-1 höher bevor die Daten zum Master 
kommen

Finde ich ungeschickt.

Diese Überlegungen beziehen sich auf parallele bzw. serielle Anordnung 
der Sensor-Module. Bei den hier vorgeschlagenen diversen Mischsystemen 
greift das dann nur noch bediengt. :-) Aber dann sind auch meist mehr 
Leitungen nötig.

Die Adresse könnte im EEPROM stehen, somit haben alle Slaves das gleiche 
Programm. Firmwareupdate durch modifizierten Bootloader möglich.

@Vlad Tepesch
Meinst Du eine Daten-Ring-Leitung?

Master     S-1      S-2      S-3
   Tx---->Rx Tx--->Rx Tx--->Rx Tx-->I
   Rx<------------------------------I

Wenn hier ein Slave bzw. ein Verbindung ausfällt, dann ist alles aus.



Gruß...Harpax

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingolf Geißler schrieb:
> @Vlad Tepesch
> Meinst Du eine Daten-Ring-Leitung?
>
> Master     S-1      S-2      S-3
>    Tx---->Rx Tx--->Rx Tx--->Rx Tx-->I
>    Rx<------------------------------I
>
> Wenn hier ein Slave bzw. ein Verbindung ausfällt, dann ist alles aus.

nein.
wie die Serielle Kommunikation gelöst wird ist unabhängig.
Ich würde die 1-wire Variante bevorzugen.
  VCC
   ^
   |
  [¯]
  [R]       
  [_]
   |            
   |       _________      
   +-->|--| TX   IO |    3
   +------| RX   II |   
   |       ¯¯¯¯¯¯|¯¯
   |             |
   |       ______|__      
   +-->|--| TX   IO |    2
   +------| RX   II |   
   |       ¯¯¯¯¯¯|¯¯
   |             |
   |       ______|__      
   +-->|--| TX   IO |    1
   +------| RX   II |   
   |       ¯¯¯¯¯¯|¯¯
   |             |
   |       ______|__      
   +-->|--| TX   IO |    0
   +------| RX   II |   
   |       ¯¯¯¯¯¯|¯¯
   |             |
                 |
                _|_
                

II init in
IO init out   
Ich würd für die Selbstkonfiguration zusätzliche Pins spendieren, sofern 
die nicht Mangelware sind.

Zumindest die Selbstkonfiguration kann ohne Master passieren, so dass 
auch der Master ermittelt werden kann.
Master wird nämlich der, dessen init-Eingang zu begin als low definiert 
ist (aller anderen haben die Pullups aktiviert).

der am ende der Kette setzt nun den initout auf Ausgang und low und sagt 
nun "init 1" oder so und alle die noch keine ID haben, schauen, ob ihr 
eingang low ist.

Die II-IO-Kette kann man später ja noch für andere Sachen benutzen.
zb Sendetoken, oder so.

Wenn man bei der II-IO-Kette am Ende statt Masseverbindung einen 
Pulldown setzt (eingänge alle ohne pullup und IOs von Anfang an auf High 
und Ausgang) kann man hier auch einen Ring machen.

Allerdings würde ich bei dem System komplett auf Ring verzichten, da man 
da ja Kabel von beginn der Kette zum Ende ziehen müsste.
Aber man will ja eigentlich nur einstecken.

Man könnte natürlich auch einfach eine Leitung parallel durch alle 
Boards durchschleifen (ohne Verbindung zu den Controllern) und nur am 
Anfang/Ende die Leitung mit den entsprechenden Pins verbinden

      ____    ____    ____    ____     
  /--|____|--|____|--|____|--|____|--\
  \----------------------------------/


Edit:
das problem mit dem Ausfall besteht natürlich trotzdem.
Aber das besteht auch bei einem Bussystem.

Wenn zB im 1-Wire Bus ein µC rumspinnt und mit seinen TX den Bus 
dauerhaft auf Low zieht oder gar RX auf Asugang stellt, ist der Bus auch 
tot

Autor: Michael Skropski (rbs_phoenix)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ingolf Geißler: Ich glaub, du hast nicht ganz verstanden wie ich das 
meine. (Ich bin "ich (Gast)" )

Die einmalige Initialisierung sieht so aus:
Der Master sendet ein High aus. Dieser geht in den ersten µC / in das 
erste Modul. Dann sendet der µC die Adresse "1" und seine Modul-ID (z.B. 
0x55 für Temperatursensor und 0x66 für Drucksensor). Jetzt sind 2 Sachen 
passiert. Der Master weiß, dass es ein Modul vom Typ x an der Adresse 1 
existiert und die restlichen Slaves erkennen, dass an den Master die 
Daten geschickt wurden und zählen einen Zähler hoch. Der erste µC 
schaltet auf Normalbetrieb um. Durch die 1ms Verzögerung hat das Modul 
Zeit, seine Daten zu senden. Das könnte man natürlich auch mit einem 
Ausgang vom µC machen, nur darf dieser dann nicht ausfallen. Mit der 1ms 
Verzögerung wird der µC umgangen und ein Defekt wird ignoriert. Nach 
dieser Millisekunde bekommt der 2te µC / das 2te Modul das Highsignal. 
Da passiert das gleiche. Durch seinen Zähler weiß er, dass er an 2ter 
Position ist. Also sendet er an den Master seine Adresse ("2") und seine 
Modul-ID. Das erste Modul bleibt unbeeindruckt, weil er die Adresse 1 
hat, der Master aber 0. Die restlichen Module erkennen aber diese Null 
und zählen wieder eins hoch.
Und so geht das weiter und weiter. Sollte ein µC ausfallen, wird das 
High-Signal trotzdem nach einer Millisekunde weitergegeben und da in dem 
Fall die restlichen Slaves nicht hochgezählt haben, da das Modul ja 
nichts gesendet hat, bekommt das nächste heile Modul die nächste 
Adresse. Ob ein Modul aktiv ist, kann man ja einfach mit einer grünen 
LED an einem Ausgang vom µC sichtbar machen. So sieht man dann auch, ob 
ein Modul geht oder nicht.

Der Master wartet grob 260-270ms auf Antworten (8bit Adressen => max. 
254 Module) und danach weiß er, welche Module wo sind und wieviele es 
insgesammt sind. Dann kann er in den Normalbetrieb schalten.
Alternativ dazu kann man auch eine Platinenseitige Rückführung machen. 
(siehe alternative.PNG) Wenn der µC kein Signal am Eingang hat, ist kein 
Modul mehr hinter ihm und somit kann der gleich hinter seinen Daten ein 
"STOP" an den Master senden. Somit spart man die Zeit, die der Master 
noch warten würde. Gerade, wenn man 16bit Adressen hat und (65535 
Adressen = ) 65,5 Sekunden warten müsste.


Nach der Initialisierung kommt alles so, wie du es mit paralleler 
Ansteuerung haben willst, nur dass der Master eine Liste hat, welche 
Module/Slaves es mit welcher Adresse gibt. Somit ist die eigentliche 
Kommunikation parallel, nur die Initialisierung "seriell". Richtig 
seriell ist es auch nicht. Es wird halt ein Highsignal von Modul zu 
Modul gereicht. Dieser sendet seine Antwort aber auch parallel zum 
Master.

Wären insgesammt 5 Adern. 5V, GND, CLK, DATA und INIT. Ggf. eine sechste 
Leitung für die Rückführung vom nächsten Modul. Bei 8bit Adressen glaube 
ich aber, ich würde mich für die Wartezeit entscheiden, denn man spart 
sich eine Ader und 260ms warten, bevor alles Startklar ist, sollte 
ansich möglich sein.

Hier (allgemein bei Datenbusse mit Adressen) kann man auch schöne Sachen 
machen wie Broadcast-Adresse(n). Adresse 255 sind alle Module (z.b. Für 
Sensor abschalten) oder 254 für alle Drucksensoren und 253 für alle 
Temperatursensoren. Und so weiter...

Autor: Ingolf Geißler (harpax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder Guten Abend!


@Vlad

Ahhh jetzt... also eine Mischung aus p und s.



@Michael

Ahhh jetzt... also eine Mischung aus p und s. :-)


Hmmm... würde die Konfiguration erheblich vereinfachen...hat was!
Habt Recht wenn die Anzahl der Sensor-Module eine gewisse Anzahl 
überschreitet oder wenn die Module an schwer- oder un-zugänglichen 
Punkten montiert sind wird es bei rein paralleler Lösung etwas schwierig 
mit der Administration.

Ich glaube ich muß mich mal an dieser Stelle outen.

(Nein...bin hetero!)

Selber habe ich ein solches System (noch) nicht am Laufen - sind alles 
nur Überlegungen. Ist halt wie bei Vlad...die To-Do-List...Wobei bei 
meinem "irgendwann-wenn-Zeit-ist"-Projekt eine Funk-Lösung mit RFM12 
angepeilt ist. Daher auch die Rx-Interrupt ,Stand-by und reine 
"2-Draht"-Gedanken, weil Funk ja nur Rx/Tx hat und da kleine Solarzellen 
zum Einsatz kommen sollen. Ach ja - Freizeit bräuchte Mann und das am 
Stück und nicht geschnitten. :-) Und wenn die Freizeit dann urplötzlich 
vor der Tür steht, dann ... ja dann sind bestimmt wieder andere Themen 
wichtiger... Ist bestimmt nicht nur bei mir so.


@Michael Klennert

Was sind denn das für Module, die da einsetzen werden sollen, bzw. wie 
sieht es mit der Datenrate aus - von Dir hat man ja nix mehr gehöhrt. 
:-)
Vielleicht komm ich ja mit meinem Projekt einen kleinen Schritt voran.



Gruß...Harpax

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingolf Geißler schrieb:
> Daher auch die Rx-Interrupt ,Stand-by

Mit der UART kannst Du nicht Strom sparen. Ehe der Quarz aus die Hufe 
kommt, sind die ersten Bytes schon vorbei.


Peter

Autor: Michael Skropski (rbs_phoenix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingolf Geißler schrieb:
> Ist bestimmt nicht nur bei mir so.

Ha, so ist es bei mir auch. Aber allmählich wirds was. Mein Problem ist, 
dass meine To-Do-Liste ca 30 Einträge hat^^ Aber Manches davon ist echt 
eher Pille-Palle bzw steht ganz weit unten. Z.b. Ein Signalgenerator 
Sinus, Rechteck, Dreieck, Sägezahn. Das ist ein IC von AnalogDevice und 
n PIC fürs Display und Bedienung.

Das was ich beschrieben habe ist quasi mein überlegtes Protokol für eine 
Art SPS. Da will ich eine unbestimmte Anzahl an unbestimmten 
"Einschüben" anstecken können, die Adressiert werden müssen. Ansich sind 
die Planungen schon fertig. Nur entweder muss ich das Steuerprogramm vom 
Master direkt in C schreiben und fest in den PIC programmieren (evtl 
auch von SD-Karte gelesen werden) aber da muss ich mir noch was 
überlegen in Richtung "Eigene Sprache" oder ein Programm in C, dass aber 
mit einer größeren Lib arbeitet. Dass ich sagen kann "messwert = 
get_adc(0,1);" wobei 0 das erste verfügbare ADC-Modul ist und davon der 
2. Eingang. Da der Master ja eine Liste hat, weiß er welche Adresse das 
erste ADC-Modul hat.
Wenn ich das Programm auf eine SD-Karte mache, dann nicht so derbe 
überteuert wie von Siemens^^ Die wollen für ne 512KB!!! Karte ungefähr 
70€ haben... Die haben doch n ** am kreisen. Zur Manuellen Bedienung und 
Statusüberwachung etc. bekommt der Master noch ein Touch-Display.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.