Forum: Mikrocontroller und Digitale Elektronik Analogwert im zweierkomplement seriel senden?


von Michael H. (h_m)


Angehängte Dateien:

Lesenswert?

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
void USART_Init( uint16_t ubrr)
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
void USART_Transmit(uint8_t data)
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_t USART_Receive(void)
29
{
30
    while ( !(UCSR0A & (1<<RXC0)) );  // Wait for data to be received
31
    return UDR0;                        // Get and return received data from buffer
32
}
33
 
34
/**** Flush Receive-Buffer (entfernen evtl. vorhandener ungültiger Werte) ****/
35
void USART_Flush(void)
36
{
37
    uint8_t dummy;
38
    while (UCSR0A & (1<<RXC0))
39
    dummy = UDR0;
40
}
41
 
42
int main( void )
43
{
44
    uint8_t data;
45
    USART_Init(UBRR_Value);     // Init UART
46
    USART_Flush();              // Flush Receive-Buffer
47
    DDRB = 0xFF;                // alle PINs an PortB als Ausgänge
48
     
49
    while(1)
50
    {
51
        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

von Peter D. (peda)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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: ADC
AVR-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?

von Michael H. (h_m)


Lesenswert?

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

von Jack (Gast)


Lesenswert?

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

von Dirk (Gast)


Lesenswert?

>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_16 data
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.

von ADC (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

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.

von dummschwaetzer (Gast)


Lesenswert?

was soll den im 2.byte stehen?

von Peter D. (peda)


Lesenswert?

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.

von dummschwaetzer (Gast)


Lesenswert?

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.

von dummschwaetzer (Gast)


Lesenswert?

korrektur
0xFF -0,5°C

von Gustl B. (-gb-)


Lesenswert?

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.

von Dirk (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

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.

von Forist (Gast)


Lesenswert?

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.

von Dirk (Gast)


Lesenswert?

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.

von Michael H. (h_m)


Lesenswert?

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
1
ADMUX |= (1<<MUX2);                // ADC-Kanal 4 einstellen
2
    ADMUX |= (1<<MUX2)|(1<<MUX0);       // ADC-Kanal 5 einstellen

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
void USART_Init( uint16_t ubrr)
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
void USART_Transmit(uint8_t data)
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_t USART_Receive(void)
23
{
24
  while ( !(UCSR0A & (1<<RXC0)) );  // Wait for data to be received
25
  return UDR0;                        // Get and return received data from buffer
26
}
27
28
/**** Flush Receive-Buffer (entfernen evtl. vorhandener ungültiger Werte) ****/
29
void USART_Flush(void)
30
{
31
  uint8_t dummy;
32
  while (UCSR0A & (1<<RXC0))
33
  dummy = UDR0;
34
}
35
36
int main( void )
37
{
38
  uint16_t x, ergebnis,ergebnis1;
39
  uint8_t data;
40
  USART_Init(UBRR_Value);     // Init UART
41
  USART_Flush();              // Flush Receive-Buffer
42
  DDRB = 0xFF;                // alle PINs an PortB als Ausgänge
43
  
44
      //*** Init ADC ***
45
    ADCSRA |= (1<<ADEN);              // ADC aktivieren
46
    ADCSRA |= (1<<ADPS0)|(1<<ADPS1);    // Vorteiler auf 8
47
    ADMUX |= (1<<REFS0);              // Uref = 5V
48
  ADMUX |= (1<<MUX2);                // ADC-Kanal 4 einstellen
49
    ADMUX |= (1<<MUX2)|(1<<MUX0);       // ADC-Kanal 5 einstellen
50
    ADMUX |= (1<<ADLAR);              // Ausgabe linksbündig
51
    DIDR0 |= (1<<ADC5D);              // Dig. Input Kanal ADC5 deaktivieren (spart Strom)
52
     
53
    //*** Dummy Readout ***
54
    ADCSRA |= (1<<ADSC);              // Start ADC-Wandlung
55
    while (ADCSRA &(1<<ADSC));            // Auf Abschluss der Konvertierung warten
56
    x = ADC;                            // Das Ergebnis der 1.Wandlung in x speichern
57
     
58
59
  while(1)
60
  {           // Ausgabe ADC5
61
            ADCSRA |= (1<<ADSC);          // Start ADC-Wandlung
62
            while (ADCSRA &(1<<ADSC));        // Auf Abschluss der Konvertierung warten
63
            ergebnis = ADCH;                // Inhalt von ADCH in ergebnis speichern
64
           USART_Transmit(ergebnis);
65
         _delay_ms(1000);
66
         
67
         // Ausgabe ADC4
68
          ADCSRA |= (1<<ADSC);          // Start ADC-Wandlung
69
          while (ADCSRA &(1<<ADSC));        // Auf Abschluss der Konvertierung warten
70
          ergebnis1 = ADCH;                // Inhalt von ADCH in ergebnis speichern
71
          USART_Transmit(ergebnis1);
72
          _delay_ms(1000);
73
  }
74
}

von Peter D. (peda)


Lesenswert?

@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.

: Bearbeitet durch User
von Dirk (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.