mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMega8 an Serieller SS sendet Müll


Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe aus dem UART-Teil des AVGCC-Tutorials mal die Routine für das 
senden eines einzelnen Zeichens auf die Serielle Schnittstelle 
ausgeliehen und versucht mittels diesen Codes meinen ATMega8 dazu zu 
bringen, P (0x50) an meinen Computer zu senden.... Das ganze in einer 
Endlosschleife, der PC empfängt auch tatsächlich jede menge 
(gleiche)zeichen, jedoch nicht P.
anstelle des P empfängt er § (0x15). wenn ich nun hingehe und versuche O 
(großes o = 0x4F) zu senden kommt wider erwarten nicht das Zeichen 
(0x14) welches einen vor §(0x15) ist, sondern aus der ganz anderen Ecke 
der ASCII Tabelle das X (0x58)....

Hier der code
#include "avr/io.h"


/* USART-Init beim ATmega16 */
#ifndef F_CPU
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */
#endif
 
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)
 
#define UART_BAUD_RATE 19200


int main(void)
{
  /*        I/O Settings      */
  UCSRB |= (1<<TXEN);                 // UART TX einschalten
    UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1 
  UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
  UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
  
  unsigned int i=0;
  

  
  while(1)
  {    
    // bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
    while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
      
    }
    
    UDR = 0x50;    // P
  }
}

kann es vll daran liegen, das in dem Tutorial der Code für einen 
ATMega16/32 ist und ich ihn auf einen ATMega8 anwende ? normal 
unterscheiden die 3 sich doch abgesehen vom Speicher nicht wirklich oder 
??


Danke

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das übliche: Welche Taktquelle? Und versuchs mal mit
#define F_CPU 16000000UL
Und check mal, wenn Du mit AVRStudio arbeitest, ob in den Configuration 
Options auch 16000000Hz stehen. Wenn nicht, dann eingeben.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und danke für die rasche Antwort....

leider macht er immer noch das gleiche wie vorher, also das $ anstelle 
des P Senden. naja zumindest empfängt der PC das §, weiß nicht ob der µC 
das P sendet oder doch tatsächlich das §... aber ich denke das liegt am 
µC, das der mist sendet :)

Also ich arbeite mit Programmers Notepad und werfe die Programme dann 
per PonyProg rein. Als Taktquelle habe ich einen externen 16MHz Quarz.
Bei den Fuses habe ich alle Häckchen bei CKSEL entfernt, also sollte auf 
externen Takt umgestellt sein.

Hat sonst noch jemand eine Idee ??

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Als Taktquelle habe ich einen externen 16MHz Quarz.
> Bei den Fuses habe ich alle Häckchen bei CKSEL entfernt, also sollte auf
> externen Takt umgestellt sein.
Für einen Quarz darfst Du aber KEINEN externen Takt einstellen. Du 
musst auf "external Crystal/Resonator" (high Frequency, > 8 MHz) fusen. 
Sonst klappt gar nichts.

EDIT:
"Externer Takt" (external clock) bedeutet, dass ein externer Taktgeber 
(z.B. ein QuarzOSZILLATOR oder eine andere externe Taktquelle) 
dranhängt, die bereits ein "fertiges" Taktsignal liefert. Dabei wird 
durch die Fuses der im µC eingebaute Oszillator komplett abgeschaltet.

Da die Fuses in PonyProg allerdings invertiert sind, müssten die 
Einstellungen bei Dir passen (CKSEL3..0 = 1111). Der Fehler muss dann 
woanders liegen.

Aber verwechsle nie "externer Takt" mit "externer Quarz"! Steht im 
Datenblatt allerdings an einigen Stellen auch ein bisschen verwirrend 
drin...

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sorry meinte ja chrystal....
ist auch richtig eingestellt:
External Crystal/Ceramic Resonator 1111 - 1010
da ich einen Crystal habe also auf 1111, d.h. bei Ponyprog alle Häckchen 
bei CKSEL weg, so habe ich das auch....

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, die CKOPT-Fuse sollte für so hohe Frequenzen programmiert sein 
(Häkchen rein).

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...und im Terminal ist auch das richtige Frame-Format und die Baudrate 
eingestellt?

