Guten Morgen,
ich möchte wie in der Aufgabenstellung (Bild Aufgabenstellung) mit einem
Atmega88 und einem Poti an A0 einen Analogenmeßwert an LabVIEW senden.
Wie die Byte Reihenfolge sein soll steht im Bild Datenformat, ein Byte
senden wäre jetz für mich glaube ich machbar, das er zwei nacheinander
ausliest in dem ein Wert steht check ich nicht. Das das im
zweierkomplement ist schon.
das poti habe ich jetzt von 0-5V versorgt an A0
als echo Programm habe ich vorerst jetzt folgendes.: da wird noch kein
analogwert ausgelesen
1
/*
2
* uart_demo_01.c
3
* Initialisierung der UART, 9600, 8N1; unter Verwendung von Marcos
4
* Funktionen zum Senden und Empfangen eines Bytes im Polling
5
* Ein empfangenes Zeichen wieder senden und am PortB ausgeben * Pinbelegung der UART-Schnittstelle: Tx = PD1, Rx = PD0
6
* Controller: ATmega88 @ 8MHz
7
*/
8
#include<avr/io.h>
9
10
#define FOSC 8000000 // Set clock Speed in Hz
11
#define BAUD 9600 // Set baud rate
12
#define UBRR_Value FOSC/16/BAUD-1 // Set baud rate value in baud rate register
13
14
voidUSART_Init(uint16_tubrr)
15
{
16
UBRR0H=(uint8_t)(ubrr>>8);// Set baud rate in high- and low-register
17
UBRR0L=(uint8_t)ubrr;// Set low-register always after high-register
18
UCSR0C=(1<<UCSZ01)|(1<<UCSZ00);// Set frame format: 8data, 1stop bit
19
UCSR0B=(1<<RXEN0)|(1<<TXEN0);// Enable receiver and transmitter
20
}
21
22
voidUSART_Transmit(uint8_tdata)
23
{
24
while(!(UCSR0A&(1<<UDRE0)));// Wait for empty transmit buffer
25
UDR0=data;// Put data into buffer, sends the data
26
}
27
28
uint8_tUSART_Receive(void)
29
{
30
while(!(UCSR0A&(1<<RXC0)));// Wait for data to be received
31
returnUDR0;// Get and return received data from buffer
USART_Transmit(data=USART_Receive());// receive on byte, send it
52
PORTB=data;// and write to Port B
53
}
54
}
das habe ich jetzt zum test aus meinem Buch und möchte das erst einmal
so verwenden, natürlich dann die while schleife anders, nur den meßwert
senden.
mein problem ist jetzt wie lese ich den Analogwert so ein,zb welchen
Datentyp int_16
Das ich dann den Wert im Zeierkomplement mit meinem programm oben senden
kann, weil wie gefordert sende ich ja dann schon einmal ein byte nach
dem anderen raus
Mfg Huber
Michael H. schrieb:> das er zwei nacheinander> ausliest in dem ein Wert steht check ich nicht.
Das geht auch nicht, wenn es zuverlässig sein soll.
Das Labview hat keinen Hellseher eingebaut. Es kann daher ohne ein
Protokoll nicht wissen, welches das 1. und welches das 2. Byte sein
soll.
Da der AVR eh nur 10Bit ADC wandeln kann, könnte man als einfaches
Protokoll von den ungenutzten 6 Bit 2 Bits für die Kennzeichnung
verwenden, z.B.:
1xxx.xxxx = high Byte
0xxx.xxxx = low Byte
Michael H. schrieb:> als echo Programm habe ich vorerst jetzt folgendes.: da wird noch kein> analogwert ausgelesen
Ja, dann mach das doch einfach...
1. ADC initialisieren
2. AD-Wandlung starten
3. warten bis Wandlung beendet
4. AD-Wert abholen
5. weiter bei 2.
AVR-Tutorial: ADCAVR-GCC-Tutorial/Analoge Ein- und Ausgabe> das poti habe ich jetzt von 0-5V versorgt an A0
Beim AVR gibt es keinen Pin A0. Meinst du ADC0 am PA0?
Lothar M. schrieb:>> das poti habe ich jetzt von 0-5V versorgt an A0> Beim AVR gibt es keinen Pin A0. Meinst du ADC0 am PA0?
Ja Adc0,
gut dann werde ich das heute abend mal so schreiben das ich jede
zb.sekunde 1 Byte über die serielle Schnittstelle raussende.
Jetzt habe ich noch eine Frage zu dem Buchausschnitt, dann kann ich das
buch ja praktisch wegschmeisen, das bekomme ich ja nie hin mit meinem
atmega88.
könnte mir bitte jemand vielleicht ein ganz einfaches VI im
Blockdiagramm zeigen wie ich im puffer dann mein Byte angezeigt bekomme,
denn ich will sowas wie im bild mit einem poti hinbekommen, poti auf
Zeiger hoch, poti runter Zeiger runter
Du hast nicht geschrieben was im zweiten Byte stehen soll. Wenn dass nur
weitere Bits des Wertes sein sollen, dann hat der Aufgabensteller einen
klassischen Fehler gemacht. Um nicht zu sagen, typischer Pfusch. Es wird
erwartet, dass nach dem Einschalten der Sender und Empfänger synchron
arbeiten und das dauerhaft so bleibt.
Auch wenn es nur ein sehr kleines "Netzwerk" ist, dass fällt unter
Trugschluss #1 der klassischen Kommunikations-Trugschlüsse
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
>das er zwei nacheinander ausliest in dem ein Wert steht check ich nicht.
das ist im Prinzip wie bei Menschen am Telefon: du benötigst zuerst eine
Pause, dann kommen einzelne wörter, pause [Satzende], anderere
Wörter/Werte
Das einfache Protokoll aus dem Text:
"die Labview er warten zwei hintereinander ausgesendetete Bytes"
Auch wenn Labview keinen Hellseher eigbaut hat, der eigentlich eher für
eine BILDverarbeitung benötigt würde aber von Filmexperten o.ä.
irgendwie für ein Protokoll benötigt wird (ungefähr) kann Labview die
Zeit messen. Also:
Pause,Byte 1, Byte 2, Pause,....
wobei Pause zur Unterscheidung (zeitlich) länger als ein byte sein muss.
Grob bei 9600 8N1 8-bit+1-start+1-stop=10-bit ca. 100bytes/sek also die
Pause ungefähr 1/100 sek
da avr einen kleinen Ausgabespeicher haben, kannst du (nach syntax
korrektur!)
1
2
uint_16data
3
UDR0=high(data)//fängt an 1.Byte zu zu senden
4
UDR0=low(data)//2.Byte im Fifo
5
sleep(30ms)// warten: 2 Bytes + 1 Pause
6
data=neuer_wert
7
UDR0=high(data)
8
UDR0=low(data)
9
....
programmieren und 2 bytes werden hintereinander gesendet (da
keinerlei Pause) und danach genügend Zeit zur Erkennung eines Wartens
gelassen.
Die jüngere Internetgeneration wird sich nicht vorstellen können
zuverlässig eine (Warte) Zeit zu messen, aber ansonsten ist das
Protokoll sehr einfach.
Michael H. schrieb:> ich möchte wie in der Aufgabenstellung (Bild Aufgabenstellung) mit einem> Atmega88 und einem Poti an A0 einen Analogenmeßwert an LabVIEW senden.
Über den UART kannst du keine Analogwerte senden.
Du wirst vorher irgendeine Digitalisierung durchführen und dann die
digitalen Daten über die Schnittstelle übertragen müssen.
Dirk schrieb:> Das einfache Protokoll aus dem Text:> "die Labview er warten zwei hintereinander ausgesendetete Bytes"
So ein "Protokoll" würde Dir jeder Informatiker um die Ohren klatschen.
Das hat man vielleicht in der Steinzeit der Datenverarbeitung mal so
gemacht, als es noch keine Mikrocontroller gab.
Dazu fehlt mindestens noch die Angabe des Timeouts, d.h. bis zu welcher
Zeit gehört ein Byte noch zum selben Paket und ab wann zum nächsten.
Solche zeitgesteuerten Protokolle macht man aber heute nicht mehr (zu
unzuverlässig und fehlerträchtig), sondern nur noch datengesteuerte
(Starttoken, Länge, Adreßfeld, Datenfeld, CRC, Endetoken). Und typisch
gehört auch eine Fehlerprüfung zu einem Protokoll, z.B. CRC.
Michael H. schrieb:> ich möchte wie in der Aufgabenstellung (Bild Aufgabenstellung) mit einem> Atmega88 und einem Poti an A0 einen Analogenmeßwert an LabVIEW senden.
Ich nehme mal an, daß du diese Aufgabenstellung von irgend jemandem
aufgebrummt bekommen hast und sie dir nicht selber ausgedacht hast.
Dem Verfasser dieser Aufgabenstellung sollte man die Ohren lang ziehen -
bis er so aussieht wie das, was er ist: (Emil: Grautier mit 4
Buchstaben).
Mal abgesehen von dem "Zweierkomplement,..der Wert muß erst noch
umgeformt werden.." hat dieser Unglücksrabe offensichtlich keinen
Verstand walten lassen - Peter hat das ja schon deutlich genug zum
Ausdruck gebracht.
Also mein Vorschlag: forme deinen Zahlenwert in einen Text um und sende
diesen zeilenweise. Beispiel:
{'+', '8', '7', '.', '3', 0x0D, 0x0A}
W.S.
Vermutlich ist das Labview-Tool eine Blackbox, die um 1980 rum mal
jemand programmiert hat.
Mal suchen, ob irgendwo das Timeout steht und dann zwischen den
Messungen >Timeout Delay einfügen.
Und dann den 16Bit-Wert des ADC in 2 Bytes zerlegen und senden. Man darf
sie ohne Warten senden, da der AVR einen Sendepuffer hat.
Vermutlich soll der ADC-Wert (0..1023) noch irgendwie skaliert werden,
also ax+b rechnen. Kann man in float machen und dann zum Senden wieder
int zuweisen.
Peter D. schrieb:> Und dann den 16Bit-Wert des ADC in 2 Bytes zerlegen und senden.
soll er aber laut Aufgabenstellung nicht:
Byte 1: Vorzeichenbehaftete Temperatur in 0,5°C Schritten:
0x00: 0°C
0x01: 0,5°C
0x7F: 63,5 °C
0x80: -64°C
0xFF: -1°C
Byte2 ???
Hinweis: Du hast die Temperatur bereits im zweiekomplement, falls dein
Typ für den temperaturwert signed char ist.
Also ich hatte so ähnliche Probleme auch schon und habe es so gelöst:
Sollen viele Daten gestreamt werden dann verwende ich ein Paketformat.
Sollen nur ab und zu wenige Daten gelesen werden, dann muss zuerst
angefragt werden. Also man schickt ein spezielles Byte hin und bekommt
als Antwort die ADC Werte.
Peter D. schrieb:> Dirk schrieb:>> Das einfache Protokoll aus dem Text:>> "die Labview er warten zwei hintereinander ausgesendete Bytes">> So ein "Protokoll" würde Dir jeder Informatiker um die Ohren klatschen.
das heißt du kannst nicht eigenständig antworten und musst als
Alternative von "jeder" berichten der Gewalt anwenden würde.
Peter D. schrieb:> Das hat man vielleicht in der Steinzeit der Datenverarbeitung mal so> gemacht, als es noch keine Mikrocontroller gab.
du kannst dich lediglich an die Steinzeit erinnern und bspw. DMX oder
WS2801, 2811, 3001, 1804, sind dir in der Neuzeit unverständlich
Peter D. schrieb:> Dazu fehlt mindestens noch die Angabe des Timeouts, d.h. bis zu welcher> Zeit gehört ein Byte noch zum selben Paket und ab wann zum nächsten.
wenn du ohne die Hilfe von jedem Informatiker nicht den Timeout
(Zeitdauer(Pause) > Zeitdauer(1 Byte) ) eigenständig berechnen kannst,
dann kannst du natürlich nicht den implizit(!) angegebenen Timeout
berechnen.
(und hast wohl auch keine Möglichkeit meinen Text zu lesen)
Die Existenz des längstmöglichen (Zeit in sek) Bytes ist Peter D.
sicherlich noch unbekannt, da Peter D. nur Pakete denken kann.
Peter D. schrieb:> Solche zeitgesteuerten Protokolle macht man aber heute nicht mehr (zu> unzuverlässig und fehlerträchtig), sondern nur noch datengesteuerte> (Starttoken, Länge, Adreßfeld, Datenfeld, CRC, Endetoken).
deine macht-man Vorstellung, die implizit annimmt, dass eine Zeitmessung
"unzuverlässig" sei, verbietet dir sicherlich eigenen Menschenverstand
zu benutzen und du musst *man*-Verstand berichten :
falls du dich am Telefon "zeitgesteuert" unterhältst und nicht die
zeit_definierten_ Pausen des anderen Telefongesprächs verstehst, da kein
Timeout angegeben wurde, dann könntest du dein "zeitgesteuert"
überdenken.
Übrigens: wenn du bunt "Starttoken, Länge, Adreßfeld, Datenfeld, CRC,
Endetoken" ausgeben musst und keinen Informatiker der kurz deine Ausgabe
anhalten kann, dann fehlt bei dir eine Pausefunktion.
kurz: ein eigenständiger Mensch hat mit etwas Hintergrundwissen über
asycnchrone serielle Datenübertragung (nicht extern zeitgesteuert)
kein Problem das Labview-Protokoll sicher zu implementieren.
Ein Mensch der die Steinzeit kennt wird wohl am neumodischen Morsecode
scheitern, da auch dort keine festen Timeouts angegeben wurden und
müsste Informatiker um Hilfe bitten damit die den Morsecode einem
Menschen um die Ohren schlagen.
Ja man kann das schon zeitgesteuert machen, ist aber halt doof.
1. Man erreicht nicht die maximal mögliche Datenrate.
2. Weil einem vielleicht irgendwo ein Betriebssystem rein spielt braucht
man deutlich längere Pausen als man es gerne hätte.
Ich hatte das auch mit Pausen probiert, aber jetzt mit Anfrage und dann
senden geht es viel problemloser.
Dirk schrieb:> wenn du ohne die Hilfe von jedem Informatiker nicht den Timeout> (Zeitdauer(Pause) > Zeitdauer(1 Byte) ) eigenständig berechnen kannst,> dann kannst du natürlich nicht den implizit(!) angegebenen Timeout> berechnen.
Das ist Bullshit.
Man nimmt doch nicht für jeden einzelnen Task einen MC, sondern ein MC
kann viele Tasks gleichzeitig bearbeiten. Daher ist nicht garantiert,
daß der Sender Bytes pausenlos senden kann, sondern es können auch
andere wichtigere Interrupts dazwischen kommen. Man muß also einen
sinnvollen Timeout definieren, der erheblich größer als eine Bytezeit
ist.
Und wenn Du mal solche Protokolle debuggen mußtest und aus dem Fluchen
nicht mehr rausgekommen bist, dann wüßtest Du auch, warum Profis sowas
meiden, wie der Teufel das Weihwasser. Statt einfach den Datenstrom in
eine Datei zu schreiben, um ihn zu analysieren, müßte man zu jedem
einzelnen Byte auch den Timestamp loggen.
Oft muß man auch bei größeren Entfernungen Protokolle über andere
Interfaces (Ethernet, USB, WLAN) tunneln, da gehen dann sämtliche
Zeitabhängigkeiten verloren.
Michael H. schrieb:> Wie die Byte Reihenfolge sein soll steht im Bild Datenformat, ein Byte> senden wäre jetz für mich glaube ich machbar, das er zwei nacheinander> ausliest in dem ein Wert steht check ich nicht.
Mit den vorhandenen Angaben ist die Aufgabe nicht lösbar. Es fehlt die
Definition zum zweiten, von LabView-VI erwarteten Byte und ggf. auch
noch eine Angabe zum Synchronisationsverfahren bei der Bytezählung.
Ohne vernünftige Spezifikation der VI-Schnittstelle ist das hier alles
blindes Rumgemache.
Peter D. schrieb:> Dirk schrieb:>> wenn du ohne die Hilfe von jedem Informatiker nicht den Timeout>> (Zeitdauer(Pause) > Zeitdauer(1 Byte) ) eigenständig berechnen kannst,>> dann kannst du natürlich nicht den implizit(!) angegebenen Timeout>> berechnen.>> Das ist Bullshit.> Man nimmt doch nicht für jeden einzelnen Task einen MC, sondern ein MC> kann viele Tasks gleichzeitig bearbeiten. Daher ist nicht garantiert,> daß der Sender Bytes pausenlos senden kann, sondern es können auch> andere wichtigere Interrupts dazwischen kommen. Man muß also einen> sinnvollen Timeout definieren, der erheblich größer als eine Bytezeit> ist.
wenn du nicht eigenständig antworten kannst und zwangsweise "*man*
nimmt"
und nur viele verstehst, dann versuch einfach zuerst(!) die Grundlagen
zu verstehen:
-"einem Atmega88": die Anzahl der µC beträgt [ _ ]?
- wie viele Temperaturen sollen gleichzeitig übertragen werden?
- wie viele PC/Empfänger sind an EINER Leitung?
- wie viele µC/Sender sind an EINER Leitung?
- warum kann dein µC keine 3,2 ms (oben grob um Faktor 10 verrechnet)
messen?
- warum muss der Sender pausenlos senden, wenn der PC eigenständig
warten kann?
- warum sollen "wichtige" Interrupts dazwischen kommen, die nicht
programmiert sind?
> Und wenn Du mal solche Protokolle debuggen mußtest und aus dem Fluchen> nicht mehr rausgekommen bist, dann wüßtest Du auch, warum Profis sowas> meiden, wie der Teufel das Weihwasser. Statt einfach den Datenstrom in> eine Datei zu schreiben, um ihn zu analysieren, müßte man zu jedem> einzelnen Byte auch den Timestamp loggen.
ich kann ein "solches" Protokoll (Pause,2 Bytes hintereinander)
problemlos debugen, dazu braucht ein konventioneller Informatiker die
Fähigkeit bis 3 zählen zu können und müsste nicht wie ein Junkie viel
Stoff dazugeben
Informatiker müssen weder Teufel noch Weihwasser bemühen, sondern können
eigenständig Informationen verarbeiten.
Wenn du versuchen würdest dein Ausgabeprotokoll im Einzel
schrittverfahren zu debugen, dann kannst du
Massenausgabe Peter Dannenberger:
>Peter: So ein "Protokoll" würde dir
dbg: einfache Spekulation ("würde") wäre gegen Datenschutz/stabile Daten
>Peter: jeder Informatiker
dbg: Peter kann nicht jeden Informatiker kennen
>Peter: um die Ohren klatschen.
dbg: traditionelle Informatiker verstehen Informationen und müssen nicht
gewaltsam um die Ohren klatschen
==>Zwischenrechnung: Peter hatte keine Chance EINEN Informatiker zu
fragen
>Peter:Das hat man vielleicht [... mal so gemacht,]
dbg: Peter beginnt eine Spekulationsausgabe (doppelte Unbestimmtheit:
man/vielleicht gibt Peter viel Sicherheit)
>Peter: Steinzeit der Datenverarbeitung
dbg: Peter hat die sichere Steinzeit in Erinnerung
>Peter: als es noch keine Mikrocontroller gab
dbg: Peter muss in der Zeit programmiert/belehrnt/befühlt o.ä. worden
sein
>Peter: Dazu fehlt mindestens noch die Angabe des Timeouts,
dbg: Peter kann 10 bit-Zeiten nicht berechnen
>Peter:d.h. bis zu welcher Zeit gehört ein Byte noch zum selben Paket
dbg:Schwierigkeit ab Pause:
1. Byte (1.Byte von Paket 1)
2. Byte (2.Byte von Paket 1)
Pause
3. Byte (1.Byte von Paket 2)
4. Byte (2.Byte von Paket 2)
zeitlich zu erfassen
>Peter: Solche zeitgesteuerten Protokolle
dbg:glaubt an Protokolle via Zeitschaltuhr und "solche"
>Peter: macht man aber heute nicht
dbg: man/ "aber" relativ zu "solchen" (undefinierten)
>Peter: zu unzuverlässig und fehlerträchtig
dbg:"solche" Protokolle sind aufgrund der solche Definition per se
unzuverlässig
>Peter: Starttoken
dbg: eine Pause kann nicht erkannt werden, aber Peter benötigt token
>Peter: Länge
dbg: 2 Bytes ist zu schwierig für Peter
>Peter: Adreßfeld
dbg: µC hat eine Leitung zum PC, aber Peter muss eine mögliche
Adressen im Feld adressieren
>Peter: Datenfeld
dbg: das 2 Byte 'Datenfeld' high_byte + low_byte ist für Peter zu groß
>CRC
dbg:die Leitung ist verrauscht
>Endetoken
dbg:die Pause wird nicht verstanden
>Und typisch gehört auch eine Fehlerprüfung zu einem Protokoll, z.B. CRC.
dbg: Peter erinnert sich nicht an die Aufzählung CRC und glaubt typisch
wäre eine Temperatur hochsicherheitsbedürftig
https://www-vs.informatik.uni-ulm.de/teach/ss02/sp/Kap7.pdf
kurz: wenn du es schaffst EINEN Punkt zu beantworten, dann musst du
nicht Masse ausgeben, sondern könntest einfach die Grenzen bzw.
Temperaturträgheiten mitberücksichtigen:
- ISR: bsp. max. 100HZ (100 Temperaturen/Sekunde)==>10ms (nach obiger
Fehlrechnung wären 10HZ extrem sicher)
- -65°C..+65°C sind für bspw. 100°C traditionelle Kalibrierung zu wenig
==> 2 Bytes
1
ISR:
2
UDR0=high(temperatur)
3
UDR0=low(temperatur)
4
ret
Ferig (bis auf C syntax).
- 333 Temperaturen/Sekunde wären ebenfalls vollkommen Protokoll-Konform
- mit der Fiktion: PC zuerst wartend (wird nicht beim laufenden µC
zugeschaltet) nach erster (zwangsweisen) Pause, da ohne Strom: 500HZ
==> eine Temperaturauflösung von 500tps reicht für viele solcher
Temperaturmessungen.
Die eigentlich beabsichtige Schwierigkeit dürfte sicherlich die
Temperaturerfassung/ Umwandlung gewesen sein.
Wenn ein intelligenter Fragesteller wie Michael Huber kurz über das
einfache Sendeverfahren stolpert und eigenständig fragen kann, dann
ist das kein Problem.
Wenn aber vollkommen flauschige Äkschperten keine 2 Bytes einfach
hintereinander senden können und nur "solche" Protokolle kennen, die
zudem zeitgesteuert (13:24:47 Paket 1,...) sein sollen, dann fehlt dir
eigener Menschenverstand der dich anhalten kann und dich von
schlagenden Informatikern berichten lässt, da du ohne Hilfe von
unbestimmten "man"/"jeder"/"solche"/.... nicht antworten kannst.
Versuch einmal ohne solche unbestimmte Hilfe zu antworten, dann
könntest du es auch bemerken.
Also, Danke mal für die ganzen Antworten.
Ich habe die Aufgabenstellung aus dem Buch verworfen, für meine
Bastelzwecke funktioniert jetzt anfangs der nachfolgende Code,
allerdings habe ich schon so lange nichts mehr gemacht, das ich nicht
mehr weiß wie man einen zweiten ADC-Kanal benutzt.
könnte mir jemand sagen wie ich den richtig konfigurieren kann.
so wie ich das momentan verstehe, wird jeder ADC-Kanal nacheinander
abgefragt.Und im ADCH Register abgelegt.
Um ADC 4 und 5 zu nutzen muss ich das im AMUX Register frei schalten
mir fällt nicht mehr ein wie ich diese jetzt einzeln auswerten und in
ein Variable speichern kann, so wie ich es nachfolgend geschrieben habe
funktioniert es natürlich nicht, wie muss ich das richtig machen ?
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
#define FOSC 16000000 // Set clock Speed in Hz
5
#define BAUD 9600 // Set baud rate
6
#define UBRR_Value FOSC/16/BAUD-1 // Set baud rate value in baud rate register
7
8
voidUSART_Init(uint16_tubrr)
9
{
10
UBRR0H=(uint8_t)(ubrr>>8);// Set baud rate in high- and low-register
11
UBRR0L=(uint8_t)ubrr;// Set low-register always after high-register
12
UCSR0C=(1<<UCSZ01)|(1<<UCSZ00);// Set frame format: 8data, 1stop bit
13
UCSR0B=(1<<RXEN0)|(1<<TXEN0);// Enable receiver and transmitter
14
}
15
16
voidUSART_Transmit(uint8_tdata)
17
{
18
while(!(UCSR0A&(1<<UDRE0)));// Wait for empty transmit buffer
19
UDR0=data;// Put data into buffer, sends the data
20
}
21
22
uint8_tUSART_Receive(void)
23
{
24
while(!(UCSR0A&(1<<RXC0)));// Wait for data to be received
25
returnUDR0;// Get and return received data from buffer
@Dirk (Gast)
Mein Chef würde mich fristlos entlassen, wenn ich so ein Protokoll
implementieren wollte. Spätestens beim Review würde es auffallen.
Es geht nicht darum, daß bei simpelsten Aufgaben sowas funktionieren
könnte. Da hätte man viel zu tun, wenn man je nach Aufgabe verschiedene
Protokolle definieren müßte. Protokolle müssen zumindest für die
geplanten Anwendungsfelder skalierbar sein.
Man hat leider auch mit externen Protokollen zu tun, wo man sich fragt,
was hat der denn geraucht. Das ist aber noch lange kein Grund, es
genauso schlecht zu machen.
Es macht natürlich auch Spaß, wenn die Aufgaben wachsen und das
Protokoll immer noch paßt. Z.B. ist bei jeder µC-Baugruppe auch ein
Firmwareupdate, d.h. der Aufruf des Bootloaders implementiert.
Peter D. schrieb:> @Dirk (Gast)> Mein Chef würde mich fristlos entlassen, wenn ich so ein Protokoll> implementieren wollte. Spätestens beim Review würde es auffallen.
Das ist verständlich.
Wenn bei dir der Wille nicht ausreicht um 2 Byte ohne Unfall ein paar
Meter mit EINER seriellen Leitung zu übertragen, dann würde das
sicherlich beim Review auffallen.
Dein Chef hat sicherlich kein Problem mit einem Peter der nichts
eigenständig beantworten kann und sogar den Chef als Hilfe für eine
Antwort benötigt, solange du nicht im Review befragst wirst.
Da du offenleslich keine eigene Identität hast und auch
>>versuch mal ohne Hilfe von unbestimmten "man"/... auszukommen
nicht eigenständig lesen konntest, versuche ich mal eine Simulation
als wenn du (Peter) man wärst:
Peter D. (als Peter simuliert) schrieb:> Es geht Peter nicht darum, daß bei simpelsten Aufgaben sowas> funktionieren könnte. Da hätte Peter viel zu tun, wenn> Peter je nach Aufgabe aus verschiedensten Texten> verschiedene Protokolle definieren müßte. Protokolle, die Peter interessieren,
müssen zumindest für die von Peter> nicht genannten geplanten Anwendungsfelder skalierbar sein.> Peter hat leider auch> mit externen> Protokollen (die Peter wohl erlebt hat) zu tun, wo Peter sich fragt, was hat
der Peter Bekannte
> denn geraucht. Das ist aber noch lange kein Grund, es genauso wie> Peter es erlebt hat, schlecht zu machen.
==> Peter schreibt offenleslich von seinen Protokollen (und versteht
Peter nicht)
Dein protokolliertes Textprotokoll konntest du auch nicht lesen, aber
vielleicht erinnerst du dich noch an:
Peter D. (simuliert als Peter)schrieb:> Peter nimmt doch nicht für jeden einzelnen Task einen MC, sondern ein> MC von Peter kann viele Tasks gleichzeitig bearbeiten. Daher ist nicht
garantiert,
> daß der Sender (ein MC von Peter) Bytes pausenlos senden kann, sondern es
können auch
> andere wichtigere Interrupts,(die Peter zuvor bei dem MC von Peter
programmiert hat) dazwischen kommen. Peter muß also einen
> sinnvollen Timeout definieren, der erheblich größer als eine Bytezeit ist.
==> Peter ist inkompatibel EINEM PC auf EINER Leitung mit EINEM Task
zwei (2) Bytes hintereinander zu senden und EINE Pause zu programmieren
==> andere Menschen verstehen, dass der PC warten kann und müssen
nicht pausenlos senden
Peter D. schrieb:> Oft muß Peter auch bei größeren Entfernungen Protokolle über andere> Interfaces (Ethernet, USB, WLAN) tunneln, da gehen dann sämtliche> Zeitabhängigkeiten verloren.
==> Dirk kann trotzdem in EINEM Labor kurze Strecken mit einer einfachen
Schnittstelle 'Zeitabhängigkeiten' gewährleisten
==> Peter kennt weder ATM-Netze (asynchron) noch SDH (synchron) mit
Zeitabhängigkeiten, auch wenn praktisch das weltweite Internet auf den
längeren Strecken damit betrieben wird.
Lieben Gruß an den Chef der einen Peter beschäftigt, der solche massive
Angst vor Einzahl/ konkreten (nachlesbaren) Wörtern und einem
konkreten 'Protokoll' hat, dass er den Chef als Hilfe benötigt.