-
Thread
Einfacher Messadapter RS232
Hallo, Seit langen mal wieder hier ! Atmel AtTiny13 mit 9,6 MHz interner Oszillator Mit dem Zeichen U (0x55) initilisiert sich der Software URAT (Auto BAUDing 300 - 115200). Erwartete Antwort kommt ! Mit dem Zeichen 0 (0x30) kann ich dann den logischen Zustand vom PB2
moin erstmal würde ich die DCD,DTR,DSR Ausgänge der RS232 jeweils über eine eigene Diode zusammenfassen , da es passieren kann das diese unterschiedliche Pegel aufweisen (Initialisierung) mfg
-
Thread
Internen Takt beim STM32F031 verwenden
Also das sollte funktionieren, damit läuft der µC auf 48MHz aus dem internen Oszillator: [c] // Enable PLL as Clocksource FLASH_SetLatency( FLASH_Latency_1 ); RCC_DeInit(); RCC_PLLConfig( RCC_PLLSource_HSI_Div2, RCC_CFGR_PLLMUL12 ); RCC_PLLCmd( ENABLE );
das ist doch schonmal eine gute Erkenntniss. Dann ist da eine Kommunikation via RS232 mit einem PC Programm zur Parametrierung vorgesehen? Ist die eine serielle Schnittstelle angeklemmt über die der PC mit dem Board kommunizieren kann? Hoffentlich nicht über die virtuelle COM im STM32F103
-
Thread
Framing Error Frage
meines Transfers ein Framing Error auftritt. ich verschicke 11 Datenbytes asynchron (UART) über die RS232 an meinem Mikrocontroller AT90S8515 --> heisst das mein Start und Stoppbit nicht richtig erkannt werden?? --> oder liegt es daran, dass zuviele Daten gesendet werden?? darf in einem Programm
gesetzt, dass der auch verwendt wird? Sonst läuft > dein Controller vielleicht mit dem interen RC-OSzillator mit 4 MHz. > Sende mal viele Daten vom uC zum PC. Wenn da Aussetzer drin sind stimmt > deine Baudrate nicht. Der AT90S8515 hat so was tolles wie einen internen Oszi und die dazugehörigen Fuses
-
Thread
UART Kommunikationsproblem
RichieRich schrieb: > Jetzt habe ich den internen Oszillator auf 6 MHz umgestellt mit der Das glaube ich nicht. Man kann den internen RC beim ATmega32 nämlich nur auf 1,2,4 oder 8 MHz einstellen.
schrieb: > Die Zeitbasis ist 250 us. Also ca. 850 µs für 9 Bit = ca 10600 Baud. Du wirst den internen Oszillator kalibrieren müssen, sonst wird das nichts.
-
Thread
UART senden ohne Timer emulieren
Infos! Neue Frage: Ich möchte den ADC auslesen. Wenn ich das über die ADC-Register mache [c]rs232_send_byte(ADCH); rs232_send_byte(ADCL);[/c] krig ich immernur 00000011 11111111 gesendet? Wenn ich es folgendermaßen auslese funktionierts [c]rs232_send_byte(ADC >> 8); rs232_send_byte
> Wenn ich das über die ADC-Register mache > > rs232_send_byte(ADCH); > rs232_send_byte(ADCL); > > krig ich immernur 00000011 11111111 gesendet? Weil du falschrum liest => Datenblatt konsultieren.
-
Thread
AVR defekt? Wie feststellen
Ich hab auch erst ewig rumgemacht, Probleme mit USB-RS232-Adaptern, Ansprechen der Devices, Probleme über Probleme. Dann hab ich mir bei Ebay ein STK500 (original verpackt noch versiegelt) gekauft und auf einmal lief alles. So macht das Hobby wieder Spaß
kleine Bruder davon (AVR-ISP) ist bezahlbarer und funktioniert (wie das STK500) auch mit billigen USB-RS232-Umsetzern, oder man nimmt gleich die USB-Variante (MK II). Man hat zumindest die Sicherheit, dass der Programmer auch zukünftige AVR-Typen unterstützt, sobald sie am Markt verfügbar sind, denn die
-
Thread
Wofür braucht man 14.7456 Mhz Quarz?
und +-0,2 bis 0,3% Temperaturdrift drin. Und schließlich ist noch eine wichtige Frage, ob eine RS232-Verbindung (Punkt-zu-Punkt) oder ein halbduplex RS485-Bus vorliegt. Von oben nach unten werden immer größere Anforderungen an die Synchronisierung gestellt, die praktisch nur durch eine angemessene
ich in solchen Fällen immer, wenn jemand aus einem Ingenieurbüro seine Meinung vertritt, dass der interne RC-Oszillator für solche Sachen genau genug sei...
-
Thread
Blutzucker-Messgerät Hardware OLED Display
ich hätte auch eine frage: hat der ATMEGA einen externen Quarz oder OSzillator, oder wird der interne benutzt. danke pcs
Der Pegel ist gleich der Atmega Betriebsspannung (also 3V). Zum Testen benötigst Du einen PC mit RS232-Port und einen Pegelwandler oder einen USB-RS232-Adapter (zB FT232).
-
Thread
Datenübertragung µC <--> PC
Möglichkeiten kenne ich schon -- teilweise, mit Außnahme V-USB, alle schon selbst benutzt: 1. doch RS-232, leider auf PCs immer seltener anzutreffen. Auf Tablets/Smartphones gar nicht mehr (bzw. noch nie)... 2. RS-232 via FTDI oder ähnlichen Chips auf USB (scheint die von vielen favorisierte Methode
selbst programmiert" oder gekauft: Ein OS-Update erfordert manchmal ein Treiber-Update. Und bei "TTL-RS-232 via USB-VCOM" braucht man den Treiber nicht selbst anpassen, das macht der Hersteller. Die Chips sollten gesockelt sein oder gar im Adapter-Stecker integriert sein. Ich führe daher nur RS-232
-
Thread
AVR/Atmega8 an STK500 - UART/USART
Andrey, hast Du auf dem STK500 die Verbindung vom PortD (Pins PD0 und PD1) zum Anschluss "RS232 SPARE" (STK500-User Guide, Seite 3-5) hergestellt? Steckt Dein RS232-Kabel im Anschluss "RS232 Port for Communication" (STK500-User Guide, Seite 3-1)? Ciao, mare_crisium
bedeutet, dass das Stopp-Bit zu früh kommt. Das dürfte jetzt das schon von Karl Heinz angesprochene "interner RC-Oszillator"-Problem sein.
-
Thread
"USB to RS232" korrekt?
Hi hast du dir das Datenblatt vom FT232 mal angesehen? Da steht genau drin wie du den beschalten must um einen USB zu RS232-Wandler zu erstellen. Da stehen auch die verschiedenen Spannungsversorgungen drin. Daniel
einholen. Nicht, Mach es so wie im Datenblatt. So auf den ersten Blick. C1 muss 100nF sein. Der FT232RL brauch keinen Quarz, der interne Oszillator reicht. MFG Falk P S Warum baust du so ein Standardding selber? Gibts für wenig Geld fertig im Laden. Nicht sinnvoll.
-
Thread
Baudrate Mega128L 4Mhz intern geht 8Mhz intern nicht
geht #define cpuclock 8000000 //geht nicht //MIT umstellung der Fuse von 4 auf 8 Mhz init_rs232(4800,4800); void init_rs232(unsigned int baud0,unsigned int baud1) { baud0=cpuclock/((baud0*16L)-1); baud1=cpuclock/((baud1*16L)-1); //UART 0 INIT UBRR0H= (unsigned char)(baud0>>8); UBRR0L
alternativer keramischer Resonator wäre kaum billiger. Es ist somit doch völlig unsinnig, mit dem internen RC-Oszillator seine Zeit zu verplempern, sobald man den UART verwenden möchte. Auch irgendwelche sogenannten Baudratenquarze einzusetzen, ist doch Schnee von gestern. Ein Blick in die Baudratentabelle
-
Thread
STK500+Atmega640 -> UART funktioniert nicht
Schnittstelle verwendet. Folgende Dinge habe ich eingestellt: Habe beim STK500 eine Brücke von den Pins "RS232 Spare" (RX und TX) zum Mikrocontroller Port E (PE0 und PE1) gemacht. habe beim den Fusebits den internen Oszillator des Atmega640 auf 8Mhz gestellt, laut Datenblatt: CKSEL = 0010. Die Jumper
Kommen an den Ausgängen überhaupt keine Signale raus? Ansonsten: Dass der interne RC-Oszillator der AVRs für asynchrone serielle Übertragung aufgrund seiner Ungenauigkeit und Temperaturdrift eigentlich ungeeignet ist, ist ein Thema, das hier im Forum schon oft genug durchgekaut
-
Thread
Problem AM-Empfänger konstruieren
Senderprogramm ist für einen Tiny 26, und das Empfängerprogramm für einen ATmega8. Der Tiny läuft mit dem internen Takt, der Mega 8 mit einem externen Quarzoszi mit 4 MHz. Die RS232 funktioniert einwandfrei, es liegt wirklich nurnoch an der Funkgeschichte. Ich habe eben versucht das die beiden zusammen spielen
Hauptschleife für den Empfänger sollte so aussehen, das er die empfangenen Daten einfach nur an die RS232-Schnittstelle weitergibt, den auf dem PC wird das dann in einem eignen Programm entsprechend verarbeitet. Es braucht den Empfänger nur als Umsetzer zwischen Funk und RS232. Hast du auchmal über
-
Thread
löst das STK500 meine Probleme ?
STK500 kaufe, ist darauf dann alles schon aufgebaut und ich muss nur noch den IC aufstecken und die RS232 anschließen und es läuft? (wenn ich das programm auf den IC aufgespielt habe), ist der Quarz schon drauf? Ist das meine Lösung? Oder hat einer ein Board, auf dem das UART-beispiel vom Tutorial läuft
Was ist direkt an der Buchse, dan der das Kabel angesteckt wird? Wenn du das RS232 Kabel ansteckst, ist dann am anderen Ende das Flackern immer noch da? Ist es am richtigen Pin?
-
Thread
Software UART mit FIFO
einen Pin mit dieser Funktion kippen lasse. Könnte das schon ein Hinweis auf den sehr ungenauen internen Oszillator sein?
_ machen Danke für den Quellcode... kombiniert mit deinem Bootloader muss ich fast nie mehr den RS232 Stecker am STK 500 umstecken :)
-
Thread
Verständnisfrage Takt für UART mit einem Quarz
möchte mir bei einem Atmega8 die Möglichkeit offen halten irgendwann mal UART zu benutzen um über RS232 mit dem PC zu kommunizieren. So weit so gut, das sollte ja kein Problem sein, wenn man die Pins TXD (PD1) und RXD (PD0) freihält. Jetzt ist mir allerdings eine Frage zum Takt des Atmegas gekommen
Hans Guckindieluft schrieb im Beitrag #3768805: > den internen Quarz Das ist ein RC-Oszillator *KEIN* Quarz
-
Thread
Keine RS232 Kommunikation bei CPU-Taktraten über 4 MHz
Ich habe mal 2 Dateien angehängt. Fuse-Bits und meinen Quelltext. Die RS232 Konfiguration nutze ich schon seit jahren und hat bisher immer funktioniert. Aber wie gesagt, bisher bin ich auch immer mit 4 MHz ausgekommen. Vllt mach ichs mir ja doch zu einfach :)
begrenzt. Bei 4 MHz oder mehr irgendeinen Jitter am Systemtakt zu erkennen kann ich wohl vergessen. Die RS232-Signale kann ich mir aber mal angucken. Morgen :)
-
Thread
SOUNDRX - Datenübertragung/Bootloader PC -> µC über PC-Soundkarte
noch ne tolle Idee. Mann könnte dich einen SPI oder Jtag Programmer bauen der anstatt mit USB oder RS232 dann über die Soundkarte des Rechners läuft. Ich bekommme Die USB to RS232 dinger auch nicht wirklich zum laufen und das Notebook hatt leider keinen RS232 mehr.
TTL-Pegel ankommen. Nachteil: Du kannst die Übertragungsstrecke nicht so lang machen wie bei einer RS232.
-
Thread
Kommunikation zwischen 2 AVRs über einen Anschluss
. Ausserdem wird als Übertragunsverfahren Puls-Code-Modulation verwendet. Das hat gegenüber einem RS232 Protokoll den Vorteil, das die Taktfrequenzen der beiden Kontroller nicht so gut synchronisiert sein müssen. Das ist vor allen Dingen bei den internen RC-Oszillatoren wichtig. Meine grobe Schätzung
hagen) >Na da verbrauche ich aber lieber einen der vielen Timer und kann >nebenbei noch das SPI, die RS232, den ADC, die PWMs, die Ports, den >Analog Comparator, den EERPOM, FLASH, SRAM usw. benutzen. Und was machst Du bei einem Attiny13 ohne SPI, RS232 und mit nur 5 nutzbaren Portpins? > Hannes
-
Thread
Atmega Uart welcher AVR ?
Rs232 schrieb im Beitrag #2317041: > Welcher AVR hat dieses Problem nicht und eine ausreichende > Langzeitstabilität ohne externen Quarz ? keiner
Hi >Aber doch nicht die neueren !? RC-Oszillator bleibt RC-Oszillator. Was soll das Ganze? Hast du eine Quarzallergie? MfG Spess
-
Thread
USART Routine von ATMEL
>Den ATmega8 hast du auch umgestellt vom 1-MHz-RC-Oszillator auf >externen Takt, ja? ? Hab den internen Takt der STK 500 mit 3,86....
Matthias wrote: >>Den ATmega8 hast du auch umgestellt vom 1-MHz-RC-Oszillator auf >>externen Takt, ja? > ? Hab den internen Takt der STK 500 mit 3,86.... Woher weiß das aber dein ATmega8? Den interessiert das einfach gar nicht, was an seinem XTAL1 passiert, solange
-
Thread
AVR - Fusebits, externer Takt und das Tutorial...
Fuse-Bits unter "Clock Sources" erklärt, auch mit Schaltplan wie man einen Quarz und einen externen RC-Oszillator anschließt(Quarz mit Bürdekapazitäten an XTAL1 und XTAL2, Externer Oszillator nur an XTAL1). Gegen den internen RC spricht gar nichts, außer Du brauchst sehr stabile und genaue Takte für zeitgenaue Anwendungen oder Du willst schneller als 8MHz takten. Den internen Oszillator kann man kalibrieren, damit kriegt man ihm recht genau (auch siehe Datenblatt). Da weder i2c noch der PC-Parallelport zeitkritisch sind (im Gegensatz zu RS232) sollte das Timing für Deine
-
Thread
Reflektionen mit Oszi messen
ist und RS232 Transceiver verwendet werden, dürften eingefügte Serienwiderstände eigentlich nichts wesentlich ändern. Heutezutage verwendet man für solche Zwecke symmetrische, differentielle Signalübertragung
@Azubi: hat du Quarze für die Mikrocontroller verwendet, oder werden interne Oszillatoren benutzt ?
-
Thread
AtMegaL mit 14,7456MHz Quarz und XDIV
Nehm doch den internen Oszillator auf 8 MHz und trimm den auf deine 7,3728MHz. Mit einem Uhrenquarz am Timer0 und fortlaufender Nachregelung bleibt die Frequenz für RS232 genau genug. gruß hans
Mittels eine 32 kHz Uhrenquarzes den internen Oszillator trimmen ist nicht ungewöhnlich. Das wird unter anderem selber von Atmel auf dem Butterfly-Evalboard gemacht. Und es gibt auch entsprechende allgemeine App.-Notes von Atmel dazu http://atmel.com
-
Thread
UART - Beispiel aus dem Tutorial will einfach nicht laufen :-(
und die takterzeugung mit einem quarz funktioniert nicht! evtl. geht der avr dann zurück auf den internen takt, das weiss ich aber nicht. wenn du einen quarz verwendest stell sicher, dass der interne puffer des avr's auch aktiviert und der oszillator eingeschwungen ist. kann in den fuses mittels einschwingzeit
Ist der USB/RS232-Adpater direkt an die PortPins angeschlossen oder an die 9-pol. SubDBuchse? Wenn letzeres der Fall ist, müssen die beiden TXD und RXD(RS232 SPARE) über den LEDs mit den jeweiligen PortPins des Prozessors
-
Thread
ATmega328P UART in Assembler
Hi >Wo mag der Fehler liegen? Bei 1MHz Takt hast du bei 9600Bd schon 7% Fehler. Mit internem RC-Oszillator kann es noch mehr werden. Gehe mal auf 4800Bd runter. MfG Spess
Wenn das ein echter USB-RS232-Adapter ist, wird es in nahezu allen Fällen sowieso nicht funktionieren, weil die Pegel nicht zueinander passen. Bei den USB-RS232-Adaptern ist meist ein FT232R und ein MAX232 verbaut: (USB) |--[
-
Thread
LED Adressierung bei Buslängen > 10 m
Auf jeden Fall werde ich eine bitweise Synchronisierung brauchen, da die Controller mit ihren internen Oszillatoren bei schwankenden Temperaturen (evtl. auch als open-air Lichtkette) funktionieren sollen. Nur der Master bekommt einen Quarz. Tendieren tue ich zu b.), weils noch etwas einfacher zu
Hallo, Wie läuft die Kommunikation mit den Tinys? Ohne Quarz ist RS232 o.ä. sehr unzuverlässig. :) Was eventuell machbar wäre wenn man sich den Quarz unbedingt sparen will, daten im Manchestercode senden, der bringt den "Takt" gleich mit. Nachteil ist der große Datenoverhead
-
Thread
DMX Baudrate - Einstellungen und Datenpakete "debuggen"?
folgendes initialisiert: [c] void init_Timer(void) { //OSCCON MPU Frequenz SCS1 = 1; //1x internem Oszillator OSCCONbits.IRCF = 0b1111; //Bit 3-6 16Mhz //OPTION_REG Timer 0 0b0x0x0111 OPTION_REGbits.PS = 0b000; //Prescaler = 0b000=1:2, 0b001 = 1:4, 0b010 = 1:8, 0b011 = 1:16,...,0b111
Pegelanpassung an Schnittstelle nicht vergessen (MAX2323 etc). Vielleicht!!! funkteoniert das sogar mit dem internen Oszillator. Bevor so etwas "primitives" nicht läuft, brauchst du keine DMX-Routine testen.....
-
Thread
LCD 16x2 Problem
benütze oder? Halbwegs korrektes Timing kannst du bei der Einstellung aber nicht erwarten, da der interne Oszillator keine 3.7MHz hat.
Wo sollte der max232 sein? Meinst du bei RS232? Da ist nichts gesteckt.
-
Thread
UART- seltsamer Empfang
Mist. Woran kann das liegen? Kabellänge evtl? (ca 1 Meter) oder was sind sonst die stürprobleme bei RS232?
vertan, oder der µC-Takt stimmt nicht mit dem, was du zur Berechnung genommen hast. Kommt gern beim interne Oszillator vor... Ich denke das wird der Fehler sein...
-
Thread
Anbindung (seriell) Atmel an PC
ISP-Programmieradapter, welches auf der einen Seite Tx/Rx Anschluss vom µC und auf der anderen Seite ein RS232-Anschluss (9-Pol Sub D) besitzt ?? Das muss es doch irgendwo schon käuflich (<20 Euros) geben ! Ich habe bisher einen missglückten Selbstbauversuch gestartet, Schliesslich ist der Materialpreis
habe auch vor kurzem mit Mikrocontrollern angefangen, und letzte Woche an mein AtMega8-Board einen Max232 nebst serieller Schnittstelle nach der Schaltung aus dem Tutorial geloetet. Hat auf Anhieb funktioniert, obwohl ich in der ersten Version die Masseleitung an der RS232 vergessen hatte... er bekam die
-
Thread
RS232 Chip und ESD Problem
eventuell jemand sagen, was erfahrungsgemäß den Chip robuster > machen kann? Filter in allen Leitungen. RS232 hat üblicherweise keine hohe Baudrate. Also kann man überall R-C-Glieder oder noch besser LC-Glieder einsetzn. -> auf TTL-Seite, z.B. 470R...1k und 1...10nF -> auf RS232-Seite ähnlich -> In
gute Idee. Möglich, daß damit ein Latchup-Effekt vermieden wird. Mit den moderaten Baudraten einer RS232 auch kein Problem, z.B. SMAJ15 oder ähnlich einzusetzen. Aber RS232 ist nicht für hunderte Meter gedacht. Normal also nicht notwendig. Gruß Öletronika
-
Thread
stm32f103xB USB HID/VCP Fragen
Visual Basic .NET auf dem PC auswerten könnte (gibt es da )? Auf dem Board habe ich keinen externen Oszillator, benutzte in meinem Code den internen 8Mhz RC der via PLL auf 72MHz hoch getaktet wird. Ist USB Übertragung mit einem internen Oszillator möglich?
/www.embedded24.net Artata schrieb im Beitrag #3151101: > Ist USB > Übertragung mit einem internen Oszillator möglich? Möglich schon (die Silabs Controller können das), aber meistens ist für Full Speed USB ein externer Oszillator nötig.
-
Thread
Wer hilft mir weiter,damit ich das ambilight zu ende bekomme
Farbinformationen gewinnt und b) diese integriert oder was auch immer der damit macht. Das Ganze wird per RS232 an den Controller gesandt und der kümmert sich eigentlich nur noch um die Kommunikation mit dem Rechner und die PWM der einzelnen Leuchten...also kein großer Zauber. Was allerdings noch keiner
Problem. Wenn in deiner Brennschaltung ein Quarz werkelt, in deiner Anwendungsschaltung aber ein Oszillator, dann wird das so nichts werden. Denn für eines von beiden (Quarz oder Oszillator) musst du dich entscheiden. Sobald du dich aber für eines von beiden entschieden hast, geht das andere nicht mehr
-
Thread
max232 atmega8 + pc
> zu 3. sin doch nur zum glätten oder? Die Sind für die Ladungspumpen um die Spannungen für das RS232 zu erzeugen. Vllt erreicht eso nicht die nötigen Spannungen. > zu 4. ist einer drinnen mit 100nF bloß das bild ist abgeschnitten Sollte aber 1µF sein. > zu 5. sin bei der spannungsversorgung (nicht
hab ichirgendwie eine chance dass ich es so zum laufen bekomme? Ich würde mal vorschlagen den internen Oszillator als Taktquelle zu verwenden, und die Spannungen an den Pin 2 und Pin 6 des MAX's zu messen um zu sehen, ob die Pegel in Ordnung sein könnten. Dazu kommt noch ob du die Baudrate auch
-
Thread
RS232 mit Mega8 und Bascom
Projektchen" z.B. ein Fischertechnik-Interface Clone mit einem 2313 in Assembler möchte ich nun über die RS232 mit einem Mega8 über Bascom programmiert Daten austauschen. Ich habe die Fuse-Bits sauber gesetzt und er läuft schön "rund" mit 4Mhz. Mit dem folgenden Bascom Code funktioniert es leider nicht:
Hi, bis jetzt hatte ich noch keine Probleme mit dem internen RC bei 4Mhz und 9600 Baud. Du koenntest versuchen den Oszillator zukalibrieren , vielleicht hilft das. Insbesondere für hohe Datentransferraten solltest du auf einen ungeraden Quarz zurueckgreifen
-
Thread
STM32F4 ARM Platine - bitte ansehen
könnte man überlegen, ob die überhaupt benötigt werden. Insb. die 25 MHz. Die STM32 haben PLLs und interne Takte, die man zur Not mit dem externen 32 kHz abgleichen kann. USB wird, warum eigentlich, auch nicht vom Controller übernommen, sondern von einem FT232RL
warscheinlich bei den meisten Anwendungen sowieso den internen Oszillator verwenden. Nur dachte ich, ich sehe halt die beiden externen Oszillatoren einfach vor, falls ich doch mal eine genauere Frequenz brauche. USB hatte ich schon geschrieben: Ich möchte
-
Thread
Problem mit Atmega32 und LCD (HD44780 kompatibel)
könntest mal versuchen die Zeichen langsamer zu senden. > Wie mache ich das? Nun wenn Du keine RS232 etc. verwendest, so könntest Du z.B. in der "lcd-routines.h" eine falsche Taktfrequenz einstellen, und ggf. ebenso im Studio selbst. Wenn du 8 MHz verwendest, so z.B. 16000000 (bzw. 16000000UL
Compiler ohne UL Probleme macht) Wenn du bereits auf 16 MHz Quarz bist, so kannst Du ja auf internen RC-Oszillator umstellen, aber pass mit den Fuses gut auf - ich will danach NICHT "verfust" lesen müssen... Wenn es ein geringes Timing-Problem war, so müsstest Du danach sinnvolle Texte lesen
-
Thread
ATMEGA 644 System Clock <-> RS 232
.pdf Wenn das so ist hätte evtl. jemand ein kleines Beispiel in C zur Hand wie man den 644 für RS232 Initialisiert? Das währe nett. Danke Euch, Tommy
Baudratenfehler von 7%. Bei 8MHz sind es 0,2%. Allerdings sind das theoretische Werte. Die Frequenz des internen RC-Oszillators ist aber nicht sonderlich stabil, so das auch bei 8MHz mit größerren Fehlern zu rechnen ist. Für eine fehlerfreie RS232-Verbindung ist der interne RC-Oszillator ungeeignet. Nimm einfach
-
Thread
PIC liest Befehle über RS232 falsch ein
meine Projektarbeit an der FH programiere ich gerade einen PIC 16F876, welcher Kommandos über die RS232 Schnittstelle empfängt und entsprechend die Peripherie regelt. Der PIC ist an einem 13 MHz Oszillator angeschlossen, welcher auch für die restliche Hardware verwendet wird. Der Pegelwandler für RS232 ist ein MAX232. Mein Problem: Schicke ich beispielsweise das Wort "Hallo" an den PIC und lasse es zurücksenden, kommt "HX<1/2" (!/" als ein Symbol" zurück. Allerdings besteht das Problem nur in
-
Thread
Richtiger Bus bzw. dynamische Adressvergabe
einen TTL-Pegel überträgst. Aber so wie ich das einschätze, klappt das schon mit einem ordentlichen RS-232. 38,4 kBit ist noch nicht so abartig viel. Vielleicht wäre es hier auch sinnvoll, mal einen Testaufbau zu machen - zwei MAX232 über ein paar Meter Kabelrolle miteinander verbinden und schauen, wie
die du noch durchkriegst. Zum testen kannst du ja einen simplen Rechteckgenerator an den einen MAX232 hängen, und beim Empfänger schauen, wie das Rechtecksignal dann dort aussieht. Wenns mit dem MAX232 nicht geht, könnte man evtl noch einen MAX487 versuchen, der macht RS-485. Übrigens meine ich
-
Thread
Sporadische Aussetzer Serielle Kummunikation AVR
kann ich bestätigen. Ich hatte das gleiche Problem bei zwei Atmega 48 die ca. über 2 Meter per RS232 verbunden waren und im gleichen Raum. (auch gleiche Temperatur) Mit dem Internen 8 MHz Oszillator war die Sache nicht so toll stabil. Abhilfe: Entweder externer Quarz oder eine Art automatische
Fuses]] richtig gesetzt, sodass der Quarz verwendet wird? Sonst läuft der nämlich ggf. mit dem internen 8 MHz RC-Oszillator :-0 MfG Falk
-
Thread
Dringendes Problem mit UART+Baudrate.
Klemm man den Quarz ab, dann sollte gar nichts ankommen. Wenn doch was ankommt dann ist noch der interne RC-Oszillator mit 8 MHz aktiv. MfG Falk
auswirken, obwohl der µC gar nicht auf dem Board sitzt? Schließlich will ich das Board nur wegen der RS232-Schnittstelle missbrauchen. Gruß Matze
-
Artikel
AVR Checkliste
einen Quarz oder einen Oszillator verwenden, egal bei welcher Baudrate: 3% Fehler sind immer 3% Fehler, egal ob bei 1200 oder 9600 Baud. Falls doch der interne Oszillator verwendet wird: Wurde er für die richtige Frequenz und Betriebsspannung
Programmieradapter eingesteckt ist, deutet dies auf ein Problem mit der Masse hin (z. B. GND-Anschluss am RS232-Stecker nicht belegt oder dergleichen). Der Pegelwandler/Inverter (z. B. MAX232) muss mit Kondensatoren für die internen Ladungspumpen beschaltet werden. Beim MAX232 sind dies mindestens vier Kondensatoren
-
Thread
uart interface pic18
Du hast keine stabile Taktquelle. Der interne Oszillator ist keine! Dieser PIC kann USB ohne Quarz, aber dann dient USB als stabile Taktquelle. USB ist hier nicht konfiguriert, also ist auch von dieser Richtung aus Fehlanzeige. Schließe
Yo, sehe ich auch so. Interner Oszillator läuft auf 1MHz per default ... Kein Problem mit 115200 bei mir wenn man den Oszillator über das OSCCON vernünftig einstellt. Vergiss den externen vorerst mal ! #include <p18cxxx.h
-
Thread
Beispielprogramm für RFM12 433MHz Funk-Module
Schau mal hier: http://www.mikrocontroller.net/attachment/24996/rfm12_rs232_rxtx_check_int.zip
@benedikt, vielen dank für die schnelle antwort. zählt rfm12_rs232_rxtx_check_int.zip auch zu den neuen, wie auch die im beitrag funkbrücke!? in dem angehängten code aus dem beitrag: bidirektionale RS232 Funkbrücke mit RFM12 sind ebenfalls schaltpläne, dort
-
Thread
K0855 durch Mikrocontroller ersetzen?
oder USB-Softwareroutinen auf einem AVR einrichten. Andere attraktive Kommunikationswege könnten über RS232 Funkkommunikation oder TCP/IP oder... gehen. Viele Robotprojekte mit AVRs könnten dir hier Anregung geben.
Lzaman wrote: > Datenblatt jetzt vorhanden, wollte aber gerne wissen ob der Atmega16 > einen internen Quarz intergriert hat oder muss ich einen externen dazu > schalten? Quarz nicht. Einen RC-Oszillator. Wenn du Datenübertragung nach aussen machst, zb über RS232, wirst du mit dem RC-Oszillator
-
Thread
Projekt für den NXP 8051 "Mischanlage" in Planung
LED-Anzeigen Auf Port2, RxD, TxD, SDA und SCL (I²C-Schnittstelle) 1 Taste mit Interrupt USB <-> RS232 Converter (FT232R) XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Für mich sind ja normale Ein / Ausgänge wichtig und ein Analog eingang für den Poti. Wenn Display
Geschwindigkeit und Quelle, mit welcher der RTC getaktet wird. In Verbindung mit RCCLK=1 und FOSC[2:0]=011 (interner RC Oszillator) ergibt sich, dass der RTC vom RC Oszillator den Takt bekommt (7,3728 MHz). Dieser wird nun durch den 7Bit Vorteiler des RTC geschickt, wodurch der neue Takt 57600 Hz beträgt. Bei einem
-
Thread
Bascom Bootloader Atmega32 plu Fusebits
roboternetz.de runtergeladen, bei dem soll es auch möglich sein den per Funk zu programmieren über RS232. Funk ist mir nicht wichtig, Allerding kann ich mit diesem nicht über RS232 programmieren. Mein Programm läuft, und ich kann mich auch per RS232 mit dem Board die Ausgaben sehen, aber wenn ich
fotoforum/avr/flashen/flashserial.jpg Und wie gesagt ich kann mir in dem terminal von Bascom die RS232 Ausgaben von dem Testprogramm das ich drauf habe ansehen: http://www.fam-markus.de/fotoforum/avr/flashen/rs232.jpg