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
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.
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! ^^
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
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-
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!
Nö, AVRs mit 4xUART sind mir nicht bekannt. Notfalls gibt es externe UARTs mit 2/4 Kanälen (TL16C554).
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
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.
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
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
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...
>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.
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.
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
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.