Autor: Studiologe .-. (studiologe)
Datum:
Angehängte Dateien:
  • preview image for HT.jpg
    HT.jpg
    22,1 KB, 159 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Jo CKOPT ist natürlich auch ein Häckchen,
die Einstellungen bei HyperTerminal sind wie auf dem Bild im
Dateianhang zu sehen richtig eingestellt. aber es geht leider nicht...
Empfangen wird ja die ganze zeit etwas, aber leider das falsche Zeichen

§ statt P

Autor: Auch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lade dir mal

http://www.docklight.de/

runter.
 Benutze nur noch das, ist um Welten besser
als das der Firma Winzigweich.

Es zeigt dir auch Steuerzeichen an.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, also ich habe mir das mal runtergeldan, gefällt mir ehrlich gesagt 
auch schon besse als das von M$

jedoch empfange ich damit auch nur Mist....
Ich sende laut source-code ein 0x50, empfangen wird
ASCII: }
HEX  :7D
Dec  :125


also liegt es auch nicht am Hyperterminal, obwohl ich da auch was 
anderes empfange (§ statt 0x50)

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm also komischer Effekt ist nun, das wenn ich auf stopp klicke, kurz 
darauf auf start, das dann unterschiedliche daten empfangen werden.....

beim ersten mal war es:
ASCII: }
HEX  :7D
Dec  :125
dann plötzlich
ASCII: -
HEX  :5F
Dec  :095

dann wieder
ASCII: }
HEX  :7D
Dec  :125


????? was ist los mit der verrückten Computerwelt ?

Autor: Auch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit was Prog. du?
AVR Studio & WinAVR?
Bei mir funktioniert der code einwandfrei.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>das dann unterschiedliche daten empfangen werden.....

Kann passieren wenn die Zeichen ununterbrochen kommen, dann kann es 
passieren, dass der PC das Startbit nicht mehr korrekt finden kann.

Hast du einen USB/Seriell-Adapter dran? Dual-Core CPU? Das kann auch 
Probleme machen, besonders wenn mehrere Adapter gleichzeitig laufen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das liegt an baudrate/stoppbit/paritätseinstellungen!
Irgendwo gleichen die sich nicht!
vielleicht stimmt auch nur die quartzfreuqenz nicht

Autor: Auch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du WinAVR benutzt, welche Quarzfrequenz ist in der
Project Option eingestellt?
Diese Einstellung überschreibt dir die Einstellung in deinem Code.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich arbeite mit Programmers Notepad und werfe die Programme dann
per PonyProg rein, wie oben schon erwähnt.

wo finde ich denn die Project Option  ???

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach da
/* USART-Init beim ATmega16 */
#ifndef F_CPU
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */
#endif

mal
/* USART-Init beim ATmega16 */
#define F_CPU 16000000           /* Oszillator-Frequenz in Hz */

draus.
Also ohne das #ifndef / #endif.
Wer weiss, welche CPU Frequenz dem Compiler über das Makefile
vorgegeben wird.

