-
Thread
Systick zu langsam / Hardwarefehler
Schaltpläne posten, aber letztendlich handelt es sich nur um den Prozessor mit Hühnerfutter, der ein paar UARTs betüddelt. 99,9% werden ohne Fehler gefertigt, weshalb es in meiner Frage nicht um einen systematischer, sondern Einzelfehler geht. Dieser zeigt sich wie folgt: Der Systick läuft ca. Faktor
Folglich funktionieren einige Timeouts auch nicht wie erwartet. Das Interessante ist, dass die UARTs mit der richtigen BAUD-Rate arbeiten! D.h. deren Taktquelle ist in Ordnung. Also bin ich von einem defekten Controller ausgegangen, doch auch dies hat den Fehler nicht behoben! Bevor jetzt Aussagen
-
Thread
UART einzelne Zeichen senden
Beliebter Fehler: Der AVR läuft mit internem Oszillator. Der ist ohne Nachjustierung aber meist zu ungenau, um im Baudratentoleranzbereich von PCs zu bleiben. ALso: Externer Quarz angeschlossen und aktiviert?
Umrechnungsformel von 16 in 8 ändern) wird die Abweichung bei 9600 bd stark reduziert. Trotzdem nimmt man bei UART-Anwendungen besser einen Quarz, da der interne RC-Oszillator nicht besonders genau ist.
-
Thread
Taktgenauigkeit v. Quarz
Auch richtig gefused oder benutzt das Ding den internen RC-Oszillator?^^
Zahnpasta und > Bleistiftminen. Kommt auf die Anwendung an! Wir haben viele IO-Boards die nur über UART (per RS422) kommunizieren. Und hier sind 500ppm völlig ok. Die internen RC-Oszillatoren der STM32 sind nämlich oft genau einen Zaken zu ungenau für sowas *1). Da käme eine billige Taktquelle mit 1000ppm
-
Thread
AVR-Debugging: Speicherstelle überwachen
Baudratenfehler ist <1%? Nein. Die neueren AVRs sind bei den verwendeten Baudraten (9600/19200) mit internem Oszillator hinreichend genau, der Input ist OK (kann man sich ja im Debugger anschaun). Peter D. schrieb im Beitrag #6880310: > Dann kommt noch hinzu, ob Du auch wirklich ein sauberes fehlertolerantes
Beitrag #6880319: > Nein. Die neueren AVRs sind bei den verwendeten Baudraten (9600/19200) > mit internem Oszillator hinreichend genau https://www.prosieben.de/tv/galileo/themen/mittwoch-17-dezember-2014/schlaumeier-pferd-vor-der-apotheke-kotzen-sehen Vermutlich willst Du das Produkt nicht komerziell
-
Thread
Keine RS232 Kommunikation bei CPU-Taktraten über 4 MHz
> Bei höheren Taktfrequenzen funktioniert aber nicht einmal 2400 Baud. In der Regel kann jeder uart bis maximale Quarzfrequenz/16, /32 oder /64. Bei glatten Quarzen passen die baudratn oft nicht. Der Fehler sollte <1% sein, über 3 geht nix mehr. Es gibt uart-Quartze, mit vielfachen von 115200
. Keine Fehler oder Aussetzer mehr.
-
Thread
ATtiny2313A und ESP-12F/M3 UART Problem
Der Tiny läuft mit internem Oszillator? Der interne Oszillator ist vermutlich nicht genau eingestellt? Viele UART-Probleme entstehen durch eine ungenaue Taktquelle am AVR. Man kann den internen Oszillator aber über Register
Sebastian R. schrieb im Beitrag #6848440: > Der Tiny läuft mit internem Oszillator? > Der interne Oszillator ist vermutlich nicht genau eingestellt? Ja ist er. Diesen Punkt habe ich nicht bedacht da ich solche Probleme noch nie mit einem Controller hatte. Ich verwende
-
Thread
LWL Broadcom AFBR-26xx DC-50Mbd codierung
Gustl B. schrieb im Beitrag #6841195: > schreibe einen UART Wozu? gibts ja überall im internet rumliegend. Zb. hier https://forum.digikey.com/t/uart-vhdl/12670
FPGA schrieb im Beitrag #6841367: > Gustl B. schrieb: >> schreibe einen UART > > Wozu? gibts ja überall im internet rumliegend. Zb. hier > > https://forum.digikey.com/t/uart-vhdl/12670 Naja. Die allermeisten UARTs sind mal sicher NICHT auf 200MHz++ Arbeitstakt ausgelegt
-
Thread
WS2812B 800KHz PWM mit Transistor Pegelwandler
so, dass die SW vorab testet, ob ein externer Pullup angeschlossen ist. Zunächst wird nämlich der interne Pulldown aktiviert und dann der Logik-Level am Ausgang gemessen. Ist dieser High, wird auf OpenDrain umgeschaltet, sonst auf PushPull.)
4,7V zu wenig. Mit den +5V wird ein FTDI232RL Chip versorgt so spare ich mir den externen Oszillator für den USB zu UART Wandler. Desweitern versorgt dieser die RGB LEDs. Stefan ⛄ F. schrieb im Beitrag #6843684: > Felix, hast du die Basis-Schaltung ausprobiert? Ja habe ich, damit würde es
-
Thread
ATmega328p fehlerhafte UART-Anzeige mit bootloader
entsprechend der Fuses die ich gesetzt habe. Im bootloader, wie auch im Hauptprogramm habe ich die uart.h und uart.cpp eingefügt. Wie gesagt, bin ich Anfänger und hoffe, dass ich alle nötigen Dateien angehängt habe. Vielen Dank schon einmal.
zu fassen. Habe nun viel mit UART versucht zu diagnostizieren, die ganzen counter mit geplottet und deren Funktion versucht zu verstanden, aber ich krieg nicht raus was der Fehler ist. Ich kann mir gut vorstellen, dass es am ATMega328p
-
Thread
genaue Zeitmessung (hohe Auflösung + Genauigkeit) STM32
anbietet (Also mit einem digitalen Eingang starten und stoppen lässt), sich mit einem hochgenauen Oszillator ansteuern lässt und per SPI,I2C oder UART abfragen lässt? Ich habe schon einen TDC7200 ins Auge gefasst, aber dieser kann maximal 14mS messen (mit 2Mhz Quarz) und langsamer kann ich den nicht
du dich lieber streiten, falsch verstehen und Fehler in Formulierungen suchen um dich besser zu fühlen?
-
Thread
Resonator korrekt anschließen
Kern. Sobald irgendwelche Treiber ins Spiel kommen, sind 0 und 1 Bits nicht mehr gleich lang. Die internen Verzögerungen und die Ausgangsströme für Hi und Lo sind nicht symmetrisch. Das ergibt einen kleinen zusätzlichen Fehler. Der ist unabhängig von der Bitrate und wirkt sich deshalb bei hohen Bitraten
Zimmertemperatur, ansonsten kommen nochmal 0.3 bis 0.4% dazu. Dieses gesagt habend würde ich für UARTs immer Resonatoren bevorzugen; die sind eben viel pflegeleichter als Quarze; alleine die internen Kondensatoren verkleinern die Antennen auf der Platine deutlich.
-
Thread
Geeigneter Controller der AVR-Familie gesucht
kenne mich mit der Materie eben noch nicht so aus. Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt.
libre95 schrieb im Beitrag #6706552: > Falk B. schrieb: >> Na dann nimm 8 MHz, ggf. einfach mittels internem RC-Oszillator erzeugt. > > An 8MHz hatte > .......ich auch schon gedacht. /o\ Vielen Dank!
-
Thread
STM32L052x8 USB mit Bare Metal Code funktioniert nicht. SET_ADDRESS fehlerhaft
zur USB-Logik: https://github.com/kcuzner/led-watch/blob/master/common/src/usb.c Es wird der interne 48 MHz Oszillator mit Clock-Recovery für's USB genutzt. Der Core/Peripherie läuft vom internen 16 MHz HSI mittels PLL auf 32 MHz. Das System scheint soweit auch korrekt zu sein. Sobald der STM
mit _internen_ Oszillatoren halte ich immer für wenig stabil und zuverlässig. Ein interner Oszillator wird immer mehr oder weniger stark vor sich hindriften, im Gegensatz zu einem Quarzoszillator. Auch wenn
-
Thread
Pendel mit DCF77 synchronisieren Gesperrt
Ein freischwingendes passendes Pendel ist doch schon ein mechanischer 1Hz Oszillator. Den mit ein bischen Jitter zu verstimmen dürfte aufwendiger sein als Du vermutest.
wieder einpendelt. Vielleicht solltest Du erwägen einen stabilen TCXO oder besser OCXO/Stratum III Oszillator als Zeitbasis für den uC zu verwenden weil der typische 8MHz uC Quarz normalerweise im Vergleich zu solchen Oszillatoren sehr unstabil ist. Jedenfalls bin ich der Ansicht, daß bei Deinem Konzept
-
Thread
[ATTiny44+PI4] TWI Slave nur mit langsamen Clocks
verschoben (zB 0x40 statt 0x80). Bei 100kHz klappt der ACK nicht mehr. Der Tiny läuft bei mir mit dem internen 8MHz RC-Oszillator. Der Code ist mit -O2 kompiliert. Clock hab ich nicht kalibriert. Als Code habe ich diesen hier benutzt: https://github.com/svoisen/TinyWire/tree/master/TinyWireS Hat jemand
I2C-Master habe ich bisher nur von Philips gesehen. Z.B. die AVRs und 8051 von Atmel haben massiver Fehler in der Hardware, obwohl sie das Interface von Philips abgekupfert haben.
-
Thread
Anfängerfrage: 40 Stück Atmega328 an einem Quarz?
. Die wirklich interessanten Aspekte dieses Projektes kannst du auch ohne Übertakten mit den internen R/C Oszillatoren testen.
Übertakten den LPM-Befehl stören, d.h. man liest manchmal falsche Daten. Viel Spaß dabei, solche Fehler zu debuggen.
-
Thread
Initialisierung 204b LCD mit ST7066U
im 4 Bit/Pin Modus (ohne Busy-Flag) zu initialisieren :/ Dabei benutze ich einen ATMEGA328P mit interne Oszillator. Leider klappt es nicht. Ich habe mich aller Anfangs an dem LCD Tutorial von Mikrocontroller.net orientiert. Doch schnell war klar, dass ich etwas ändern muss. Zunächst habe ich die
eagled schrieb im Beitrag #6663169: > Zunächst habe ich die > Verdrahtung kontrolliert und keine Fehler feststellen können. Da las doch noch mal Andere drüber gugen!
-
Thread
Vergleich Osz R&S RTB2004 vs. Siglent SDS5034X
Wenn die Dekodierungskästchen rot sind, ist irgendwo ein Fehler
ich alle Triggerereignisse aufzeichnen will, verwende ich den Fast Segmentation Modus. Wenn aus internen Gründen, wie Speichermanagement usw., Trigger nicht erkannt, bzw. ausgelassen werden, fehlen sie eben auch in der History. Es gibt immer Lücken beim Triggern, z.B. wenn der Bildschirm aktualisiert
-
Thread
Einstieg(scontroller) in Ethernet Kommunikation mit STM32
nämlich alles andere als simpel - insbesondere wenn du nicht den simplen Weg über einen Ethernet-zu-UART Adapter gehst. Muss es unbedingt mit Kabel sein? Es gibt extrem preisgünstige WLAN-zu-UART Adapter, zum Beispiel das ESP-01 Modul.
festlegt. Das Gleiche hast du prinzipiell auch beim ESP-01 Modul, nur dass dieses halt WLAN und UART nutzt.
-
Thread
EMV und aktuelle uC
Datenblätter vergleichbar sind). Die L0 sind auch von der Takterzeugung her flexibler, man kann z.B. einen internen Oszillator mit 1MHz haben. Die STM32G0 strahlen wieder etwas mehr und haben weniger VDD/GND-Pinpaare, aber dafür haben sie als einzige STM32x0xx einen internen Oszillator, der stabil genug für UART
im* µC abspielt, kommt dann gar nicht erst auf die Leiterplatte. Und wenn du dir dann noch den internen Oszillator leisten kannst, dann ist Ruhe. Und wenn es wegen hoher Genauigkeitsanforderungen ein externer Taktgeber sein muss, dann nimm keinen Oszillazor mit ns-Flanken, sondern einen Quarz, der
-
Thread
Maßnahmen gegen das Hängen bei SPI/I2C Kommunikation
sichergestellt ist, dass die Schleife wirklich schnell genug verlassen wird. Z.b. warten bis transmit des uarts beendet. Bei I2C-bus nur für interne Signale, ganz sicher nicht das Warten bei clockstretching.
Teilnehmer MCs, dann sollte man ein Protokoll mit CRC vorsehen. Ist die CRC falsch, dann liegt ein Fehler vor.
-
Thread
STM32F407-DISC1 Board defekt
erreicht. Jetzt kann ich mich wieder der Frage zuwenden, ob mein repariertes Boar vielleicht noch einen Fehler hat, der bewirkt, daß der UART beim Starten der Anwendung nichts ausgibt, während das Board C (heiliges Anwendungsboard) diesbezüglich funktioniert. So, da sind wir jetzt.
8MHz HSE-PLL läuft auch. Mache jetzt den UART Test.
-
Thread
STM32 USB Übertragungsproblem mit Code von S.F.
dann bei 20 Modulen funktioniert. > Und es funktioniert wochenlang mit 10 Modulen parallel ohne Fehler. > Der CRS müsste ja komplett daneben sein. Kann sein, dass die falschen CRS Einstellungen den Takt noch mehr verbiegen als wenn es ausgeschaltet ist. Und dass bei 20 Modulen die RC-Oszillatoren
den Absolutwerten aber keine übermäßige Bedeutung beigemessen. Das war offenbar ein entscheidender Fehler. Dennoch bin ich extrem erstaunt, wie 'gut' die nicht nachgetunten RC-Oszillatoren sind.
-
Thread
Sipeed Lichee Tang FPGA mit RISC-V Core aus China unter 20€
#6579370: > Wie viel würdest Du dafür bezahlen, > nicht Tage mit der Suche nach undokumentieren Fehler zu verbringen oder > dich mit einer instabilen Toolchain herumzuschlagen? Eine Lizenz für Xilinx kostet ~$3500. Da bekommst Du mit jeder Version neue undokumentierte Fehler. Die Stabilität hängt
wurde. Das was mich hierbei am meisten interessoert hat ist die Umsetzung. Es werden *FiFo* als UART Buffer genutzt. Auch der interne *SDRAM* kommt zur Nutzung. Alles in allem - Ein schönes Projekt
-
Thread
uC from Scratch
Wenn er den MCU mit internem Oszillator betreibt sollte es doch überhaupt kein Problem sein ein Board zu erstellen: 1. Pro VCC-Pin ein Bypass-MLCC-Kondensator ~0.1uF 2. Ein Bulk MLCC-Kondensator an VCC mit ~4.7uF irgendwo
Sonst stellst Du bei der Inbetriebnahme Deines Boards fest, dass Dir 3 Größenordnungen im Timing fehlen.
-
Thread
microCore, ein Echtzeitprozessor in VHDL für FPGAs
erwartet hat. Pause: Ein Ereignis hat NICHT stattgefunden, das die Software erwartet hat. Die UART in microCore löst z.B. dann eine Pause aus, wenn versucht wird, die UART auszulesen - aber (noch) gar kein Zeichen empfangen wurde. Normalerweise wird dann im Pause-Trap der Multitasker aufgerufen und
Trap wird sofort ein EXIT ausgeführt, so dass der Prozessor solange auf der Stelle tritt, bis die UART ein Zeichen empfangen hat.
-
Thread
W5500 SPI Antwortet nicht
Schaltung nicht mit dem Oszillator vom Standard Board.
mir die Alarmglocken. Wie stellst du "fehlerhafte Pakete" fest? Wie ist das zu verstehen? Fehler auf der Netzwerk-Ebene werden ja vom internen TCP korrekt abgehandelt sodass der User nichts davon mitkriegt. Wenn du aber Fehler bei der SPI-Übertragung findest dann wär's schlimm ...
-
Thread
Fragen zu Quarzoszillatoren für Mikrocontroller
der UART meist nur mit Fehler (<1%) einstellbar. Macht aber wenig, denn erst bei etwa 5% bekommt die UART Probleme. Ein Quarz hat Vorteile gegenüber einem externen Osz: -nahezu jeder Kontroller enthält
der UART meist > nur mit Fehler (<1%) einstellbar. Macht aber wenig, denn erst bei etwa > 5% bekommt die UART Probleme. Wenn man die Geräte auf beiden Seiten der Leitung baut, kann man so mit besonders
-
Thread
Hochgeschwindigkeit-Oszillator in VHDL
jetzt vielleicht etwas laienhaft sein... Ist es eigentlich möglich einen Hochgeschwindigkeit-Oszillator in VHDL ohne die Verwendung von internen oder externen Oszillatoren zu machen? Also mit der maximalen Schaltgeschwindigkeit (Umschaltung/Erkennung der Logikelemente auf/von High oder Low) was der
Beitrag #6521306: > Ich kenne Leute, die noch einen Trimmprozess fahren, nur damit sowas wie > UART funktioniert. Wenn ich in einem FPGA so einen Oszillator nähme und einen UART drauf fahren müsste, dann würde ich dafür sorgen, dass ein UART-Frame mit einem definierten Sync-Wort beginnt, damit ich
-
Thread
MC 8051 Speicheranschluss
Sache? Ich rate mal: Weil es noch kein Brownout etc. und Beginn des Programms nach definierter Oszillator-Einschwingphase, gesetzt per Fuses, wie bei AVRs gibt. ciao gustav
im Beitrag #6520225: > ohne das NOP auf Adresse 00 läuft's nicht. Dann sollte man besser den Fehler suchen.
-
Thread
CH340 als Einzelchip in DE?
diesen Chips eine Seriennummer eingestellt werden. Das ist sehr hilfreich wenn mehrere solcher USB UART Wandler angesteckt sind. Ich bin wieder beim FTDI, auch wenn der etwas mehr kostet.
EUR im DIL14 ( Baudrate 300 ... 460800 ) https://www.shotech.de/de/mcp2221a-i-p-usb-2-0-to-i-2c-uart-protocol-converter-with-gpio.html 1,90 EUR im SO14 ( Baudrate 300 ... 460800 ) https://www.shotech.de/de/mcp2221a-i-sl-usb-2-0-to-i-2c-uart-protocol-converter-with-gpio.html Versand kostete nur
-
Thread
R8751H Vintage Clock Basteltagebuch (War: [8051] XTAL1 und XTAL2)
dass ich erstmal nur einen AT89C51-RC benutze. Warum nicht den AT89LP51RD2-20PU? Der hat einen internen Bootloader über die UART. http://ww1.microchip.com/downloads/en/devicedoc/atmel-3714-microcontroller-8051-at89lp51rd2-ed2-id2-datasheet.pdf
nicht unter 3,5MHz betrieben werden, da intern DRAM. Mit EPROM würde ich nichts mehr machen, interner Flash über UART ist viel bequemer.
-
Thread
Welchen Cube MX und IDE für den H7
conversationen zu starten und manuell zu interleaven (gegebenenfall unter Verwendung eines/mehreren internen OPAmps für die Bufferung(en))?
Und gerade der H7 hat mit mehreren PLLs und internen clocks doch unzählige Möglichkeiten. Selbst CubeMX rechnet sich doof wenn er versucht die PLL Einstellungen zu ermitteln. Und selbst der LSE rennt nicht einfach los wenn man irgendeinen Quarz dranhängt
-
Thread
NTC-Thermometer mit Padauk PFS154 und 7-Segementanzeige und UART-Ausgang
mit 3,3V laufen zu lassen. Hier fällt mir gerade noch ein Fehler im obigen Schaltplan auf: Der GND-Anschluss des PFS154 ist nicht Pin 9 sonder Pin 12 ! Verzichtet man auf die Möglichkeit, dass der PFS154 über UART Zeichen empfangen kann (wird hier mit dem Thermometer
eine zweistellige Anzeige zu viel Aufwand, gerechtfertigt vllt. für einen Temperaturschreiber über UART.
-
Thread
Ungültige Kombinationen bei RS232
konfigurieren > > Damit ist Euer "erwartet" sinnlos oder zumindest verwirrend. Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in einem Software-UART
Hmmm schrieb im Beitrag #6465787: > Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit > rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie > auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in > einem
-
Thread
STM32F4 discovery auslesen - unbekannte Programmgröße
bootloaden kann? Und das dann über einen anderen UART? Kann man testen, ob ein Bootloader am UART "wartet", ihm also eine Sequenz einfüttern, auf die hin er sich "meldet"? Ist das dieser Intel ":"-Loader? Für erhellende Beiträge danke ich im Voraus
Pins 39 und 42 von P2. > R68 - entf. > > SB10 - ON Ha, dann ist ja auch klar, warum der interne ST-Link nicht funktioniert ... > SB12 - OFF > SB15 - OFF > SB16 - OFF > SB18 - OFF > SB19 - OFF > SB20 - OFF Das betrifft Oszillator und SWO, ist also uninteressant, weil man sowieso wohl
-
Thread
Fragen zur Programmierung eines ATMega8
und auf einem 8MHz mit RC Oszillator laufenden uC das Senden der daten dann nur mit der halben Baudrate erwartet. Selbst wenn du einen auf 8MHz ungeschriebene bBootloader verwendest, ist der RC Oszillator eigentlich für UART Übertragungen
Arduino Fanboy D. schrieb im Beitrag #6456637: > Ansonsten macht ein Bootloader bei internem Takt wenig Sinn, außer man > unternimmt weitergehende Schritte zur Takt Kalibrierung. Allerdings. Der interne R/C Oszillator ist dazu kaum geeignet.
-
Thread
LCD Display (240x240px) via USB
20 MHz und kann daher nicht mit 3,3V betrieben werden. Das Digispark Modul kommt mit seinem internen R/C Oszillator. Auf welcher Frequenz dessen PLL läuft, weiß ich nicht. Der Programmieradapter des NiboBEE Roboters simuliert USB mit einem 15 MHz Quarz. Um Grafiken für ein Punk-Matrix Display
Ohne Framework sind die aber alles andere als einfach. Da sind mir persönlich die Boards mit USB-UART Wandler Chip deutlich sympathischer.
-
Thread
ATMEGA328P-AU läuft etwa um Faktor 10 langsamer als normal
pF sind empfehlenswert. Wenn du sonst nicht viel programmiert hast (Fuses?), sorgt da der interne RC-Oszillator (ca. 8 MHz) bei CKDIV8 für etwa 1 MHz.
bestimmt den Takt und da muss der "geflashte" Bootloader das auch wissen was F_CPU war sonst kann er die UART nicht richtig beim Start initialisieren. Wenn kein Bootloader auf dem Chip ist nimmt er eh weder was an der UART an noch passt der interne Takt zu den Fuses. Warum läuft der bei ihm 10x langsamer
-
Thread
S: Empfehlung nachbausicheres LC-Meter-Projekt mit Atmega
olle LM311 > zuständig ist. Habe ich gar nicht verwendet. > Hör dir doch einfach mal den Oszillator mit deinem > Transceiver an. Das ist allerdings 'ne Idee.
dann noch eine Variante mit 8051 ..die Software hat wohl mal ein Tscheche gemacht ..da geht der Oszillator nicht besonders.
-
Thread
STM32L051K8T6 wird vom ST-Link nicht erkannt
Moot S. schrieb im Beitrag #6406318: > Der Chip braucht keinen externen Quarz. Per default ist der interne > eingestellt. Wenn einen benötigen würde wäre ein 8Mhz Quarz bestückt, da > ich nachher wenn es dann mal läuft auf den externen Quarz wechseln > möchte. Die L4 können den internen MSI-Oszillator
dass ST keine kaputten Chips rausgibt wird irgendwo zwischen Lieferung und einlöten des Chips der Fehler sein. Nachdem ich den 3. Chip eingelötet habe funktioniert das Programmieren und ich kann auch den Beispiel Code wo die UART angesteuert wird ohne Probleme laufen lassen.
-
Thread
ZX81 plus38 Clone
deshalb ist vorerst ein 14Mhz statt ein 13Mhz Quarz drinnen und die Kondensatoren am Schwingquarz fehlen. Der Oszillator läuft aber trotzdem. Die Platine zieht in dieser Konfiguration 140mA. Der Prozessor zeigt aber an seinen Adressleitungen erst einmal keine weitere Reaktion.
Meine Güte mit diesen Fehlern ist die PCB Schrott. Eine Unverschämtheit sowas anzubieten.
-
Thread
F_CPU umschalten, gibt es etwas zu beachten?
eine Mimose :( Dann hilft nur eine gute, langsame PLL. Oder ein STM32G031J6M. Der hat einen internen RC-Oszillator, der sich in Schritten von 0.3% trimmen lässt. 20MHz und 18.432MHz sind ja in Wirklichkeit 19.2MHz ±4.17%. Man erzeugt also nominelle 38.4MHz STM32-CPU-Takt, teilt den durch 2 für exaktes
Bauform B. schrieb im Beitrag #6382151: > Oder ein STM32G031J6M. Der hat einen internen RC-Oszillator... Ja, wenn STM32G031J6M mit AVR JTAGICE XPII und AVR Studio arbeiten könnte, so würde ich auch so machen. Aber vor dem ich Controllerfamilie wechsele, möchte ich aus dem Vorhandenen
-
Thread
USART Frage zu Bibliotheken
Moeglicherweise hast du keinen Quarz sondern den internen RC Oszillator verwendet. Der waere dann zu ungenau. und macht solche Fehler, von Bitverschieben. Zweitens war der Mega8 die falsche Wahl. Der hat nichts, der kann nichts. Ich wuerde eher etwas in
werde ihn mir anschauen. Der Tipp das 1Mhz nicht gut sein soll bzw. generell irgendetwas mit dem internen Oszi nicht stimmt und das die Fehler verursacht ist genau richtig gewesen. Ich habe die Fuse-Bits so angepaßt das der interne Takt bei 8Mhz läuft und siehe da es geht nun auch mit der Lib. Auch
-
Thread
Atmega328p fuses falsch gesetzt
aufgelötet, das bekomme ich nicht ab. Mit dem Hilfstakt an XTAL1 wäre wohl machbar, allerdings fehlen mir hierzu die Quarze.
UNO liefert der 3,3V Ausgang nur wenige Milliampere. Das ist nur ein kleiner Seiteneffekt vom USB-UART Adapter.
-
Thread
CH340 Spezi gesucht. DTR Pull-Up?
Nachreichung meine Nano-Clones ohne XTAL am USB-UART
sich durchgesetzt, dass man aus dem SOF-Signal des USBs (welcher GENAU jede 1ms zuschlägt) den internen primitiven RC-Oszillator nachregelt. Das ist einfach ein Zähler, der zwischen zwei SOF einen gewissen Wert erreichen soll. Gespeist wird dieser Zähler vom internen RC-Oszillator. Wenn der Wert jetzt
-
Thread
ATMega324P und USART Probleme
20Mhz, mit und ohne den 2 27pF Kondensatoren getestet - LED blinkt nun im Sekundentakt. Sowie den internen Oszillator verwendet - keine Chance den kann man nicht so einfach programmieren wie den Mega8 (kann mir eingr erklaeren wie man den in 8Mhz betreiben kann?). Im Anfangteil vom Programm lasse ich eine
Also da hat's noch zwei Fehler (sowie Ungereimtheiten): > lds r16, (1<<RXEN0)|(1<<TXEN0) 'lds'? > sts UDRE0,r16 'UDRE0'?
-
Thread
PIC Microchip lebt noch?
PICs nichts bekannt. 1) Alle AD-Wandler rauschen. 2) Längst nicht alle PICs besitzen einen internen Oszillator, der genau genug ist, um über den gesamten zugelassenen Temperaturbereich einen Fehler von +-2% zu produzieren. Fazit: Du bist ein dreckiger Lügner.
dem gleichen Prozessor im 32 Pin Gehäuse einmal Geräte mit z.B. 14 ADC Eingängen bauen will neben UARTs, und I²C und ein paar digitalen I/Os, dann aber mit dem gleichen (Synergie in SW und HW Entwicklung!) wieder mal mehrere Timer Aus-/Eingänge und I²Cs und mehr USARTs braucht parallel zu normalen I/