Liebe Leidensgenossen, Gleich habe ich keine Haare mehr zum Ausraufen: Nach Portierung eines Beispielprogrammes von BASCOM nach C habe ich unterschiedliche Schaltspannungen an allen Ports, die auf high geschaltet sind. Flashe ich das BASCOM Hex-File, so liegen ca. 4,7 V auf PIN5 PORTD. Flashe ich das C Hex-File, so kann ích nur ca. 2,4 V am gleichen Ausgangspin messen. Liegt das an etwaig nicht korrekt abgeführten Lizenzgebühren oder hat jemand schon mal Ähnliches erlebt und kennt die Lösung zu dieser wochenendraubenden Angelegenheit? Ich würde mich über brauchbare Tipps freuen. Peter
Mache es gelegentlich in die andere Richtung. Wenn es mal nicht sofort funktioniert hat, lag es bisher immer an mir selbst. Also, nochmal den Code durchgehen, kann ich da nur empfehlen. So ohne irgendeine weitere Info kann man auch nicht sonderlich brauchbare Tipps geben.
Hallo, zeige mal Deinen C-Code. Hast Du die Datenrichtung korrekt festgelegt? Es ist alles WieImmer
> nicht korrekt abgeführten Lizenzgebühren wovon redest du ? > Flashe ich das C Hex-File, so kann ích nur ca. 2,4 V am gleichen > Ausgangspin messen. da würde ich sagen, hast du schlecht portiert.
Danke für die schnellen Antworten; Gibt doch noch Bundesbürger ohne langweiligen Fersehsamstag :) Ich habe beiede Sourcecodes in einer Datei angefügt und hoffe, dass alles korrekt dargestellt wird. Zu den bisher aufgetretenen Fragen folgende Antworten: Source? (kommt) Liegt an meiner fehlerhaften Portierung => Jo, deshlab frage ich hier nach Züchtigung meiner Codierfähigkeiten. RE: Lizenzgebühren > sorry, das war etwas sarkastisch gemeint. Ich denke der Punkt Datenrichtung könnte mir übel mitgespielt haben. Prozessor: ATmega32 auf Pollin Eval-board V.2.0.1 Dann bin ich ja schon mal gespannt, wo ich mit der Fingerspitze beim Codieren hängen blieb.
> DDRD = 0x7; /* PD2 bis PD4 als Eingaenge */
PD3 bis PD7 als Eingang
Hallo, auf die schnelle sehe ich nur, dass Du zB PD7 für den Beep benutzt, dieser aber in der Init() als Eingabe festgelegt ist. Im C-Code legst Du die Datenrichtungen anders fest als in Bascom. Prüfe das selbst mal nach. Alles WieImmer
Danke Lucky, Das war die tückische Stolperfalle für mich unbedachten Codierer! Ddrd = &B11100000 in BASCOM wird zu DDRD = 0xE0; /* PD5 bis PD7 als Eingaenge */ Ich glaube jetzt könnte es funktionieren.
Auch meinen Dank an WieImmer! Stimmt es dann so mit der nachfolgenden Zeile? DDRD = 0xE0; /* PD5 bis PD7 als Eingaenge */
Hier ein Auszug aus meiner simple-UART Initialisierung (poll):
1 | void uart_init (void) |
2 | {
|
3 | unsigned short ubrr = -.6 + F_CPU/((16L-8*U2X_BIT) * BAUDRATE); |
4 | |
5 | UBRRH = ubrr >> 8; |
6 | UBRRL = ubrr; |
7 | |
8 | UCSRA = (U2X_BIT << U2X) | (1 << TXC); |
9 | |
10 | // Enable UART Reciever, Transmitter
|
11 | // Data mode 8N1, asynchronous
|
12 | |
13 | UCSRB = (1 << RXEN) | (1 << TXEN); |
14 | |
15 | #if defined (URSEL)
|
16 | UCSRC = (1 << UCSZ1) | (1 << UCSZ0) | (1 << URSEL); |
17 | #else
|
18 | UCSRC = (1 << UCSZ1) | (1 << UCSZ0); |
19 | #endif
|
20 | |
21 | // Flush input buffer: remove rubbish that might occur after
|
22 | // (re)configuering the UART hardware
|
23 | do
|
24 | UDR; |
25 | while (UCSRA & (1 << RXC)); |
26 | }
|
Wie zu sehen ist, wird der UART initialisiert bevor er aktiviert wird!
Danke Johann, Ich werde Deine UART Implementierung auch gleich mal testen. Übrigens lautet die Datenrichtungsdefinition nun so korrekt, denn PD7 ist nur ein Ausgang und muss nicht aktiv sein: DDRD = ( (1 << PD5) | (1 << PD6) ); /* PD5 und PD6 als Eingaenge */
Hast Du früher mal mit PICs hantiert? Beim AVR ist das andersrum.
1 | DDRD = ( (1 << PD5) | (1 << PD6) ); /* PD5 und PD6 als Eingaenge */ |
Definiert PD5 und PD6 als Ausgang. Die anderen Pins an Port D sind danach Eingänge. Den übringen Code habe ich mir allerdings nicht angesehen. Ich weiß nicht was PD5 + PD6 eigentlich tun.
Johann L. schrieb: > unsigned short ubrr = -.6 + F_CPU/((16L-8*U2X_BIT) * BAUDRATE); Erklärst du bitte mal, wie da die -0.6 reinkommen ? Mit ein bisschen Pech ziehst du dir damit die komplette Fliesskommabibliothek in dein Projekt und dein Code ist riesengross. Es ist viel sinnvoller, UBRR als Konstante vom Compiler ausrechnen zu lassen und dann nur diese Konstante in die Baudratenregister zu schreiben.
Manfred hat Recht; Korrekt erspäht. Ich lief damals von den PICs über. Ausschlaggebender Grund war die Verfügbarkeit des GCC für die ATMEL µCs. Der Kommentar war noch falsch, für das Pollin Eval Board muss es heissen: DDRD = ( (1 << PD5) | (1 << PD6)| (1 << PD7) ); /* PD5, PD6 und PD7 als Ausgänge */ Hier sind PD5 und PD6 die 2 LEDs als Ausgänge und PD7 hat der Pollin Sourcecode falsch als Eingang definiert. Deshalb läuft der Summer auch ganz leise oder knackt in meinem Fall nur leicht bei 2,7 V anliegender Spannung im High Zustand. Mit der oben stehenden Zeile sollte man dann den richtigen Klang erzielen. RE: '-.6' Matthias hat Johann's Quellkode sorgsam studiert. Der UART Teil bei mir stammte aus dem Tutorial und hat nicht die Fliesskommaproblematik. Dennoch danke für die Unterstützung!
Matthias Sch. schrieb: > Johann L. schrieb: >> unsigned short ubrr = -.6 + F_CPU/((16L-8*U2X_BIT) * BAUDRATE); > > Mit ein bisschen Pech ziehst du dir damit die komplette > Fliesskommabibliothek in dein Projekt und dein Code ist riesengross. Nö. Alle Werte sind zur Compilezeit bekannt: F_CPU, U2X_BIT und BAUSRATE. GCC faltet die Konstanten fleissig und zuverlässig auch bei abgeschalteter Optimierung. > Es ist viel sinnvoller, UBRR als Konstante vom Compiler ausrechnen zu > lassen und dann nur diese Konstante in die Baudratenregister zu > schreiben. Genau das passiert im Programm.
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.