Autor: Auch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere das UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1
in das UCSRC |= (1<<URSEL)|(1<<UCSZ0))|(1<<UCSZ1);     // Asynchron 8N1
mal.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Karl heinz:
Ich habe seinen Code schon getestet, UBRRL stimmt (51), UBRRH braucht's 
normalerweise nicht, da bei 16MHz und Baudraten > 3922 sowieso immer 0 
drinsteht.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Studiologe .-. wrote:
> wo finde ich denn die Project Option  ???
Lass Dir nix erzählen. Die Configuration Options gibts nur im AVRStudio, 
mit dem Du ja nicht arbeitest. Du müsstest, wenn überhaupt, dann im 
Makefile die Änderungen direkt machen. Aber die Methode von Karl Heinz 
ist für Deine Einstellungen sicher die sicherste.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch einer wrote:
> Ändere das UCSRC |= (1<<URSEL)|(3<<UCSZ0);     // Asynchron 8N1
> in das UCSRC |= (1<<URSEL)|(1<<UCSZ0))|(1<<UCSZ1);     // Asynchron 8N1
> mal.
Das ist beide Male exakt dasselbe...

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schätze auch mal dass es am Makefile liegt, wenn's mit Mfile erstellt 
wurde dürften da 8MHz drinstehen (default).

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. wrote:
> Schätze auch mal dass es am Makefile liegt, wenn's mit Mfile erstellt
> wurde dürften da 8MHz drinstehen (default).
In dem Falle müsste ja die Lösung von Karl Heinz den gewünschten Erfolg 
bringen. Wir werden sehen...

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm also zu F_CPU finde ich garnichts im Makefile, sollte also daher 
egal sein oder ?
Hat auf jeden Fall auch nicht den gewünschten Effekt gebracht :(

Autor: Studiologe .-. (studiologe)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal das Makefile, vll habe ich ja auch irgendwas anderes darin 
falsch gestellt....

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW:
Wenn bei solchen Sachen irgendwas nicht klappt, ist es IMMER sinnvoll, 
als erstes alle Makros, die irgendwelche kritischen Werte berechnen oder 
angeben (in diesem Falle gilt das besonders für UART_UBRR_CALC und 
F_CPU), rauszuschmeißen und die Register zumindest probeweise von Hand 
zu setzen. Also in diesem Falle alle #defines weg und ins UBRR den 
errechneten Wert (also hier 51, wie ja oben irgendwo schon mal erwähnt) 
reinschreiben.

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denk, du benutzt einen Mega8?
Im Makefile ist noch Mega16 gewünscht...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Studiologe .-. wrote:
> hmm also zu F_CPU finde ich garnichts im Makefile, sollte also daher
> egal sein oder ?
Den Fall hatten wir neulich schon mal. Da war es zwar ein vom AVRStudio 
erstelltes Makefile, in dem ohne eine explizite Angabe bei den 
Configuration Options auch kein F_CPU-Wert zu finden war (ansonsten 
gleicher Aufbau wie bei Dir mit #ifndef F_CPU...). Klappen tat es aber 
nur mit einer Eingabe des korrekten Frequenzwertes in den Configuration 
Options vom AVRStudio (und damit im Makefile).

> Hat auf jeden Fall auch nicht den gewünschten Effekt gebracht :(
Wie gesagt, schmeiß das #ifndef...#endif raus. Dann muss der Compiler 
auf jeden Fall den angegebenen Wert nehmen. Oder, wie oben gesagt, alles 
direkt eingeben. Oder dem F_CPU für Code-interne Anwendungen einen 
anderen Namen verpassen...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ozo wrote:
> Ich denk, du benutzt einen Mega8?
> Im Makefile ist noch Mega16 gewünscht...
Oha! Ich hab mir das Makefile jetzt nicht angeschaut, aber wenn das so 
ist, dann wundert mich gar nichts...

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hab ich extra nochmal nachgeguckt, ich habe nicht phantasiert:
---
# MCU name
MCU = atmega16
---

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>UCSRC |= (1<<URSEL)|(3<<UCSZ0);

URSEL sollte low sein. Mit high schreibst du in UCSRC, nicht in UBRRH.
Kommentiere diese Zeile einfach mal aus.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also gut habe jetzt mal alles ins folgende geändert, was leider auch 
nicht geholfen hat....
im Makefile habe cih auch ATMega8 reingeschrieben statt ATMega16, half 
auch nicht :(
#include "avr/signal.h"
#include "avr/io.h"

int main(void)
{
  /*        I/O Settings      */
  UCSRB |= (1<<TXEN);                 // UART TX einschalten
    UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1);     // Asynchron 8N1

  
  unsigned int i=0;
  

  
  while(1)
  {    
    // bei neueren AVRs steht der Status in UCSRA/UCSR0A/UCSR1A, hier z.B. fuer ATmega16:
    while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
      
    }
    
    UDR = 0x50;    // P
    
  }
}

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. wrote:
>>UCSRC |= (1<<URSEL)|(3<<UCSZ0);
>
> URSEL sollte low sein. Mit high schreibst du in UCSRC, nicht in UBRRH.
> Kommentiere diese Zeile einfach mal aus.
Hallo? Genau das will er doch! Da steht explizit, dass UCSRC geschrieben 
werden soll!

Es kann eigentlich tatsächlich nur am Makefile liegen. Wenn da der 
falsche µC-Typ drinsteht, ist die Wahrscheinlichkeit für ein 
Nicht-Funktionieren sehr groß.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Studiologe .-. wrote:
> Also gut habe jetzt mal alles ins folgende geändert, was leider auch
> nicht geholfen hat....
Du darfst das Setzen des UBRRL auch nicht wegschmeißen! Woher soll der 
denn jetzt wissen, mit welcher Baudrate er arbeiten soll?

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, so bringt das nix.
Schick doch bitte mal die Ausgabe von make.

Autor: Studiologe .-. (studiologe)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
habe aber Makefile wie gesagt angepasst...
siehe anhang

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Genau das will er doch!
Hab's gerade gesehen. Ich habe diese Bits noch nicht verwendet, lief bis 
jetzt immer prima mit xx,n,8,1.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...Nur damit wir uns richtig verstehen: Die Zeile
UBRRL = 51;
ist WICHTICH. Die muss da irgendwo bei der Initialisierung stehen 
bleiben.

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, nach erstem Augenschein sieht Makefile sinnig aus.
Und was bekommst du als Ausgebe bei "make all" ?

Autor: Thilo M. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kannst es ja mal mit dem Malefile versuchen.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm vll liegt es ja auch daran, wie ich das miteinander verkabelt habe?!
Also
µC   -- PC
TxD   RxD
RxD   TxD
GND   GND
VCC   CD (Carrier Detect)

sollte doch soweit richtig sein, vor allem da der PC ja auch was 
empfängt

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#include "avr/signal.h"
ist übriges veraltet, sollte nicht mehr benutzt werden.
Und da du ja sowieso keine Interrupts benutzt -> raus damit

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pegewandler ist schon dazwischen?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie jetzt, direkt oder über MAX232 (oder sonstigen Pegelwandler)?

Autor: Auch einer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe aus deinem Code mit AVR Studio mal ein Hex-File gemacht.

Teste das einfach mal.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pegelwandler ? ähhh hmmm also ich glaube daran liegts, ist nämlich 
keiner dran....

wie sieht denn sowas aus ? also bisher gehe ich noch direkt dran, wird 
auch der fehler sein.... oder ?

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Studiologe .-. wrote:
> Pegelwandler ? ähhh hmmm also ich glaube daran liegts, ist nämlich
> keiner dran....
Autsch! Das erklärt einiges. Man sollte Dich...

> wie sieht denn sowas aus ? also bisher gehe ich noch direkt dran, wird
> auch der fehler sein.... oder ?
Google mal nach MAX232. Im AVR-GCC-Tutorial steht übrigens an der 
entsprechenden Stelle auch etwas über die Pegel!

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst auch Testweise mal das UCPOL-Bit setzen, das invertiert die 
Pegel. Manche Schnittstellen kommen mit 0 und 5V aus.

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hehe jo den absatz habe ich gan übersehen :)
tut mir leid, das ich eure zeit so "verschwendet habe"...
ich bin mal eben bei reichelt was bestellen

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo kann ich denn das UCPOL bit setzten ?
UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1)|(1<<UCPOL);     // Asynchron 
8N1

