mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bräuchte euren Rat/Denkanstoss für µC-Bus


Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi alle zusammen,

ich brauche mal rat für ein projekt, an dem ich grad sitz und mir keine 
idee kommt, oder besser gesagt zu viele...

programmier jetz seit ca nem halben jahr unter winavr (c) mit dem stk500 
un verschieden atmegas (8,16,32,128). läuft auch alles gut soweit^^

nur hab ich jetzt ein erstes größeres projekt vor mir, und dafür fehlt 
mir noch einwenig der allgemeine überblick, was mit µCs machbar ist und 
wo die grenzen des ganzen stecken.

zum projekt:
hab nen lasersensor (wahlweise bis zu vier!)der mir über rs232 mit 1 kHz 
daten (jeweils 2 byte pro messwert) sendet, die dann verrechnet und auf 
nem lcd (eDIP240) angezeigt werden müssen. hatte erst vor alles auf 
einem zu machen (atmega128)aber der wird denke ich maßlos überfordert 
sein. ausserdem werden die schnittstellen zu knapp usw usw
hatte da jetz an ein bus gedacht (tendiere da zu spi) mit jeweils einem 
atmega pro sensor und einem master mit dem lcd...
wäre das ein richtiger ansatz oder völliger blödsinn, dass so zu lösen?
wenn ja welche alternativen gäb es für solche projekte?
mit stellt sich auch die frage, wie denn genau einlesen:
in ner schleife? per interrupt? per timer? per kA? ;-)

wer super wenn mir einer das mal näher bringt und mir sagt, auf was ich 
dabei so grob achten sollte!
danke schonma vielmals!

gruß keniff

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht wie groß der Rechenaufwand für die Berechnung deiner 
empfangenen Daten ist, aber für mich klingt das nicht so, als wäre ein 
einziger uC damit überfordert. Im Zweifelsfall würde ich dann eher einen 
größeren/schnelleren uC auswählen.
Der Vorteil dabei wäre: geringer Platzverbrauch, kein zusätzlicher Bus 
für eventuelle Kommunikation zwischen den uC nötig, ...

Das einzige, wofür ich mir eventuell einen zusätzlichen uC aussuchen 
würde, wäre vielleicht wirklich einer für das LCD. Zumindest, wenn du 
vor hast das LCD ohne serielle Schnittstelle anzusprechen. Parallel 
gehen zu viele Pins flöten.

Zum Thema Daten Einlesen:
Das Einlesen per Interrupt und anschließendes Auswerten in einer 
Schleife.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey,
danke erstmal für schreiben!

void get_adc_res(void)
{
  uint8_t MSB;
  uint8_t LSB;
        char puffer[10];

  MSB = USART_Receive1();
  LSB = USART_Receive1();

  unsigned int erg = (((unsigned int) (MSB & 0x1F)) << 7) + LSB;
  unsigned int erg2 = (erg - 40) * 10 / 4015;

  sprintf(puffer,"%x",erg2);

  //eDIP_mess("\x1B""Z""L""\x05""\x05""Messwert ", puffer);
}


also das wär die routine zum berechnen der 2 bytes zu einem integer 
wert. also du würdest sagen, dass ich die 4 sensoren über rs232 (denk ja 
dann mal software usart) auswerten und berechnen kann ohne 
rechenzeitprobleme zu bekommen? dann würd das mit dem bus komplett 
rausfallen und würd es um einiges leichter machen...
du meintest größeren/schnelleren µC? was käm da in frage? kannst mir da 
einen empfehlen? das problem dabei wär das ich wie gesagt bis jetzt nur 
winavr in verbindung mit den atmegas kenne? und da war der 128er der 
größte den ich bis jetzt genutzt hab...

Hans Wurst worte:
Zum Thema Daten Einlesen:
Das Einlesen per Interrupt und anschließendes Auswerten in einer
Schleife.

hmm, was ist wenns 4 sensoren werden sollten? 4 interrupts?
a) gibts das überhaupt? (sry, vllt is die frage sau dumm kA ^^)
b) was ist dann wenn er den einen aufnimmt?kanns nicht passieren das die 
andern messwerte der anderns sensoren flöten gehn?
das schreit nach ne puffer oder so etwas?

oder red ich grad kompletten müll?
lünsch mich wenns so is! ^^

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so...

hab den ersten sensor jetzt an nem atmega128...
und es läuft! ,-)
mir kam jetzt eine idee vllt ein multiplexer zu verwenden, um die 
weiteren 3 sensoren über diesen mit dem µC zu verbinden und nach der 
reihe sie einzeln ansprechen über eine gemeinsame rs232 leitung? ginge 
das? denke ja, aber is das elektrotechnisch sauber gelöst? gibs andre 
bauteile, die da mehr geeignet sind? bin für alles offen ,-)

gruß keniff

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Controller mit 4 UARTs. Wäre wohl der einfachste Ansatz. Muxer 
geht nur, wenn du die sendenden Kollegen explizit abfragen kannst. Wenn 
die wild durcheinander senden nützt die ein Muxer wenig-

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch aus der atmega baureihe? das wär nicht das schlechteste
genau das problem hab ich hier nämlich, dass der laser dauerhaft daten 
schickt. kann das schicken zwar stoppen aber der sensor reagiert darauf 
nicht direkt...
also scheidet multiplexer wohl aus

danke fürs schnelle weiterhelfen!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, AVRs mit 4xUART sind mir nicht bekannt. Notfalls gibt es externe 
UARTs mit 2/4 Kanälen (TL16C554).

