-
Thread
Probleme beim Debuggen mit SW4STM32 und und F7Disco
> Wenn ein leeres Projekt mit minimalem Blink-Code auf einem ST-Board > nicht läuft, ist der Fehler wohl eher in der Hardware zu suchen. Davon gehe ich aus. Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob die Problemursache beim Oszillator liegt. > Oder willst du
Stefanus F. schrieb im Beitrag #5618595: > Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob > die Problemursache beim Oszillator liegt. Sollte dann aber nicht eigentlich nichts funktionieren, wenn der Fehler da läge? Ich bin immer noch
-
Thread
STM32F103: bei UART1 remapped funktioniert der UART1 Interrupt nicht
auf der Platine zu finden. Laut diesem Post, sollte der Prozessor dann aber automatisch den internen Oszillator nehmen? https://www.mikrocontroller.net/topic/424084#4958849 Gruß hochsitzcola
schrieb im Beitrag #5616007: > Laut diesem Post, sollte der Prozessor dann aber automatisch den > internen Oszillator nehmen? Die Hardware enthält keinen Automatismus. Das müsste man ausdrücklich in Software implementieren.
-
Thread
Padauk MCU für 0.038 USD aus Taiwan
Programmiermodus kommt." Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen, die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem Oszillator
kommt." > > Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen, > die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP > sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V > gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem > Oszillator
-
Thread
Frage zu MSP430 Dokumentation für Einstieg
nicht ausprobiert. Muss nur noch die ADC und RTC und EEPROM Emulation anpassen. Da der MSP430 kein internes EEPROM hat werde ich natürlich FRAM dazu nehmen. Anstatt eines sonst üblichen externen RTC möchte ich den internen RTC dafür in Anspruch nehmen. Ein 32kHz Quarz ist ja auf der L.P. Board vorhanden
Rufus Τ. F. schrieb im Beitrag #5604036: > BSL, das ist ein etwas verfrickeltes UART-Protokoll. BSL läuft über UART, I²C, oder USB, je nach Chip. > Das kann jeder MSP430 Außer die ganz kleinen Flash-Modelle, z.B. MSP430G2001.
-
Thread
Komisches Verhalten beim Programmieren
Alle AVR Mikrocontroller werden standardmäßig von einem internen R/C Oszillator getaktet. Erst durch Umstellen der Fuses mit einem Programmieradapter wird er ggf. auf eine externe Taktquelle umkonfiguriert. > Detected Micro does not match the Selected Micro
benötigt man dafür mittlerweile keinen Quarz mehr? Mittlerweile? Naja... Klar, für USB, CAN, UART, usw ist oft ein recht exakter Takt erforderlich. Dann Quarz. Aber sonst, laufen so ziemlich alle AVR auch gerne mit internem Takt Tipp: Das jeweilige Datenblatt mal studieren
-
Thread
Atmel AVR: RC-Takt genau genug für Low-Speed-RS232?
gelegentlichen Update von Firmware per Bootloader oder zum Ausgeben von Logmeldungen genügt mir der RC Oszillator. Für ernsthafte UART Kommunikation würde ich den RC Oszillator bei keinem µC verwenden.
Und das hast du - woher ? Ben B. schrieb im Beitrag #5545670: > Edit: Was ist mit dem 128kHz-Oszillator, den die AVRs für den Watchdog > haben? Wird der von dem internen RC-Oszillator der CPU abgeleitet und > wie genau ist der? Im bestem Fall so genau wie der interne RC-Oszillator, meistens aber
-
Thread
AVR Timer/Counter Zeit berechnen
Marc V. schrieb im Beitrag #5537680: > Selbst ein Fehler von 30% ist absolut uninteressant, Stabilität ist > wichtig. Fehler ist auch uninteressant nur die Stabilität ist mal beim internen RC für gewisse Anwendung nicht optimal. Ebenso kann die UART
interne RC und mal nur zur Info auf die UART verwiesen ab S.163. Diese Tables beziehen sich alle auf einen externen Quarz viel Spaß mit dem internen RC als Basistakt bei der UART... Die Umgebung mal nicht
-
Thread
LPC1549 von Grund auf verstehen
Startup Code aus? Die Initialisierung kann man aus CMSIS nehmen, der uC sollte aber ohne mit dem internen 12 MHz Oszillator laufen. Was eventuell noch fehlt ist die power für gpio einzuschalten, ich weiß jetzt nicht ob das nach Reset per default für deinen Port gemacht wird. Einfacher gehts jedenfalls
Doran S. schrieb im Beitrag #5534856: > Hat jemand einen Tipp, wo der Fehler liegen könnte? > Muss ich noch irgendwie den Takt aktivieren? Ja, die diversen Fehler liegen bei dir. Erstens frag ich mich, wozu du so ein Linkerscript bloß brauchst. Geht's nicht etwas einfacher
-
Artikel
AVR Checkliste
'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene bestimmen. Ein häufiger Fehler ist beispielsweise, dass über die Fuse "CKSEL" ( clock select ) die falsche Taktquelle gewählt wurde. Die meisten AVRs können mit dem internen Oszillator ( internal R/C ), mit einem externen Oszillator
Für serielle, asynchrone Kommunikation per UART sollte man deshalb immer 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
-
Thread
Programmieren von STM32F765VGT6
ausprobieren. Na dann, lass blinken. Beim dem Blinky im Anhang wird PC13 geschaltet und dazu der interne Oszillator benutzt. Zum übertragen empfehle ich das neue STM32CubeProg. https://www.st.com/en/development-tools/stm32cubeprog.html
Ups, kleiner Fehler. Hier die Richtige:
-
Thread
mit Bascom über rs232 Frequenz aus einen Frequenzzählermodul auslesen.
wenn ich die Dauerschleife kürzer mache dann tritt auch hier der Fehler auf.
und holt die seriellen Daten ab. Daran kann man einfacher testen und z.B. Interrupttätigkeit als Fehler ausschließen.
-
Thread
Zeitmessanlage mit Raspberry Pi
bei Störungen) und wie lange der Raspi für die Verarbeitung braucht. Ich würde unbedingt einen internen Timecode-Counter im Programm verwenden, zum Beispiel über Millies (interne Millisekunden seit Rechnerstart) und nicht über die "Uhr" des Raspies. Dazu ist die zu unsicher. Den Rechner gestartet und
theoretisch habt ihr Recht. Karl K. schrieb im Beitrag #5507908: > Ich würde unbedingt einen internen Timecode-Counter im Programm > verwenden, zum Beispiel über Millies (interne Millisekunden seit > Rechnerstart) und nicht über die "Uhr" des Raspies. eh klar; man clock_gettime rµ schrieb
-
Thread
STM32 (F3) CSS immer an?
defekter Quarz wahrscheinlich erst beim Kunden auftauchen, wenn man einen exakten Clock benötigt (z.B. UART, USB). VG Basti
sehr wahrscheinlich auf HSI. Steht so im Datenblatt. Nur auf diese Weise kann man im Code auf Oszillator Faults noch reagieren und z.B. kritische Hardware halbwegs sicher abschalten. Andere µCs bleiben einfach stehen. Das wäre z.B. bei meiner Weichenansteuerung hier blöd: Die Weichenantriebe fangen
-
Thread
ADXL345 und ESP8266: Echtzeitdatenergassung mit konstanter Abtastrate und Interrupts
ist erwartet. Der ADXL345 arbeitet ohne ext. Quarz und erzeugt damit seine Frequenz durch einen internen (Ring-)Oszillator. Eine Abweichung von +/-2..3% ist da durchaus zu erwarten. Eine max. spezifierte Abweichung der Frequenz von der eingestellten ODR habe ich aber leider nicht im Datenblatt gesehen
denke daran, dass du es irgendwie mit dem PC verbinden willst. Du brauchst wohl auch noch einen USB-UART dazu und eventuell einen ISP Programmer (falls es keinen Bootloader enthält).
-
Thread
Umbenennung von Registerbezeichnungen
da mache. Interessanter Einwand... Kann ich aber nicht ganz ernst nehmen :) > logische Fehler u.ä. fallen mir meist schon > da auf Wie Du logische Fehler durchs Umbenennen von Registern und Ausschreiben der Registerbits erkennst müsstest Du mal genauer erklären. Gruss Moby
als TX senden, das dann eben ein .def bekommt. Baudrate 38400 geht auch immer. Wenn der AVR mit internem Oszillator läuft und Zeichenmüll ankommt, wird eben aus F_CPU 1000000 mal schnell 990000 oder 1010000 gemacht, eins war bisher immer im Toleranzfeld des Terminalprogramms. Da ist an diesen Stellen
-
Thread
ATmega8 verhält sich fehlerhaft
Was ist denn am Port D angeschlossen? PD0: Signaleingang von der Codeeingabe-Einheit (mittels UART und RS232 über MAX232) PD1: Signal an die Türeinheit (langsames Signal, kein UART oder so) PD2: Signal von der Türeinheit (zur Meldung von Fehlern) (langsames Signal, kein UART oder so) PD3
Fehler erst sehr spät suchen. Auf mechanische Einwirkung reagiert er auch nicht. Habe an den Kabeln gewackelt - nichts. Zudem müssten da viele Kontakte auf einmal kaputt sein. Und der Fehler dürfte nicht
-
Thread
GPSDO Fragen
professionellen GPSDO von Meinberg verglichen. Ich frage mich, was ich da erwarten kann; die beiden Oszillatoren werden ja nie exakt die selbe Frequenz haben, da sie ja nicht wirklich gegeneinander gelockt sind. Jedenfalls habe ich festgestellt, dass im Vergleich zum Meinberg mein Oszillator immer noch ein
- der Oszillator könnte ja eine halbe Sekunde lang 10.0000001 MHz machen und eine halbe Sekunde lang 9.9999999 MHz. Auf dem Oszilloskop sieht man das nicht, im Phasenrauschen sieht man es vielleicht, aber bei der
-
Thread
Analoge Orgel mit USB-MIDI steuern
später - schon mit SN74, aber ansonsten keine Unterschiede. Damals baute man noch so: 12 LC-Oszillatoren, für jeden Ton, und Oktavteiler. Eine Orgel, wo separate Oszillator für jede Taste vorhanden war, habe ich nie getroffen (so könnte eine analoge Orgel aussehen) - schon allein deshalb, weil man
Frequenzteilung im Verhältnis 2:1, und zwar auf analogem Wege über synchronisierte Sperrschwinger-Oszillatoren.
-
Thread
ATMega328P vs ATMega328PB stürzt ab
müssen! Ja, 20MHz kann er! Aber nur mit einem extern zugeführten Takt! Nicht mit Quarz und internem Oszillator!
> Ja, 20MHz kann er! > Aber nur mit einem extern zugeführten Takt! > > Nicht mit Quarz und internem Oszillator! Achso. Intern ist klar - das will ich ja auch gar nicht. Okay, er kann also keine 20 Mhz mit Quarz, sondern nur mit Takt. Das ist schlecht. Was kann er denn mit Quarz, 16 Mhz? Gehen
-
Thread
Verbesserungsvorschläge und Stromverbrauch eines AVR Weckers
Baudraten recht gut möglich. Eine Kalibrierung mit Temperaturkompensation, wäre dann kein großer Fehler.
Baudraten recht gut möglich. > Eine Kalibrierung mit Temperaturkompensation, wäre dann kein großer > Fehler. mit einer genauen 2^15Hz Referenz oder schlicht Uhrenquarz) kann man den internen RC-Oszi einfach kalibrieren. Suchfunktion im Forum sollte dazu einiges liefern. Dann ist auch die Baudrate wunschgemäß
-
Thread
Ist es noch sinnvoll, mit Controllern zu arbeiten?
unten, Cortex-M3 in der Mitte und Cortex-M7 für etwas Power. Ich wüsste jetzt nicht, warum ich da 10 Uart Treiber schreiben muss. Die Uart des M7 ist in meinem Fall zum M3 kompatibel, also benötige ich insgesamt 2 verschiedene und gut. Wirklich portiert habe ich in den letzten 30 Jahren eigentlich nie
extrem selten. Interessant waren die CMOS-Steine (65SCxx), weil man sie anhalten konnte, den Oszillator stoppen und ein paar Minuten später an der selben Stelle weiterlaufen konnte.
-
Thread
Fehler zum nachbauen :-)
bratz bratz bratz PÄÄÄÄÄÄM! Das kommt mir doch sooo bekannt vor!! Dass wir auch alle denselben Fehler machen mussten!! Ich wollte mit der frischgeladenen Batterie die internen Kurzschlüsse von alten NiCd-Akkus beseitigen. Dazu habe ich den NiCd-Akku per Draht in kurzen Abständen jeweils Sekundenbruchteile
die Idee, die Taktquelle auf den internen 32,768kHz-Oszillator zu stellen. Hat eine kleine Weile gedauert, bis ich auf den Grund dafür kam, dass das Ding nun gar nix mehr zu tun schien: an einer Stelle vor der ersten Ausgabe an dem Pin, der
-
Thread
UART an ATMEGA328P-MMU
(nextChar != '\n') { uartString1[zahler] = nextChar; zahler++; } else { uartString1[zahler] = '\0'; zahler = 0; USARTsend(uartString1); uart_putc('\n'); memset(uartString1,0,20); } } } [/c]
-
Thread
Unterschiede zwischen ARM und ATmega in der Programmierung
Kommunikations-Schnittstellen. Der ist auf den Eval Boards sowieso immer vorhanden. Beispielsweise beim STM32F103 hat der interne RC-Oszillator "HSI" ab Werk eine Toleranz von -2% bis 2.5% bei 8MHz. Nils N. schrieb im Beitrag #5319567: > Ein paar µS Timerinterrupt Sekunden schafft auch ein AVR relativ > genau > mit internen Quarz. Es gibt keinen internen Quarz, nur interne RC-Oszillatoren. Und diese Angabe der Auflösung sagt nicht viel aus.
-
Thread
Brauche Unterstützung beim OV7670 (bzw. SCCB)
Blumen gehen an ihn). Sodann folgt das eigentliche Problem, das seinen Ursprung beim Aufruf von "UART0_senden_Byte(Ov7670_readByte())" hat. Bei der Sichtung dieser Routine fiel mir auf: sie ruft die Unterroutine "UART0_tx_in(Byte)" auf und in dieser Unterroutine wiederum wird ein internen Puffer
Wenn meine Vermutung richtig ist, dann habe ich den Fehler: (muss ich aber noch mit einem Sniffer nachweisen: wenn hier was schief geht, flute ich den Buffer mit Bytes, die er nicht erwartet: [code}void OV_SCCB_RegisterToUart(char RegisterAddress){
-
Thread
UART Protokoll für µC
an alle, ich suche schon ziemlich lange nach einer Lib oder einem Standard für die serielle (UART) Kommunikation zwischen µC und PC bzw. µC und µC. Anwendungsfall wäre üblicherweise folgender: Ich hab irgendein Gerät mit einem (relativ kleinen) µC (Atmega o.Ä.) der per UART (+ FTDI, CP2102)
gehabt. Allerdings mit Logview alle paar 100ms ein paar Daten dauerhaft. PS : Die AVRs liefen mit internem RC Oszillator damals noch mit CALBYTE :-) Aber wehe, man ändert die Spannung zu sehr, dann gibt es wirre Zeichen... Gruß Kai
-
Thread
UART - Beispiel aus dem Tutorial will einfach nicht laufen :-(
https://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
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
-
Thread
Schaltplancheck: Alarmleuchte an Hausbus
nicht die Möglichkeit eins einzubauen. siehe https://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Wichtiger Hinweis 2 : "Auf Grund permanent wiederkehrender Nachfrage sei hier AUSDRÜCKLICH darauf hingewiesen, dass bei Verwendung des UART im asynchronen Modus dringend ein Quarz oder Quarzoszillator verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt
-
Thread
ISR Code schneller machen?
(); state_UART_MODE = FINISH; // Kalibrierung beenden done_cal_OSC = true; // Merker Oszillator syncronisiert } if (count_fail > 9) { // zu viele ungültige Messwerte state_UART_MODE
interrupt */ ATOMIC_BLOCK (ATOMIC_RESTORESTATE) { // wegen ISR(TIMER1_COMPA_vect) UART0_CONTROL |= _BV(UART0_UDRIE); } } [/c] Das läuft jetzt schon viele Minuten ohne Fehler, sodass ich sicher davon ausgehen kann der Fehler ist gefunden. :-) :-) Soll ich vorsichtshalber
-
Thread
Erste Schritte RS232 mit ATMega, wer kann helfen?
Avr uart geht nur mit externem Oszillator, da der interne rc zu ungenau ist.
> Der Takt steht auf 3686400Hz (interner Oszillator) Beim m88 läuft der interne Ossi mit nominell 8MHz.
-
Thread
FTDI R232L zu Hterm
welche clocks meinst du genau ?? Wenn du keine Clocks bewusst eingestellt hast dann ist das dein Fehler. Du musst dich darum kümmern. nfet schrieb im Beitrag #5254930: > (anderer externer Oszillator HSE) Er meint vermutlich dass du auf den beiden verschiedenen Boards eine unterschiedliche Taktquelle
Alle STM32 Mikrocontroller haben ein sehr variables Taktsystem. Sie starten mit einem internen 8Mhz R&C Oszillator. Per Software solltest du auf einen externen Quarz umschalten, da R/C Oszillatoren für serielle Schnittstellen nur bedingt geeignet sind (zu ungenau, vor allem bei Spannungen ungleich
-
Thread
Abblockkondensatoren bei hoher Packungsdichte
zucken, das ist Fast schon Morsen. > Das kann >aber auch dadran liegen das der Tiny kein Hardware UART kann und es uU >bessere Softwarelösungen gibt. uhhhhhh!! Warum nimmst du keinen Tiny mit Hardware-UART? Oder einen GUTEN Soft-UART? Ob es ein Kabel- oder Softwareproblem ist, kannst du prüfen
. Außerdem hast du das Problem, daß der interne RC-Oszillator nicht so super genau ist und ggf. kalibriert werden muss. https://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART >DS76176 komme ich jedenfalls völlig stressfrei auf
-
Thread
Einfuss Jitter auf Audiosignal
möchte eine PLL für das Audiointerface. Ich hatte mal von Audio Enthusiasten gehört, die extra den Oszillator in cd Spieler getauscht hatten, für eine bessere Audioqualität. Deswegen wollte ich wissen ob ein 0815 Oszillator sich stark auf die Qualität auswirkt.
sein soll, dann schau nach Oszillatoren, die extra für Low-Jitter designed wurden. Ein Beispiel wäre Si570.
-
Thread
Wann nehme ich welchen Quarz?
wenn man einen LCD nehmen will? Dann nimmt man gar keinen Quarz. Für fast alle LCD reicht der interne RC-Oszillator. > Wie sieht es aus, wenn man mehrere UART realisieren will? Dann muss man rechnen, welche Baudraten man nutzen will, wie man den Prescaler wählt und ob sich das ausgeht. Das ist
Beitrag #5240134: > Für eine Eieruhr oder den Belichtungstimer kann ich also bedenkenlos den > MC-internen Oszillator verwenden? ja, reicht locker. Im Datenblatt ist normalerweise der Fehler angegeben. Bei einigermassen guten µC hast du z.B. 1% Fehler. Bei halbwegs konstanter Zimmertemperatur eher noch
-
Thread
Selbstbau: Dev-Board
16MHz Quarz (auch hier bräuchte ich vielleicht Empfehlungen; ich verwendete bisher immer nur den internen Oszillator. Ist der hier in Ordnung oder soll ich lieber einen mit einem etwas geringeren Takt nehmen? https://www.reichelt.de/Quarze/16-0000-HC49U-S/3/index.html?ACTION=3&LA=10030&ARTICLE=32852&GROUPID
umrechnet. Einfacher wäre ein DS18S20 über I2C anzusteuern. Zu einem Dev-Board sollte eine UART Verbindung nicht fehlen. Eventuell ein FTDI-USB Wandler oder ein UM2102-Modul zum darauflöten vorsehen, oder mit den entprechenden ICs diskret aufbauen. 16Mhz sind OK, wenn man mit 5V arbeitet und
-
Thread
Drehzahlmesser ansteuern
Matthias S. schrieb im Beitrag #5196716: > Kann also sein, das der MC mit seinem internen RC Oszillator > läuft und ein wenig daneben liegt... Ist sicher so, die Xtal-Pins sind andersweitig verwendet. Die internen Oszillatoren bei den STC Controllern sind aber ziemlich genau.
hinz schrieb im Beitrag #5196873: > Die internen > Oszillatoren bei den STC Controllern sind aber ziemlich genau. Das heißt, die 10% Abweichung ist super stabil? ;-)
-
Thread
STM32 Nucleo-F303K8 führt plötzlich kein Programm mehr aus
dabei aber nicht geändert. Wo steht der PC? 0x8.... Jetzt kann ich nur noch anbieten den internen Oszillator zu benutzen um Taktprobleme auszuschliessen und noch einen anderen Pin zu benutzen. Welcher soll es sein?
Bin wieder da. PA9 und interner Takt folgen.
-
Thread
STM32F446 - Taktkonfiguration
github.com/jkerdels/stm32edu/blob/master/src/rcc.c So läuft mein STM mit 180MHz, und nutzt den internen RC-Oszillator als Taktquelle. Meint ihr das läuft so? Ich hab vor der Taktkonfiguration doch noch etwas Respekt. [c] //Initialize clock config void initClock(){ //dont touch clock at the
. Die Clockinit läuft längst nicht so wie sie soll. Gemerkt hab ich es erst so richtig bei der UART-Benutzung. Wenn ich von der Baudrate auf die Taktung zurückrechne, müßte APB1 mit etwa 18MHz laufen statt mit 45MHz, wobei ich nicht weiß wie stark der FT232 überabtastet und dabei Fehler vermeidet.
-
Thread
Externer Quarz notwendig?
Beitrag #5191593: > Brauchen die inzwischen immer noch einen externen Quarz, oder sind die > internen Oszillatoren präzise genug geworden? Der interne Oszillator ist ein R-C Oszillator und mit 3% bei 25°C angegeben. Da ändert sich auch in Zukunft nichts, wenn die Genauigkeit nicht reicht, dann
Für serielle UART Kommunikation brauchst du mindestens einen Keramik-Resonator. Der interne R/C Oszillator eignet sich nicht zuverlässig. Für USB brauchst du einen Quarz.
-
Thread
Rasperry Pi, mal in Info reinschnuppern
gekippte Bits zumindestens erkannt werden. Original: 10001 1 101 0 110 ECC (1-Bit Fehler): 10001 0 101 0 110 kann wieder zum Original korrigiert werden. ECC (2-Bit Fehler): 10001 0 101 1 110 kann erkannt werden. Naja, soviel zur Datenintegrität. Ich finds schön das du dir
mal mit einem Tunerbaustein fuer DVB-S zu tun, da konnte man aus der Software erkennen, dass der Oszillator, der von 950MHz-2150MHz einstellbar war, in Wirklichkeit mehrere Oszillatoren waren, die jeweils nur fuer einen kleinen Bereich gut waren... Gruss WK
-
Thread
Hardware-Designtipps des Monats: Der Schaltplan
angeschlossen sein müssen. Dieser Schaltplan ist exakt für das PCB Layout bestimmt und mit 0 EDR/DRC Fehler.
bessere (weil rauschfreiere) y-Auflösung, aber nur zwei Kanäle und kein Bluetooth. Mit dem RC-Oszillator: Den bekommst Du temperaturstabilisiert mit Bordmitteln auf <1% Fehler. Unter dem Kriterium, dass ein Oszi keine Uhr ist (da summiert sich ja nix über die Zeit auf), kann ich gut damit leben.
-
Thread
AVR Temperatur Problem
: > Habt Ihr vielleicht einen Tipp, was da schuld sein kann ? Kein Quartz verwendet sondern internen Oszillator überschätzt ? Robert schrieb im Beitrag #5143905: > Wenn nicht der alte AVR funktionieren würde Beide werden sich im Temperaturdrift des internen Oszillators nach Datenblatt verhalten
> Hatte den internen RC mal für vUSB verwendet Bei STM32F1xx Controllern steht sogar klar im Datenblatt drin, daß der R/C Oszillator nicht für USB geeignet ist. Und ich meine, bei AVR gibt es einen ganz ähnlichen Kommentar
-
Thread
Welcher Takt; 7,3728 MHz vs 8MHz
Pete K. schrieb im Beitrag #5129171: > Ich nehme immer den internen 8Mhz Taktgeber. Hatte noch nie > Probleme > damit. Bei 9600 Baud geht der ja auch problemlos mit dem internen Oszillator, dieser schwankt nämlich zwischen 7,4 und 8,4 MHz, je nach Temperatur
Bereich bei +/- 0.2%. Mit 8MHz Quarz sind demnach 2400, 4800, 9600, 19200 und 38400 ok. Der interne Oszillator taugt lediglich für Morsezeichen.
-
Thread
Attiny45 und Arduino
Welcher Takt intern erzeugt werden kann, steht im Datenblatt (128kHz, 8MHz, 16MHz. Die 100nF an VCC fehlen auf jeden Fall. Ohne das Programm und die Fuseeinstellungen kann Dir keiner sagen, was Du noch falsch machst.
programmierst du den ATtiny jetzt ? Ohne dass du die Fuses veränderst, arbeitet der ATtiny45 mit internen 1 MHz. Wenn das reicht, ok. Sonst musst du die Fuses verändern.
-
Thread
AVR F_CPU kalibrieren
Gefühl, ihr seid alle irgendwie daneben. Oder habe ich das total missverstanden? Der TO will den internen Oszillator nehmen und damit eine möglichst genaue Sekunde erhalten (mit von ihm akzeptierten Ungenauigkeiten). Keine externen Quarz - denn wozu soll er dann den internen Oszillator abgleichen wollen
Ziel war, den Prozessor nicht mit einem dauerhaft angeschlossenen Quarz zu betreiben, sondern den internen Oszillator mit den vorhandenen Möglichkeiten abzugleichen. Klar ist dazu irgend eine Referenz notwendig. Habe selber einen Tiny25 als DCF-Uhr programmiert. Er läuft mit dem internen Oszillator
-
Thread
While(1) wird nach setzen des Timer-Interrupts nicht mehr aufgerufen
Hallo an alle! Ich besitze ein ATmega64A Board (Takt auf internen 8MHz RC-Oszillator gestellt), an dem ich ein paar Bus-Systeme auspobieren möchte. Gestern habe ich es das erste Mal in Betrieb genommen und jetzt ist ein äußerst merkwürdiger Fehler aufgetreten, vlt
hat und der hat es Atmel diktieren können. Und damit auch diese krude SPI-Programmierung über die UART-Pins, wo auch viele drauf reinfallen.
-
Thread
Attiny 85 intern oder extern 8 mhz
habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts *immer* mit dem internen RC Oszillator... Ein relativer Fehler bleibt doch immer gleich, egal ob 9600 oder 115200 Bd.
habe, auch meistens gemächliche Baudraten wie 9600 oder 19200. > Dabei klappts *immer* mit dem internen RC Oszillator - noch nie was > gegenteiliges festgestellt. Mit geringen Baudraten kannst du allenfalls den systematischen Fehler gering halten, aber rein garnix gegen den absoluten Taktfehler
-
Thread
PIC18F26K80 UART Problem (string)
vielen Dank für alle Hilfe. Ich habe heute morgen versucht ein Minimal-Programm zu erstellen um den Fehler zu reproduzieren. Den Fehler selbst bekomme ich nicht reproduziert, aber ein völlig unberechenbares Verhalten der UART-Schnittstelle. Entweder fehlt irgendeine grundsätzliche Einstellung oder ich mache
auswerten kann. (Darum sind auch viele der neuen Delays drin) Zumindest bei der Verwendung des internen Oszillators auf 64MHz wird das aller erste Byte falsch übertragen, wenn es zu schnell nach dem Startup gesendet wird. Die Oszillator/PLL Kombination scheint dann noch nicht zu laufen.
-
Thread
CAN UP - Aktor (LPC11Cxx)
Hallo Den Quarz kannst Du auch ganz weg lassen und mit dem internen Oszillator arbeiten. Gruß Ulf
Der Quarz ist nicht nötig, der LPC11C24 läuft auch mit dem internen 12 MHz RC Oszillator. Aber der J6 am LPCLink2 ist ein Problem, ich habe den auch modifiziert. Entweder du setzt noch den Jumper JP2, dann wird der µC über den Pin1 vom J6 mit Strom versorgt. Das