oder ??

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UCSRC |= (1<<URSEL)|(1<<UCPOL);

zum Beispiel?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich vermute einen MAX232 ;-)

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Studiologe .-. wrote:
> wo kann ich denn das UCPOL bit setzten ?
> einfach über UCPOL = 1; ??
> steht so zumindest im datenblatt
Ich frage mich langsam, ob Du Dich überhaupt ernsthaft mit der Materie 
beschäftigt hast, oder ob Du einfach nur hirnlos Code kopiert hast, ohne 
ihn zu verstehen.

Wie setzt Du denn in "Deinem" Code oben die Bits in den Steuerregistern? 
Aha! Und genau so wird auch das UCPOL behandelt...

Autor: Studiologe .-. (studiologe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja habs gesetzt über
UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1)|(1<<UCPOL);     // Asynchron 
8N1

hat aber auch nicht den gewünschten effekt gebracht, mus nen 
pegelwandler her...

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur noch eine ganz peinliche Frage, wie hast du denn RX und TX 
verbunden?

Autor: Auch einer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine Schaltung ohne MAX232

Autor: Auch einer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lochraster Bild von oben im Anhang

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thilo M. (power)

>Hast du einen USB/Seriell-Adapter dran? Dual-Core CPU? Das kann auch
>Probleme machen, besonders wenn mehrere Adapter gleichzeitig laufen.