Autor: Matthias Larisch (matze88)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 1200 Baud (oder was meinst du mit 1 kHz?) dürften auch 4 
Softwareuarts kein Problem sein. 1 Uart hat man ja in Hardware, bleiben 
also nur 3 übrig. Mit dem Ansatz von Peter Danneger (Software Uart, 
irgendwo in der Codesammlung zu finden) schafft man ungefähr 38400 baud 
mit 8 MHz (1 Soft-Uart), dabei wird allerdings ein Timer mit 
Inputcapture benutzt. Wenn man geschickt programmiert, sollte das doch 
auch mit Pin-Change Interrupts (in den "neuen" AVRs sind die ja für 
jeden Pin aktivierbar) funktionieren. Natürlich bei 3x Soft-Uart dann 
eher mit 9600 bps @ 12 MHz oder so. Durchforste mal die Codesammlung ein 
wenig, da findet sich sicher einiges.

Matthias

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich ging davon aus, dass die Daten mit einer Framerate von 1KHz 
ankommen, macht also bei 2 Bytes pro Frame mindestens 38400bd. 2-3fach 
SoftUART empfangend ist dann mit AVRs wohl etwas krass.

Wobei eine Gesamtdatenrate von 4*2*1KHz=8KB/s plus Weiterverabrbeitung 
mit Division auch schon interessant werden kann.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Kannst du das Senden unterbrechen/anfordern oder kommen die Daten so 
nach
Lust und Laune? Bei steuerbarkeit wäre muxen für dich die einfachste 
Variante. Wenn wirklich sporadisch, müsste man genau rechnen.
In C natürlich beschissen. Simulation wäre da dann wohl das beste.

Viel Erfolg, Uwe

Autor: Dr.Seltsam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch für einen Multiplexer
Voraussetzungen:
 - Die Frames haben definierten Anfang und Ende.
 - Es müssen nicht alle Frames verarbeitet werden.
Dann würde ich doch mit einer gemultiplexten Schnittstelle arbeiten und 
die Umschaltung immer nach einem vollständig übertragenen Frame machen. 
Würde in der Summe deutlich langsamer gehen, als bei paralleler 
Verarbeitung, aber der Controller hätte auf jeden Fall genug Zeit für 
alles andere.

Wofür ist den die ganze Anordnung gedacht, wie zeitkritisch ist die 
Auswertung und Anzeige?


Gruß
Dr.Seltsam

Autor: Matthias Larisch (matze88)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine weitere Frage ist, ob wirklich alle Messdaten zur Anzeige benötigt 
werden. Sonst könnte man wirklich einfach EINE Uart nehmen und per 
Multiplexer einfach immer nach 1 empfangenen Übertragung auf den 
nächsten Sensor schalten. Dabei verliert man dann natürlich so einige 
Messwerte...

Autor: ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>A.K.
>Nö, AVRs mit 4xUART sind mir nicht bekannt. Notfalls gibt es externe
>UARTs mit 2/4 Kanälen (TL16C554).

Der Mega64 hat 4 Uarts.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so 'ne Anmerkung:
Zwar werden im 1 kHz-Takt Messdaten übertragen, aber es ist doch 
offensichtlich vollkommen unnötig, die auch mit dieser Geschwindigkeit 
auf ein Display auszugeben.
So schnell kann ein LC-Display gar nicht veränderte Werte darstellen und 
so schnell kann auch kein Mensch veränderte Werte wahrnehmen.

Eine Aktualisierungsrate von 10..20 Hz ist vollkommen ausreichend.

Und damit dürften sich die Anforderungen an das System drastisch 
vereinfachen; die im 1 kHz-Takt einlaufenden Messwerte werden gemittelt 
und mit erheblich niedrigerer Rate auf das Display ausgegeben.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey, cool wieviel leute helfen wollen! danke!

wie gesagt, kann das senden der daten durch ein befehl (umschalten auf 
den analog ausgang) stoppen, aber der sensor reagiert nicht sofort auf 
den befehl, kann also nicht sagen ich sende den befehl das es los geht, 
er schickt mir ein frame und danach wird er wieder gestoppt...

der sensor nimmt messwerte mit 1kHz auf und schickt sie mir bei ner 
baudrate von 38400 über rs232.

> Dr Seltsam
> - Die Frames haben definierten Anfang und Ende.
> - Es müssen nicht alle Frames verarbeitet werden.

also das frame besteht aus nem MSB und nem LSB. das zweite bit des MSB 
ist eins, sowie das zweite bit beim LSB null ist.
also ob alle messwerte aufgenommen werden müssen denke ich nicht, da ich 
auf dem display den messwerte nur vllt 1-2 pro sec aktualisieren wollte.
aber erfasst sollten sie nach möglichkeit schon werden

hmm, muss immer noch an so nen spi-bus denken. wäre das nicht einfacher, 
da software uart und alle standard µCs wegfallen. ein ATmega8 oder 16 
zum erfassen und nen 128er als master und fürs display...

@  Rufus t. Firefly
du meinst also den sensor zwar schicken lassen, aber ihn eig nur mit 
10-20Hz auslesen? oder meinst du mit mittlung alle messwerte erfassen 
und nur den mittelwert dementsprechend anzeigen? wieso sollte dann die 
anforderung kleiner werden?es ist ja nicht das anzeigen das kritische, 
sondern eher das erfassen und verrechnen?!

und nomma vielen dank für die starke beteiligung!

gruß keniff

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.