hallo! :-) ich habe hier so ein ziemlich derbes anfängerproblem. hab mir nun dieses board gekauft (http://shop.mikrocontroller.net/csc_article_details.php?nPos=0&saArticle[ID]=60&VID=GgFgrhmyOcDomnjn&saSearch[word]=&saSearch[category]=AVR&saSearch[special]=) und weiss nun nicht wie ich an den kontroller rankomme. die treiber für usb-serial sind installiert und scheinen ok zu sein. es wurde nun com3 angelegt. ich habe versucht mich mit ponyprog zu connecten und mit avr studio (STK500 or avrISP auf com3) aber die versuche misslingen. kann mir jemand vll. einen tipp geben, wie ich da weiterverfahren kann? danke! gruß
Dein Proble mist, dass auf dem Bord kein ISP realisiert ist. USB ist nur eine Schnitstelle mehr nicht. Du könntest dir einen Bootloader auf deinen Controller brennen lassen. Dann kannst den auch Programmieren.
Hallo Alex, hier liegt wahrscheinlich ein Denkfehler von Dir vor! Das Board ist ein Entwicklungsboard, mit einem USB-Anschluß. Wobei der USB-Anschluß zur Kommunikation mit einem PC gedacht ist, und nicht zum Entwickeln der eigentlichen Anwendung. Soll heißen: Du programmierst ganz normal mit AVR-Studio, und schiebst deinen Code mit einem ISP, parallel Programmer oder halt einem JTAG zu deinem AVR hinüber. Also ganz normal wie z.B. im Tutorial beschrieben. Wenn Du jetzt Daten ( z.B. Messwerte) zum PC übertragen willst kannst Du das über USB machen. Dazu mußt Du den Datenaustausch aber im µC und PC separat programmieren! Wenn Du Deine Programme in den µC per USB übertragen willst mußt Du Dir einen Bootloader für den AVR und evt. einen Software für den PC schreiben! Fazit: am einfachsten ein Parallelkabel bauen und über Pony-Prog programmieren, oder für wenig Geld einen ISP kaufen (oder bauen) und dann bequem aus dem Studio heraus flashen, oder am besten ein JTAG-Modul kaufen (da kannst Du auch debuggen)!! Ich bevorzuge letzteres! Ich hoffe, jetzt sind alle Klarheiten beseitigt! Viel Spaß! Asterix-007
steht uebrigens auch so im "datenblatt" das im shop verlinkt ist: "There are two ways to program AVR-P40-USB: with ICSP port and with JTAG port. To program via ICSP port you need serial port or parallel port AVR-ICSP programmer dongle" was mal wieder zeigt: wer lesen kann, ist klar im vorteil.
"was mal wieder zeigt: wer lesen kann, ist klar im vorteil." wer sich dem motto verpflichtet, kann gleich in der bibliothek einziehen und alle menschen hassen lernen....
hallo, habe nun es geschafft lämpchen blinken zu lassen (via gcc). wollte nun einige ausgaben mit dem uart realisieren aber es kommt nur mist am "com port" an. wohlgemerkt ist der comport ein simuliertes ding von dem herstelle. die kommunikation mit dem pc funktioniert eigentlich über usb. kennt vielleicht schon wer so einen fehler? hier meine ausgabe; ...xþxxþx xxxxþxxþxxþ x.... gruß
Hi Alexander,
>>> "was mal wieder zeigt: wer lesen kann, ist klar im vorteil."
wer sich dem motto verpflichtet, kann gleich in der bibliothek
einziehen und alle menschen hassen lernen.... <<<
Bitte sei mir jetzt nicht böse, aber es scheint wirklich so, als ob Du
Dir den Adapter gekauft hast, ohne genau zu wissen, was es ist. Und da
muss man sich dann einen solchen Vorwurf schon gefallen lassen.
Gruß
Fred
ja ist schon ok. ich mag nur solche sprüche nicht.... die nerds an der uni schmücken sich schon oft genug mit sowas... jemand ne idee zum problem? :-)
.def temp = r16 .equ CLOCK = 1000000 .equ BAUD = 9600 .equ UBRRVAL = CLOCK/(BAUD*16)-1 also ich weiss zwar nicht warum BAUD*16, aber so stehts in vielen anderen quellcodes... :-P
> also ich weiss zwar nicht warum BAUD*16, aber so stehts in vielen > anderen quellcodes... :-P Das Datenblatt des entsprechenden AVRs würde dir dazu mitteilen, dass der Arbeitstakt des UART mit der 16-fachen Frequenz der Baudrate läuft. Es werden also 16 UART-Takte benötigt, um 1 Bit Daten zu empfangen oder zu senden. ...
hmm.... mit gcc kommt auch nur mist an.... :-P
liegt es vielleicht an der usb-serial schnittstelle?
/*gcc*/
#include <avr/io.h>
#include <avr/delay.h>
#define F_CPU 1000000
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16)-1)
//-----------------------------------------------------
void _writeString (const char *string)
{
while (*string)
{
while (!(UCSRA & (1<<UDRE)))
{}
UDR = *string++;
}
}
//-----------------------------------------------------
void main()
{
UCSRB = (1<<TXEN);
UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0);
UBRRL = (unsigned char) USART_BAUD_SELECT;
while(1) {
_delay_ms(300);
PORTB &=0;
PORTB |=(1<<2);
_writeString ("Hallo, Welt!\n");
PORTB &=0;
}
// Endlossschleife nach Verlassen von main
}
Ich wiederhole meine Frage von 21:47 Uhr: Benutzt du einen Baudratenquarz? http://www.hanneslux.de/avr/tipps/baudratenquarz.html Wenn ja, hast du dieses auch per Fusebits "eingestellt"? Wenn nicht, dann läuft der AVR mit dem internen RC-Oszillator, der für UART-Betrieb ungeeignet ist.
Es sieht mit nach 1MHz int. RC aus, aber warten wir mal bis der OP antwortet. Grüße, Freakazoid
Vom Define her siehts nach 1MHz interner RC aus - aber was ist bei diesem Board voreingestellt? Erstmal müsste man die tatsächlich vorhandene Taktfrequenz haben. Mit dem "define" wird das nämlich nicht festgelegt, sondern nur dem Compiler mitgeteilt. Beim internen Oszillator sind 9600 Baud schon reichlich wackelig, da er nicht sonderlich genau ist. Mit 2400 Baud gehts zuverlässiger. Ansonsten würde ich ebenfalls einen sog. "Baudratenquarz" empfehlen, also z.B. 3,686400 MHz. Gruß Thomas
hallo leute. dank euch allen! hab da jetzt nochmal genau nachgesehen und die die fuses überprüft. habe eigentlich gedacht, dass der interne genutzt wird. ist nich. die einstellungen beziehen sich auf den 8Mhz Quarz mit den Fuses nach diesem screenshot: http://www.mikrocontroller.net/images/atmega8-nachher.png in den compilerdefinitionen habe ich nun #define F_CPU 8000000 eingestellt. (warning. int overflow... ? was macht der compiler damit? so ein fehler führt ja normalerweise zu negativen werten im register....) gruß
Du hast richtig erkennt, dass der Compiler deinen #define nicht mag. Du solltest ihm also sagen, dass die Zahl ein long ist und kein int, also #define F_CPU 8000000L
ok. ich pack ein.... habe in bascom bei den fuses gesehen, dass der quearz nicht eingestellt ist.. habs geändert..alles tot.... :-( fuck
Quarzoszi oder sonstige "saubere" Taktquelle anhängen und neu programmieren.
hängt laut datenblatt aber schon was dran. :-( http://shop.mikrocontroller.net/csc_article_details.php?nPos=0&saArticle[ID]=60&VID=GgFgrhmyOcDomnjn&saSearch[word]=&saSearch[category]=AVR&saSearch[special]=
Das, was Du gemacht hast, nennt sich "aussperren". Du hast die Fuses falsch programmiert. Der Atmel kennt: - internen Oszillator - externen Quarzoszillator - externen R/C Oszillator - externe Taktquelle. Die beiden letzten Einstellungsmöglichkeiten funktionieren nicht mit dem eingebauten Quarz. Kannst Du Dich noch erinnern, wie genau Du die Fuses programmiert hast? Gruß Thomas
Ja ... es hängt ein Quarz dran. Das ist keine Ideale taktquelle, da er erst ins schwingen geraten muss, und das mit einem internen schaltkreis des AVR den du eben abgeschaltet hast. Jetzt benötigst du eine wirklich saubere taktquelle. D.h. ein anderer controller der das Signal erzeugt oder ein Quarzoszilator oder soetwas.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.