???
Schon wieder 1. April? Duo-Core CPU von USB-RS232 Adaptern überlastet? 
Ist die Software für Duo-core Unterstützung soooo schlecht?

MfG
Falk

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Falk,
nee, wir hatten auf Arbeit neue Laptops angeschafft (Dualcore), mit 
denen konnten wir unsere Messumformer per RS232 nicht mehr 
parametrieren. Laut Softwareprogrammiere liegt's am Dualcore, warum auch 
immer.
Mit den Adaptern hatte ich selbst schon Probleme, wenn zwei Adapter sich 
einen Treiber teilten gab es schwere Timingprobleme, mehrere Bytes 
wurden 'verschluckt' und beim nächsten Ansprechen kamen die auf einmal.
Das Problem ist nicht aus der Luft gegriffen, hat schon seinen Grund 
warum ich gefragt habe.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas gibt's wirklich. Dass Device-Driver an einem Multiprozessorsystem 
scheitern. Auch schon auf einem alten P4 mit Hyperthreading oder einem 
Pentium-Pro Doppelprozessorsystem. Weil der Programmierer zu blöd war 
das zu berücksichtigen, oder dessen Arbeitgeber zu knauserig ihm eine 
entsprechende Kiste hinzustellen. Konnte einem auch vor 2 Jahren noch 
bei einer USB-Adapterkarte von Adaptec(!) passieren.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. wrote:
> Kannst auch Testweise mal das UCPOL-Bit setzen, das invertiert die
> Pegel. Manche Schnittstellen kommen mit 0 und 5V aus.

Zitat ATmega8 Datenblatt(10/06) Seite 157:

> UCPOL
> This bit is used for Synchronous mode only. Write this bit to zero when
> Asynchronous mode is used.

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, hatte ich übersehen! ;)

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Thilo M. (power)

>nee, wir hatten auf Arbeit neue Laptops angeschafft (Dualcore), mit
>denen konnten wir unsere Messumformer per RS232 nicht mehr
>parametrieren. Laut Softwareprogrammiere liegt's am Dualcore, warum auch
>immer.

Das ist ein Witz. Wenn gleich ein schlechter. :-(
So ein lausiges 1200 Baud Protokoll scheitert an High-Tec? Und warum. 
Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur 
"Timinganpassung" verwendet.

>Mit den Adaptern hatte ich selbst schon Probleme, wenn zwei Adapter sich
>einen Treiber teilten gab es schwere Timingprobleme, mehrere Bytes
>wurden 'verschluckt' und beim nächsten Ansprechen kamen die auf einmal.

Schnittstelle entweder schlecht geschrieben oder verwendet.
Naja, thats life.

MfG
Falk

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist ein Witz. Wenn gleich ein schlechter. :-(

Wir fanden's nicht soo witzig! :(
Da kommste ganz schön in's Schleudern, gottseidank waren die alten 
Laptops noch da.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur
> "Timinganpassung" verwendet.

Das dürfte aus der Mode sein. Eher schon weil er übersehen hat, dass bei 
einem Multiprozessorsystem der Code des Treibers in mehreren 
Prozessen/Threads gleichzeitig laufen kann.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas Kaiser (a-k)

>> Weil garantiert mal wieder jemand irgendwelche Zählschleifen zur
>> "Timinganpassung" verwendet.

>Das dürfte aus der Mode sein.

1.) Darauf würde ich nciht wetten.
2.) War die Software wahrscheinlich schon älter.

> Eher schon weil er übersehen hat, dass bei
>einem Multiprozessorsystem der Code des Treibers in mehreren
>Prozessen/Threads gleichzeitig laufen kann.

Und? Was änders sich da aus Sicht des Programmierers einer Anwendung? 
Ich würde erstmal sagen GAR NCIHTS! Die LOGISCHE Abfolge MUSS 100% 
identisch sein. Und wenn das Timing sauber über Timer, Flags etc. 
gemacht ist darf da auch GAR NICHTS anbrennen. Wenn, ja wenn . . .

MfG
Falk

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.