-
Thread
[2560 und FTDI-seriell]Kommunikation fehlerhaft
11001100101100011010000011 x x Ich tippe auf falsche Baudrate oder Invertierung, evtl. läuft der interne RC-Oszillator und der Calibration-Wert stimmt nicht. Sende mal ein paar 100 Buchstaben und stoppe die Zeit, wie lange das dauert. Ein Soundkarten-Oszilloskop oder billigst-LA kann das Problem
brauchen die komplette Software. Was läuft im Hintergrund? Der atMega2560 hat doch 4 Hardware-Uarts.
-
Thread
ATmega328PB nach Berührung Flash kaputt
Der Umstieg auf den internen Oszillator ist bei diesem Produkt leider nicht möglich, da ich die 16MHz brauche. BrownOut Detection ist an (1.8 oder 2.7V, bin gerade nicht sicher) Der Inhalt des Flashes ist zerstört und lässt
Poste mal den Schaltplan und die Layoutfiles. Ich vermute du hast einen PortPin an Masse und interne PullUps an.
-
Thread
SID-Player ARM/FPGA?
meines kleinen Tests ... Die 168MHz sind ungenügend und der STM32F429 mit 1MB Flash und 192kB (internes) RAM ist zu klein. (Evtl mit dem STM32H7 nochmal testen ... Der hätte 400Mhz ist aber noch nicht erhältlich, aber den gibt es dann auch im TQFP144!) Die Wave-Tables müssen im internen RAM liegen
als wenn die allerlei Tricks verwenden. Normalerweise erzeugt man die Klänge des SID mit seinen internen 3 Oszillatoren. Es gibt auch Programme, die einfach alle 20-50ms die Registerwerte für den SID mitschreiben. Damit kann man später den SID offline ( also ohne 6510 Emulation ) spielen, indem man einfach
-
Thread
Uart Baudrate
FOSC 8000000 #define BAUD_UART 9600 #define UBBR_UART (FOSC/ (16*BAUD_UART))-1 void setup(void); volatile unsigned int senduart = 0; int main(void) { setup(); sei(); /* enable Interrupt */ while (
IO-Frequenz und > Baudrate. Weil die IO-Frequenz nicht konstant ist. AVR wird mit einem für UART Betrieb etwas zu ungenauen internem Oszillator ausgeliefert, den man erst per Fuse auf Quarz (so vorhanden) umstellen muss.
-
Thread
ATMega32-16PU für die Arduino IDE vorbereiten und benutzen
mit einem Quarz getaktet wird. Was bei Arduino üblich ist. Im Lieferzustand wird er über einen internen 8Mhz R/C Oszillator getaktet, dessen Frequnez durch 8 geteilt wird. Für serielle UART Kommunikation (also den Arduino Bootloader) ist das nur notdürftig geegnet. Also ja, schließe einen Quarz an
eine bessere Taktquelle erfordert, als den internen R/C Oszillator. Zumindest wenn es zuverlässig gehen soll. AVR Mikrocontroller werden normalerweise ohne Bootloader verkauft. Die Arduino IDE unterstützt beide Methoden, UART mit Bootloader und
-
Thread
STM32F401 Initialisirung USART2 bare metal
Noch eine Verständnisfrage: Wenn ich UART2 ohne Flusskontrolle benutze, sind dann die Pins CTS (Pin A0) und RTS trotzdem belegt und können nicht mehr von z.B. Timer2 input capture (Pin A0) belegt werden? UART2 läuft, wenn ich aber die Clock
Ich habe gelesen, dass der interne Oszillator mit bis zu ±3% Abweichung behaftet ist, und messe mit SysTick an Stelle von eingestellten 2ms 1,9757ms, also eine Abweichung von 1,2%. Das ist also in Ordnung. Was mich aber wundert ist
-
Thread
vom Layout zum Schaltplan
. Den externen Quarz kannst du dir sparen. Lt. Datenblatt ist er nicht mal nötig, wenn man mit UART rummacht, der interne 8MHz Oszillator sei selbst dafür genau genug. RB0 kann als Interrupt benutzt werden, ist also genau richtig am 'Wasser-vorhanden' Sensor.
> Den externen Quarz kannst du dir sparen. Lt. Datenblatt ist er nicht mal > nötig, wenn man mit UART rummacht, der interne 8MHz Oszillator sei > selbst dafür genau genug. wenn ich das richtig erkannt habe, ist der ext. Quarz auch 8 Mhz (Aufschrift 8.000) Was bringt das dann überhaupt, wenn der
-
Thread
FPGA IoT Maker Board
notwendigen 3,3V für die Komponenten des Boards. Der Takt für FPGA und USB-Bridge wird von einem MEMS-[Oszillator](/articles/Oszillator) erzeugt. Die weitere Ausstattung des Boards umfasst einen 3-Achsen-MEMS-[Beschleunigungssensor](/articles/Beschleunigungssensor), 8 [LED](/articles/LED)s und zwei Taster.
PC geht es dann mit GNU Radio weiter. Schön wäre es natürlich wenn der FT2232H dazu nicht nur als UART (bis 12 MBaud) angebunden ist.
-
Thread
Messdatenaufnahme mit ATTINY 45/85
begin r:=(eing div e); val:='0'+r; // spart 2 Byte Soft_UART_Write(val); eing:=eing - r*e; e:=e div 10; end; Soft_UART_Write(';'); end; als anhang der quellcode
UART (egal, ob HW oder SW) und interner Oszillator ist eine wackelige Angelegenheit. Funktioniert nur zuverlässig, mit konstanter Betriebsspannung, Temperatur und Oszillator-Kalibrierung. Würde, wenn wie
-
Thread
Ein Code, mehrere Controller.
oder? Dein Problem liegt nicht in hochzählen, sondern in deinem Programm. Max. möglicher Fehler mit internem Oszi beträgt 10%. Dein Fehler ist *viiiiieeeeeel* grosser. Willst du "deinen" Code endlich posten oder nicht ?
was es hier noch über die Ursache zu rätseln gibt - dachte, es wäre längst klar, daß der unpräzise interne Oszillator des Tiny für die Abweichungen verantwortlich ist. Knapp 4% reale Abweichung für einen Oszillator, der unkalibriert +/- 10% haben kann, ist doch auch plausibel, oder?
-
Thread
Atxmega startet nicht korrekt
Robert schrieb im Beitrag #4929441: > Wenn es keine ultrahohen UART-Frequenzen werden sollen ist auch der > interne Takt beim Xmega für diesen Zweck hinreichend stabil. Die prozentuale Abweichung ist unabhängig von der absoluten Geschwindigkeit. 5% Fehler sind sowohl
Lothar M. schrieb im Beitrag #4931074: > Robert schrieb: > Wenn es keine ultrahohen UART-Frequenzen werden sollen ist auch der > interne Takt beim Xmega für diesen Zweck hinreichend stabil. > > Die prozentuale Abweichung ist unabhängig von der absoluten > Geschwindigkeit. 5% Fehler
-
Thread
Empfindlichkeit von Quarzoszillatoren
fast immer recht grob daneben, einfach weil man bei der Auslegung weder die Kapazität der Pins des internen Oszillators kennt, noch die des Layouts. Bei Standardanwendungen wie Ethernet, UART oder USB sind <65ppm Fehler natürlich egal. Aber wenn man die 10ppm herausholen will, kommt man um Finetuning
WLAN-Modul höchstwahrscheinlich für den RF-Teil und das SDIO verwendet. > - Selbst wenn der Oszillator anläuft, kann durch falsche Kapazitätswahl > der Oszillator später wieder stoppen oder falsch laufen? Ja, wäre möglich. Ein weiterer möglicher Fehler wäre zu hohes oder zu niedriges Spannungsniveau
-
Thread
Qualität bei Microchip's dsPIC33
PLL's ganz leicht verstellt. Microchip First-Level-Support: Hat 2 PICs zusammengehängt, beide mit internem RC-Oszillator (!) und hat gemeint, dass es ja eh geht. Ja eh - zufällig. Ich hab's dann aufgegeben, wollt' nicht unhöflich werden. Grüsse, Gernot
in wievielen Automotive-Produkten mit PICs dieses Problem übersehen wurde. Und weil ich nur den internen RC-Oszillator verwendet habe (PCB-Size), habe ich die LIN-Baud-Sync-Funktion der UART verwendet. Die hat natürlich auch einen Bug und ich hab einen zusätzlichen Flanken-Interrupt einbauen müssen.
-
Thread
AVR: Debug-Ausgabe fehlt
mit Eclipse, was auch soweit funktioniert. Allerdings bekomme ich keine serielle Ausgabe über UART hin. Der Code wird fehler- und warnungsfrei übersetzt, ich habe einen MAX3232 an /dev/ttyS0. Wenn ich RX und TX verbinde (loopback) dann kann ich vom PC z.B. eine Datei senden und sehe die LEDs auf
als taktgeber. Da sind die nominell 8MHz auch ziemlich genau 8 MHz. Was beim internen RC-Oszillator nun mal nicht der Fall ist.
-
Thread
FPGA auf Microcontroller synchronisieren
Du brauchst die 4MHz µC im FPGA, vergiss den 30-40MHz Oszillator am FPGA erst einmal für dein Problem...
hinweg nicht mehr als +/-200ps auf. Ich war Gedanklich beim Delay und nicht mein Jitter (Mein Fehler)
-
Thread
alte Videosignale an VGA anpassen
in C ermöglichen. Wenn allerdings kein solcher Quarz aufzutreiben ist und man deshalb mit dem internen RC-Oszillator arbeiten muss, wird man den (zuverlässig) wohl höchstens auf Pixeltakt*3 hochzwirbeln können. Dann würde es für ein komplette Implementierung in C wohl schon deutlich zu eng werden.
waflija schrieb im Beitrag #4875576: > wahrscheinlich im Gegensatz zu dir Fehler
-
Thread
ATMEGA644 defekt?
Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Das Programm nicht aber mein Blinky. Allerdings ist auch die Srromaufnahmexdes Boards gesunken was heisst das der
Marco G. schrieb im Beitrag #4869519: > Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. > Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Statische Überspannungen, Produktionsfehler, ...
-
Thread
ATMEGA328P-PU: USART sendet ungültige Zeichen bei 8MHz, funktioniert aber bei 1 MHz
Problem, bei dem ich nicht mehr weiterweiß... Die Fusebits sind so gesetzt, dass der µC auf dem internen RC Oszillator läuft, bzw. laufen sollte: FUSES = -U lfuse:w:0xE2:m -U hfuse:w:0xd9:m Leider bekomme ich auf meinem Serial-Terminal nur Fragezeichen, egal welche Baudrate ich beiderseits eingestellt
Klaus V. schrieb im Beitrag #4863978: > Ich bin dankbar für jeden Versuch mir zu helfen! Der interne Oszillator ist warscheinlich nicht genau genug um die Baudrate ausreichend korrekt zu erzeugen. Du wirst womöglich auf längere Sicht einen Quarz verwenden müssen. Klaus V. schrieb im Beitrag
-
Thread
Statemachine springt in falsche "states" warum?
Diesen Teil habe ich kopiert. Diese Componente scheint von Lattice vorgegeben zu sein und den internen RC Oszillator zu steuern. (In diesem Fall 17.73MHz). .pdf Seite 29 unten [vhdl] COMPONENT OSCH -- synthesis translate_off GENERIC (NOM_FREQ: string := "2.56"); -- synthesis translate_on PORT
vorletzte FF (in der Kette) den von Dir gewünschten (Reset-) Pegel "sehen" dann lasse dies dein interner Reset sein... dann solltest Du Dir erst einmal sicher sein können, dass Du Dir über den Pin (deines Versuchaufbaus) keine Fehler einfängst...
-
Thread
Was kann man mit 16Byte an RAM machen?
beschränkten Ressourcen auch eine Software-I2C Lösung implementieren >> ließe? > Mann kann! Naja, für UART und I2C braucht man in der Regel noch einen Datenpuffer und dafür ist bei 16Byte einfach kein Platz mehr. Für die UART nehme ich mindestens je 30 Byte Sende-/Empfangspuffer, damit man kürzere Texte
aber auch nicht sparen, ein paar pins als Reserve schaden auch nicht. Etwa wenn man merkt, dass der interne Oszillator doch nicht genau genug ist und man, entgegen der Planung, doch einen Quarz braucht. Oder man hat noch irgendwas andres vergessen. Auch bei Serienfertigung: Neuere Firmwareversionen sind
-
Thread
PROM lesen /schreiben / Programmiergerät
Wireless_Tx_Service_Manual.pdf "U2: Komplexer PLL-Baustein. Integriert sind: Referenz- oszillator,programmierbare Referenz- und Hauptteiler, ein analoger und ein digitaler Phasenvergleicher, Phasenmodulator und ein Controller zur Steuerung der internen und externen Abläufe (z.B
Hier beginnt der Rechenteil freq := Form1.FR_Input.IntValue*1000; n2 := 0; n1 := 0; n0 := 0; fehler := false; repeat n2 := n2 + 1; tz1 := (128*n2+n1)*128+n0; ergebniss := OVR*tz1-freq; Until sign(ergebniss)<> -1; n2:=n2-1; if n2 >127 then fehler := true else fehler := false; repeat
-
Thread
STM32F103 ohne Quartz und Mbed
In der Timer Implementierung für den F103 hatte ich auch schon vergeblich Fehler gesucht. Ich habe das IRMP für mbed portiert und auf dem F103 lief das nicht wegen des Timerfehlers. In der aktuellen mbed Version wurde der Timer überarbeitet und sah besser aus, ist aber vielleicht
Wie schon in anderen Threads geschreiben: One-Wire geht auch mit Uart oder 2-Kanaltimer und braucht dann kein delay() sondern erzeugt die One-Wire Primitive hardwaremaessig. Da One-Wire recht tolerant im Timing ist, sollte es auch mit dem internen RC Oszillator gehen.
-
Thread
Interrupt Frage ATMEGA8535
kämest du damit auf genau 16 Hz Ticker, was mich zu der Annahme verleitet, das dein Mega mit dem internen Oszillator läuft und damit nicht mit dem externen 16MHz Quarz, sondern mit den 1MHz des Auslieferzustandes. Um das zu ändern, setzt du die Fuses auf den externen High Frequency Crystal Modus (CKOPT
Aufrufe von _delay_ms() das richtige Ergebnis bringen. Für eine gut gehende Uhr ist übrigens der interne RC Oszillator viel zu ungenau. Wenn es dir darauf aber nicht ankommt, geht der RC aber.
-
Thread
Neue 8-Bit Tinys vorgestellt: 417/814/816/817 Gesperrt
Ich habe mich schon so daran gewöhnt, dass ich es vergessen habe: interner 20MHz Oszillator.
schrieb im Beitrag #5945383: > Ich habe mich schon so daran gewöhnt, dass ich es vergessen habe: > interner 20MHz Oszillator... der vor allem jetzt auch hinreichend genau für die meisten UART Anwendungen ist!
-
Thread
PIC24FJ256GB406 oscillator Auswahl
electrical characteristics) auch beachten. Aber in fast allen Fällen braucht dein PIC gar keinen MHz-Oszillator: Dein PIC hat self tuning für den FRC. Dessen FRC (interner RC-Oszillator) kann mittels Uhrenquarz auf 0,05% getrimmt werden. Du kannst also statt einem MHz-Quarz auch einfach einen Uhrenquarz an
, schlichtweg falsch gesetzte CLKDIV. Na gut, 0.05% Genauigkeit sagst du, reicht mir das für UART aus?
-
Thread
serielle Schnittstelle ATMega8 | TeraTerm | falsche Zeichenübertragung
Controller auch wirklich mit 1MHz? Hast du einen Quarz > dran? > > Sascha Er lief mit den internen 1Mhz, hier lag wohl auch der Fehler... nun mit 8Mhz externem Quarz funktioniert die Kommunikation. holger schrieb im Beitrag #4782907: >>Höchstwahrscheinlich sendet dein uC mit 19200B. > >
Markus E. schrieb im Beitrag #4782912: > Er lief mit den internen 1Mhz, hier lag wohl auch der Fehler... nun mit > 8Mhz externem Quarz funktioniert die Kommunikation. Schön dass du ein Feedback auf unsere Lösungsvorschläge bringst. Muss mal gesagt werden da
-
Thread
RS485 mit atmega und 1 Mhz takt
jetzt lies mal nach wieviel Abweichung der interne RC Oszillator so hat.
Weniger als 2400 geht sicher auch. Allerdings kannst du dich nicht darauf verlassen, dass der interne R/C Oszillator seine Soll-Frequenz langfristig genau genug einhält. Für Experimente reicht es meist, aber verkaufen soll man so etwas nicht.
-
Thread
ATTiny85 - Software UART Probleme
wählbarer Wert, sondern ein Konstante, die der echten CPU-Taktfrequenz entsprechen soll/muß. Mit internem RC-Oszillator und (ab Werk gesetzter) DIV8-Fuse, läuft der Tiny85 mit knapp unter 1MHz. Das ist der richtige Wert für F_CPU.
Carl D. schrieb im Beitrag #4741732: > Mit internem RC-Oszillator und (ab Werk gesetzter) DIV8-Fuse, läuft der > Tiny85 mit knapp unter 1MHz. Das ist der richtige Wert für F_CPU. Stimmt, im Datenblatt steht: "The device is shipped with CKSEL
-
Thread
internen RC Osci syncronisieren
hatte es so verstanden, dass es primär um den Austausch serieller Daten geht und das nur mit dem internen Oszillator. Die OSCCAL-Geschichte nur mittel zum Zweck. Veit D. schrieb im Beitrag #4727302: > Wenn man zum Bsp. 2 > ATtinys mit internen RC aufeinander loslässt und die sollen sich erstmal
002.cpp * * Created: 03.10.2016 20:50:04 * Author: Devil-Elec * µC : ATtiny841 mit internen 8MHz Oszillator * * Interrupt-Vector Namen Übersicht: * C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\avr\iotn841.h */ #include <avr/io.h> #include
-
Thread
Stromverbrauch ATmega168P
den ATmega168P im Einsatz, den ich in verschiedenen Modi betreibe: * ständig aktiv mit 8MHz aus internem RC-Oszillator; * ständig im Power-Down: Verbrauch bei 3V ca. 1µA; * im Idel-Mode mit 250kHz (aus 8MHz) bei 3V und alle 2ms kurz aktiv (durch Interrupt), hier messe ich im Idel-Mode ca. 140µA und
Current vs. Low Frequency > (0.1-1.0MHz)" ), Das ist aber für Quarz/Resonator, nicht für RC-Oszillator 8MHz/32. Kann gut sein, der 8MHz Oszillator verbraucht die 120µA. Setz dochmal den Teiler auf 256, ob sich da noch was verringert.
-
Thread
Atmega8, DCF an Interrupt. Ungültige Signaldauer mit externem Quarz
einem Atmega8 anzusteuern und mir die Zeit korrekt ausgeben zu lassen. Im leichtesten Fall mittels UART. In diesem Fall läuft der Controller mit dem internen RC-Oszillator auf 4 MHz. Das Signal vom DCF Modul wird an Pin4 mit einem Interrupt getriggert. Beispielhafte Debugausgabe im UART (Zahlen sind
Analyzer (z.B. einen Slaeae Clone mit freier Software Sigrok für <8€ (oder 17€ Prime)) und finde den Fehler mit Leichtigkeit. Ein Pin an die UART, ein Pin an das DCF Signal und lasse Dir durch die integrierten Decoder beide Signale in Klartext(!) anzeigen, wo es schiefgeht. Vermutung sind kurze Spikes im
-
Thread
UART Studienarbeit dringend :D
UART Studienarbeit schrieb im Beitrag #4721226: > also ich kann den mega32 nicht mit dem internen 8Mhz und > 115200baud > laufen lassen? Und nochmal: Schaue dir das Timing an. Von beiden! Vergleiche
arbeiten, z.B. 38400, da beträgt der Baudratenfehler > nur 0,2% bei 8MHz, beim 7.3728MHz-Quarz ist der Fehler 0%. Nee, sorry, vergiss es, du nimmst ja den internen RC-Oszillator, hab ich gerade erst gesehen. Der ist wahrscheinlich zu ungenau. Das mit der niedrigeren BR wird auch nur dann funktionieren,
-
Thread
ATMega8 USART
spess53 schrieb im Beitrag #4724889: > Kommt der Takt immer noch vom internen RC-Oszillator? > > MfG Spess Ja. Du meinst das ist der Fehler ? Ich habe noch ein 32768 Hz Quartz und ein 1MHz Quartzoszillator da. Nebenfrage: Ungern würde ich die Fuses umstellen.
Hi >Ja. Du meinst das ist der Fehler ? Ja das halte ich für sehr wahrscheinlich. Der interne RC-Oszillator ist nicht sonderlich Frequenzgenau und außerdem Temperatur- und Versorgungsspannungsabhängig. Kannst du mit deinem Programmer
-
Thread
UART/USART Echo
der Host auf 9600 Baud steht. Wenn du aus Versehen mit dem internen Oszillator arbeitest, sollte es bei UBRR0L = 0d51 laufen.
sicher, das auch der Host auf 9600 Baud steht. > Wenn du aus Versehen mit dem internen Oszillator arbeitest, sollte es > bei UBRR0L = 0d51 laufen. Also ich verwende Arduino Uno. Sorry für die Frage (ich bin ein Anfänger), aber ich verstehe nicht was mit dem Fuses gemeint ist. Wie
-
Thread
Output expander (1 Pin zur Verfügung)
schrieb im Beitrag #4707339: >> Bei mir wäre der Portexpander-µC wohl ein STM32F030F4, > > - der interne Oszi ist für einen UART zu ungenau -> extra Quarz oder > Resonator notwendig, das stimmt so nicht. Der interne Oszillator HSI ist 8MHz und auf 1% (bei 25°C) genau. Das reicht für langsamere UART-Übertragung
Gerd E. schrieb im Beitrag #4707351: > das stimmt so nicht. Der interne Oszillator HSI ist 8MHz und auf 1% (bei > 25°C) genau. Das reicht für langsamere UART-Übertragung mit z.B. 19200 > Bps vollkommen aus. Das eine Prozent gilt aber lt. Datenblatt nur für "with
-
Thread
Arduino Zeitmessung mit externes Modul das ms messen kann?
Mein Arduino Micro tickt mit Quarz. Also kann man den internen Systemticker des Betriebssystems verwenden.
Gibt einen 16 MHz Quarz. Jedoch ist er trotzdem nicht sehr > genau Was hat er denn? 100ppm Fehler? Wow, das geht natürlich nicht, das sind nämlich satte 0,01% Fehler. Unbrauchbar. Damit wollte ich nicht einmal das Eierkochen timen!
-
Thread
Umstiegsbreatung uC Atmel/STM
hoch multipliziert. Das Layout des Quarzes ist kein großes Problem. Man kann ja auch (Keramik) Oszillatoren nehmen, da kann man noch weniger falsch machen. Wenn man keine asynchronen Interfaces (UART, CAN) verwendet reicht evtl. auch der interne Oszillator. Ich würde aber nicht mit einem F1 anfangen
> die Umschaltung vom internen Oszillator auf den 8 MHz Quarz > haben wir bisher nicht hinbekommen Habt ihr keinen Techniker im Unternehmen?
-
Thread
Uart Problem mit ATMega8a
Schließ einen richtigen Quarz an, der interne Oszillator ist für UART nicht geeignet
man U2X erst gesetzt und dann wieder zurückgesetzt hat. Probiere mal das angehängte HEX mit internem Oszillator, 1MHz und 9600B.
-
Thread
STM32F030F4P6 und USART1
keine Zeit, deinen Code genauer zu studieren, aber im Anhang findest du mal eine funktionierende UART-Init etc. Das ganze basiert auf der UART-Lib von hier: http://mikrocontroller.bplaced.net/wordpress/ Ich hab das notwendige einigermaßen angepasst auf den STM32F0 Inhalt der main(): [c] UB_Uart_Init(); uart_puts(COM1, "Hallo UART!", CRLF); [/c] lg Chris
-
Thread
Welcher µC ist einfach zu programmieren
Lothar schrieb im Beitrag #4653891: > Bitte was? Die haben mehrere interne Oszillatoren z.B. die 72 MHz > Version eben 72 MHz und 50 MHz und 80 kHz die man im Programm umschalten > kann - also nichts mit verfusen. EFM8 mit USB haben einen 48 MHz > internen präzisen Oszillator
#4654604: > CAN beispielsweise überträgt ca. 130 Bit in einem Frame, da werden 2% > garantiert zum Fehler führen wenn man z.B 8x 0x00 im Datenpaket > überträgt Wie gesagt daher haben die Silabs 8051 mit CAN auch einen +/- 0.5% internen Oszillator.
-
Thread
Das Ende von 8bit?
braucht sich mit den Details erstmal nicht rumschlagen, sondern erst, wenn durch die Abstraktion Fehler entstanden sind.
wegen der Rechenleistung, 8051 wegen für ARM nicht verfügbarer Peripherie z.B. analog oder USB mit internem Oszillator. Bei ARM ist M3 meist der Vorzug vor M0 zu geben, bei gleichem Takt deutlich schneller zum praktisch selben Preis.
-
Thread
ADC Board für Trenz Electronic FPGA Modul
erzeugen und messen. Wenn immer noch Fehler auftreten, liegen diese zwischen FPGA, USB und PC, wenn nicht, zwischen Bus und FPGA. Da die Fehler scheinbar immer den Pixelwert 0 haben, sieht das nach Timingproblemen an einer Schnittstelle aus,
Muster erzeugen und messen. Wenn immer noch Fehler > auftreten, liegen diese zwischen FPGA, USB und PC, wenn nicht, zwischen > Bus und FPGA. Da die Fehler scheinbar immer den Pixelwert 0 haben, sieht > das nach Timingproblemen an einer Schnittstelle
-
Thread
AVR Prozessortakt halbieren
µC dann automatisch auf seinen internen Oszillator um? Wenn nicht, könnte mir bitte jemand helfen auf den internen Oszillator umzuschalten?
Soweit mir bekannt haben die Atmels nur einen Teiler 1:1 oder 1:8 zwischen internem Oszillator und der sonstigen Interna. Wenn der interne Oszillator 8 MHz hat, kommen nur 8 oder 1 MHz infrage. Wenn ich den TO richtig verstanden habe, soll der µP mit 4 MHz laufen. Zumindest mit
-
Thread
ATtiny841 - Quarz notwendig wenn UART benutzt?
Hallo, eigentlich wollte ich vom ATtiny841 den internen Oszillator verwenden. Nun habe ich im Wiki gelesen, dass man einen externen Quarz nehmen soll, wenn man die UART verwendet. Wegen Baudratenfehlern. Nur hat doch der 841er einen stabilisierten internen
zum Stopbit) voneinander zeitlich entfernt haben. Summa summarum, normalerweise genügt der interne RC-Oszillator der AVRs für UART, aber es ist eben nicht über den Temperaturbereich und über Exemplarstreuungen garantiert.
-
Thread
Atmega8 und I2C-Display startet nicht
SDA) --> PCF8574 SDA --> TC2004-LCD Atmgea Pin28(PC5/SCL) --> PCF8574 SCL --> TC2004-LCD Die internen Pullups für PC4 und PC5 sind an. Den Programmer über ISP. Dazu noch Grundbeschaltung mit Kondensatoren und 5V-Spannungsregler. Hab nach jedem Senden eines I2C-Pakets eine Ausgabe auf den UART
angestellt Dazu muss man nur das Datenblatt des Mega8 lesen. Dann sieht man schnell, das der interne Oszillator auf 1, 2, 4 oder 8 MHz gefused kann. Armin R. schrieb im Beitrag #4597056: > Die internen Pullups für PC4 und PC5 sind an. Wie oben angemerkt, reicht das für den I²C Betrieb nicht
-
Thread
ATMEL (Microchip) erhöht die Preise
Jörg W. schrieb im Beitrag #4590960: > Erst, wenn man auf die Idee kommt, dass der interne 128-kHz-RC-Oszi > wohl zugleich der Watchdog-Oszillator ist Datenblatt Seite 3. Und wenn man einen Watchdog-Reset so knapp einstellt, daß 10% Abweichung ihn schon aushebeln, sollte man vielleicht
#4591000: > Jörg W. schrieb im Beitrag #4590960: >> Erst, wenn man auf die Idee kommt, dass der interne 128-kHz-RC-Oszi >> wohl zugleich der Watchdog-Oszillator ist > > Datenblatt Seite 3. Meinst du den kleinen, unscheinbaren Pfeil vom Watchdog-Oszillator in die Taktversorgung? Ehrlich,
-
Thread
RS485 Interface
des Masters (PC). Ergeben sich da Unterschiede, weisst Du, wo Du weitersuchen musst. Beliebter Fehler ist z.B., den Prescaler-Timer des Uarts mit dem Prescale-Faktor und nicht mit dem Prescale-Faktor - 1 zu beschreiben ...
sind zwar eine Menge Inits, aber welche benutzt du denn jetzt? 'Clock_Init' bspw. startet den internen 32MHz RC Oszillator. 'PLL_Init' basiert derzeit auch auf dem 32MHz RC Osz. Nur 'exClock_Init' scheint das richtige zu sein (ohne jetzt durch die Details zu gehen).
-
Thread
AVR Uart Problem
Eine Hardware die UART verwendet ohne einen Quarz oder Quarzoszillator, sprich sich auf den internen RC-Oszillator verlässt, ist, ohne weitere Software für einen laufende Kalibrierung, eine Fehlentwicklung. Dafür spricht
einmalige Kalibrierung wird Dir nicht helfen. Mit der Änderung der > Temperatur läuft Dir der RC-Oszillator wieder weg. ATMEL sagt, dass der interne RC-Oszillator max. +-10% Fehler hat. Damit der Empfang (so wie der Tiny2313 abtastet) einigermassen klappt, darf der Fehler aber nicht größer als