Hallo zusammen, ich bin auf der Suche nach einem möglichst kleinen Microcontroller der Hardware-UART spricht, das für ein paar SN74HC595 übersetzt, ohne Quarz auskommt und gleichzeitig in einem möglichst kleinen Package daher kommt. UART zu PC wird von einem FTDI TTL-234X-5V übernommen und es müssen nur alle paar Minuten ein paar Ausgänge an den 595 umgeschaltet werden. Wenn das Ganze dann noch mit Arduino kompatibel (also nicht wie z.B. der Attiny814), recommend for new designs und aktuell verfügbar wäre, wäre ich überglücklich. Beste Grüße und einen schönen Sonntag..
ATtiny45 Ich würde der Einfachheit jedoch ein Arduino Nano Board verwenden, sofern nichts wichtiges dagegen spricht. Weil: Serielle Kommunikation mit dem internen R/C Oszllator ist bei den klassischen AVR's ein bisschen unsicher.
Ein Digispark mit CDC würde vermutlich ausreichen. Dann könntest du dir den FTDI sogar noch sparen. Oder falls du noch einen Bluepill mit original STM findest wäre das auch eine gute Option. Hier im Forum gibt es mindestens 2 Versionen für CDC für den. Oder du nimmst einfach einen anderen FTDI der SPI kann und sparst dir den uC ganz.
:
Bearbeitet durch User
Stefan F. schrieb: > ATtiny45 Hat leider keinen Hardware-UART, und wie du schon sagtest, ohne externen Oszillator nicht wirklich zu gebrauchen. Stefan F. schrieb: > Arduino Nano Platztechnisch absolut unmöglich, ich suche nach einer Onechiplösung. Im Notfall schreibe auch in normalem C ohne Arduino IDE, dann aber bitte eine möglichst einfache Implementierung, das habe ich schon seit gefühlten Äonen nicht mehr gemacht.. 🙈 N. M. schrieb: > Digispark mit CDC Das würde Treiberinstallation auf dem HostPC bedeuten, was ich versuche zu vermeiden. Der FTDI läuft auf Windoof einfach so. N. M. schrieb: > einen anderen FTDI der SPI kann Die Kommandos die vom Host kommen, und die er auch gerne beantwortet haben möchte, sind gesetzt. Einfach per SPI direkt in die 595 geht also leider auch nicht.
gubbelgubbel schrieb: > Das würde Treiberinstallation auf dem HostPC bedeuten, was ich versuche > zu vermeiden. Der FTDI läuft auf Windoof einfach so. Weil Windows den Treiber beim ersten Einstecken automatisch herunterlädt. Mir fällt gerade keine Lösung ein, die unter Windows wirklich ohne Treiberinstallation auskommt. > Platztechnisch absolut unmöglich, ich suche nach einer Onechiplösung. Einen Chip, den du an deinen FTDI TTL-234X-5V anschließen kannst? Oder vielleicht doch lieber einen Chip, der den USB Port bereits enthält? Da dir die automatische Installation des FTDI Treibers gefällt, wäre ein FTDI Modell mit SPI optimal. Oder was spricht dagegen? N. M. schrieb: > Oder du nimmst einfach einen anderen FTDI der SPI kann und sparst dir > den uC ganz. Du bist ein zu sparsam mit der Kommunikation deiner Anforderungen. Man kommt sich wie in einer Rateshow vor.
Also, wenn's nach mir ginge, würde ich mir den ATMEGA32U als "Single Chip Lösung" näher betrachten. Hat alles drin was gebraucht wird und erspart den FTDI. Der Quarz sollte wirklich kein Show Stopper sein. Wozu übrigens der HC595? Im QFN Gehäuse ist der 32U auch schön klein. https://ww1.microchip.com/downloads/en/devicedoc/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf
gubbelgubbel schrieb: > N. M. schrieb: >> einen anderen FTDI der SPI kann > > Die Kommandos die vom Host kommen, und die er auch gerne beantwortet > haben möchte, sind gesetzt. Einfach per SPI direkt in die 595 geht also > leider auch nicht. Da lässt sich leider nicht dran rütteln.
gubbelgubbel schrieb: > Da lässt sich leider nicht dran rütteln. Geht es nicht etwas ausführlicher? Kein Mensch weis, was du wirklich brauchst! Wenn das alles so geheim ist, dann musst es dir halt selbst besorgen.
Gerhard O. schrieb: > Also, wenn's nach mir ginge, würde ich mir den ATMEGA32U als "Single > Chip Lösung" näher betrachten. Hat alles drin was gebraucht wird und > erspart den FTDI. Der Quarz sollte wirklich kein Show Stopper sein. Wozu > übrigens der HC595? Im QFN Gehäuse ist der 32U auch schön klein Der braucht wenn ich es richtig verstehe auch Treiber, oder? Außerdem ist der im Moment nirgends lieferbar. Ich brauche rund 120 IOs über eine ewig lange, sehr schmale PCB verteilt. Da wird es selbst mit den SN in TSSOP knapp.
Stefan F. schrieb: > Geht es nicht etwas ausführlicher? Kein Mensch weis, was du wirklich > brauchst! Es ist ziemlich klar definiert was ich wirklich brauche: UART für FTDI SPI für SN74HC595 Kleines Gehäuse Lieferbar Idealerweise: geht ohne Oszillator an UART Idealerweise: geht über Arduino oder eine ähnlich einfache Programmierumgebung Was ich nicht brauche: USB auf SPI, weil der MC die vorgegebenen Kommandos vom Host in SPI umsetzen muss
gubbelgubbel schrieb: > Es ist ziemlich klar definiert was ich wirklich brauche: > UART für FTDI Jetzt bin ich verwirrt. Ich dachte du suchst einen Mikrocontroller, den du an deinen vorhanden UART von FTDI anschließen kannst. Oder willst du jetzt einen UART von FTDI? (was heisst "für FTDI")? Warum willst du nicht einen USB-zu-SPI Adapter von FTDI verwenden? > Kleines Gehäuse Was genau heißt für dich "klein"? Ein STM32L072C8 hat USB und es gibt ihn in 3,3·3,3 mm, und der ist ganz sicher in der Arduino IDE programmierbar. > Was ich nicht brauche: USB auf SPI, weil der MC die vorgegebenen Kommandos > vom Host in SPI umsetzen muss Heißt das, dass der Umweg über UART unbedingt sein muss, um die "vorgegebenen Kommandos" zu übertragen? Muss es unbedingt etwas mit UART sein? Ich hake nach, weil du ziemlich sicher einen Treiber installieren musst. Windows unterstützt nach meinem Kenntnisstand keinen einzigen USB-UART ohne Treiber-Installation. Es gibt andere Lösungen (z.B. HID) die ohne Treiber-Installation auskommen könnten. Auch das wäre wohl mit dem STM32L072C8 und Arduino umsetzbar, soweit ich diversen Diskussionen entnommen habe (probiert habe ich es nicht).
gubbelgubbel schrieb: > Es ist ziemlich klar definiert was ich wirklich brauche: > UART für FTDI > SPI für SN74HC595 > Kleines Gehäuse Nein. Du hast definiert, was du meinst zu brauchen. UART? Bei nur ein paar Befehlen pro Minute kann das der der FTDI mit 300 Baud rausmorsen, das liest dir noch der schlechteste Software-UART, den Arduino zu bieten hat, problemlos ein, auch ohne Quarz. SPI für die '595er? Nach allem was wir über deine Anwendung wissen, muss da kein 20MHz SPI laufen, schnarchlangsames Bit-Banging über digitalWrite & co reicht aus. kleines Gehäuse? Dir wurden Lösungen vorgeschlagen, die den FTDI ersetzen: den gesparten Platz kannst du für einen größeren µC verwenden.
gubbelgubbel schrieb: > Gerhard O. schrieb: >> Also, wenn's nach mir ginge, würde ich mir den ATMEGA32U als "Single >> Chip Lösung" näher betrachten. Hat alles drin was gebraucht wird und >> erspart den FTDI. Der Quarz sollte wirklich kein Show Stopper sein. Wozu >> übrigens der HC595? Im QFN Gehäuse ist der 32U auch schön klein > > Der braucht wenn ich es richtig verstehe auch Treiber, oder? Außerdem > ist der im Moment nirgends lieferbar. > > Ich brauche rund 120 IOs über eine ewig lange, sehr schmale PCB > verteilt. Da wird es selbst mit den SN in TSSOP knapp. OK: Mein Vorschlag: Arduino NANO mit 12 x 74HC595 in Serie. Bei 8MHz SPI Taktfrequenz geht das ruckzuck über die 328 HW SPI Schnittstelle. Und sollte der Nano immer noch zu groß sein, dann kann ja die Nano Schaltung oder äquivalent auf Deine schmale Platine übertragen werden. Im QFN Gehäuse ist der 328 ohnehin winzig. Winzige Quarze gibt es auch. Der CH340G ist kleiner als der FTDI und gibt es auch im 8-pin SMD Gehäuse. Nichts für ungut, aber ohne genaue mechanische Angaben ist es halt ein Rätselei warum "normale" Lösungen für Dich nicht passen. Es wäre besser gewesen, uns einführend zu sagen, ich möchte XYZ auf eine maximal x mal y cm große LP unterbringen und vorgefertigte Module wie der Nano sind mir zu groß. Welche Möglichkeiten habe ich? Also, wenn Du Hilfe willst, dann beschreibe in klaren Fakten was konstruiert werden soll und die zu berücksichtigen mechanischen Constraints oder Randbedingungen. Abgesehen davon, bin ich fast sicher, daß ein ATMEGA8-32U irgendwo gefunden werden könnte. Dort z.B. haben sie tausende auf Lager: https://www.digikey.ca/en/products/filter/microcontrollers/685?s=N4IgTCBcDaIIIBUCyBRA4nAjANgKogF0BfIA
Habe ich ganz vergessen: Der STM32L072CB kann USB und UART ohne Quarz. Du brauchst dafür nicht einmal einen Programmieradapter, da er mit Bootloader geliefert wird. Und es heißt CB, nicht C8. Ich sehe nicht mehr gut. https://www.st.com/en/microcontrollers-microprocessors/stm32l072cb.html
MSP430G2553, lässt sich auch mit Energia / Arduino programmieren, wenn es kein C sein soll.
gubbelgubbel schrieb: > ... einem möglichst kleinen Microcontroller der Hardware-UART spricht, > das für ein paar SN74HC595 übersetzt, ohne Quarz auskommt Selber bonden kannst du? ;-) Ein Keramikresonator wäre aber ok? Sonst kann es mit der für den stabilen Betrieb eines UARTs erforderlichen Frequenzgenauigkeit eng werden.
Wolfgang schrieb: > Ein Keramikresonator wäre aber ok? > Sonst kann es mit der für den stabilen Betrieb eines UARTs > erforderlichen Frequenzgenauigkeit eng werden. Wie gesagt, der STM32L072CB kann USB und UART stabil, ohne externe Taktquelle. Jetzt wüsste ich gerne mal von gubbelgubbel, wie er dazu steht.
gubbelgubbel schrieb: > Platztechnisch absolut unmöglich, ich suche nach einer Onechiplösung. Im > Notfall schreibe auch in normalem C ohne Arduino IDE, dann aber bitte > eine möglichst einfache Implementierung, das habe ich schon seit > gefühlten Äonen nicht mehr gemacht.. 🙈 Vorschlag: Nimm einen Atmega328PB in z.B. QFN-Gehäuse mit nem formschicken Resonator, pack da den Bootloader vom Arduino drauf und zack, kannste den als Arduino Uno verwenden. Wäre das keine Option?
gubbelgubbel schrieb: > Es ist ziemlich klar definiert was ich wirklich brauche: > UART für FTDI > SPI für SN74HC595 > Kleines Gehäuse > Lieferbar > Idealerweise: geht ohne Oszillator an UART > Idealerweise: geht über Arduino oder eine ähnlich einfache > Programmierumgebung PIC16F1454/1455. 14 Pins in DIL/SOIC/TSSOP, 16 Pins in UQFN 4*4mm, Hardware-USB-Device. Hardware UART. Hardware SPI/I2C. 3V3 und 5V-Betrieb möglich fchk
:
Bearbeitet durch User
Wer es kann, kann das auch mit einem kleinen 8 Pinner. Leider :) braucht es dazu Assembler und C-Kenntnisse. Einen Quarz oder Resonator braucht es dazh nichtmal, der interne Takt ist genau genug.
Wenn ich das richtig sehe kann STM32F042 auch in Arduino programmiert werden. USB CDC geht direkt, Quarz braucht es nicht, der genaue Takt kann durch Setzen eines Bits aus dem USB-Takt regeneriert werden. Packages gibt es in sehr klein.
:
Bearbeitet durch User
gubbelgubbel schrieb: > und es müssen nur alle paar Minuten ein paar Ausgänge an den 595 umgeschaltet werden. gubbelgubbel schrieb: > Ich brauche rund 120 IOs über eine ewig lange, sehr schmale PCB > verteilt. Stefan F. schrieb: > Der STM32L072C8 kann USB und UART ohne Quarz. So einen und dazu 8 x MCP23017 <je 16Pin> (oder ähnliche Portexpander). Damit kannst du über i2c gemütlich jeden Pin einzeln ansprechen und sparst dir damit das ganze Rumgeeiere mit zig Schieberegistern hintereinander. - https://www.mouser.de/datasheet/2/268/MCP23017_Data_Sheet_DS20001952-2998473.pdf - https://www.mouser.de/c/semiconductors/interface-ics/interface-i-o-expanders/
Irgend W. schrieb: > gubbelgubbel schrieb: >> und es müssen nur alle paar Minuten ein paar Ausgänge an den 595 umgeschaltet > werden. > gubbelgubbel schrieb: >> Ich brauche rund 120 IOs über eine ewig lange, sehr schmale PCB >> verteilt. > > Stefan F. schrieb: >> Der STM32L072C8 kann USB und UART ohne Quarz. > > So einen und dazu 8 x MCP23017 <je 16Pin> (oder ähnliche Portexpander). > Damit kannst du über i2c gemütlich jeden Pin einzeln ansprechen und > sparst dir damit das ganze Rumgeeiere mit zig Schieberegistern > hintereinander. > > - > https://www.mouser.de/datasheet/2/268/MCP23017_Data_Sheet_DS20001952-2998473.pdf > - > https://www.mouser.de/c/semiconductors/interface-ics/interface-i-o-expanders/ Die MCP23017 sind m.M.n. relativ teuer. HC164 oder 4020 und auch die HC595 wären da erheblich billiger. Leider wissen wir nicht was die Ausgänge eigentlich treiben müssen. Irgendwie vermute ich, daß LEDs im Spiel sind. Wenn es einzelne LEDs wären, dann könnten z.B. zwei MAX7219 bis zu 128 LEDs in Gruppen von 2x(8x8) zusammen gefasst im MUX Modus betreiben. Die 7219 werden mit SPI angesteuert. Das wäre in dem Fall eine saubere Lösung. Auch könnten ggf. WS28xx LEDs in Frage kommen. Es wäre schön mehr Informationen zu haben, weil man andauernd nur ratet und keine optimale Lösung ins Auge fassen kann.
gubbelgubbel schrieb: > FTDI TTL-234X-5V aka FT234XD, kann 6 MHz liefern. Nachdem der FT sein UART damit betreibt, stimmt die Frequenz auf jeden Fall. Damit funktionieren dann fast alle uC. Man braucht allerdings das Spezial-Windows-Konfigurationsprogramm von FTDI. Stefan F. schrieb: > Der STM32L072CB kann USB und UART ohne Quarz. Aber unter 0°C (evt. -10°) driftet der HSI16 doch zu weit weg. Der HSI48 kann per USB getrimmt werden, das würde reichen. Dazu müsste man den MCO-Pin mit dem HSE-Eingang verbinden und den HSI48 als "externen" Oszillator benutzen ;) Aber das kommt nicht in Frage, weil gubbelgubbel schrieb: > Es ist ziemlich klar definiert was ich wirklich brauche: > UART für FTDI
Εrnst B. schrieb: > UART? > Bei nur ein paar Befehlen pro Minute kann das der der FTDI mit 300 Baud > rausmorsen, das liest dir noch der schlechteste Software-UART, den > Arduino zu bieten hat, problemlos ein, auch ohne Quarz. > SPI für die '595er? > Nach allem was wir über deine Anwendung wissen, muss da kein 20MHz SPI > laufen, schnarchlangsames Bit-Banging über digitalWrite & co reicht aus. > kleines Gehäuse? > Dir wurden Lösungen vorgeschlagen, die den FTDI ersetzen: den gesparten > Platz kannst du für einen größeren µC verwenden. Der Host gibt über ein definiertes Protokoll vor was geschaltet werden soll. Das läuft bis jetzt über das FTDI-Kabel an einen ATMEGA2560. Der ist aber für die kommenden Anwendungen zu groß und hat zu wenig Ausgänge. Der MC meldet dann zurück, was geschaltet wurde. Das darf nicht allzu viel Zeit brauchen. Die Kontrolle der Daten soll bei den 595 über weiterschieben des Inhalts der Schieberegister zurück in den MC erfolgen. Dementsprechend muss das ganze bei 120+ Ausgängen relativ zügig von statten gehen. Stefan F. schrieb: > STM32L072CB Wo gibt's den aktuell zu kaufen? Gerhard O. schrieb: > Dort z.B. haben sie tausende auf Lager: > https://www.digikey.ca/en/products/filter/microcontrollers/685?s=N4IgTCBcDaIIIBUCyBRA4nAjANgKogF0BfIA Guter Tipp, den 32er habe ich nirgends gefunden..
Gerhard O. schrieb: > MUX Modus ist in der Anwendung ausgeschlossen, die Ausgänge müssen dauerhaft ihren Zustand halten.
Der STM32F042G6 schaut sehr gut aus und ist sogar erhältlich, danke für den Tipp.
gubbelgubbel schrieb: > STM32L072CB > Wo gibt's den aktuell zu kaufen? Gestern gab es ihn bei Mouser und bei LCSC, aber nicht in diesem extrem kleinem 3,3 mm Gehäuse, sondern in 7 mm LQFP.
gubbelgubbel schrieb: > Der STM32F042G6 schaut sehr gut aus und ist sogar erhältlich, danke für > den Tipp. Und wieviel Platz ist mechanisch nun tatsächlich vorhanden?
gubbelgubbel schrieb: > ... > Wenn das Ganze dann noch mit Arduino kompatibel (also nicht wie z.B. der > Attiny814), > ... Auch für die neuen 0/1/2 Serien gibt es Erweiterung für die Arduino IDE. https://github.com/SpenceKonde/megaTinyCore https://wolles-elektronikkiste.de/megatinycore-nutzen
Ich hatte mir gestern mal die neue STM32C0 Serie angeschaut. Die gibt es in wirklich kleinen Gehäusen. Ohne Quarz, die Frequenz-Stabilität soll 1% betragen, reicht locker für Uart.
Uwe D. schrieb: > Und wieviel Platz ist mechanisch nun tatsächlich vorhanden? Ist "möglichst klein" tatsächlich so schwer zu verstehen?
gubbelgubbel schrieb: > Uwe D. schrieb: >> Und wieviel Platz ist mechanisch nun tatsächlich vorhanden? > > Ist "möglichst klein" tatsächlich so schwer zu verstehen? Ja, das wäre ein ASIC im 0.5mm BGA-Gehäuse.
gubbelgubbel schrieb: > Uwe D. schrieb: >> Und wieviel Platz ist mechanisch nun tatsächlich vorhanden? > > Ist "möglichst klein" tatsächlich so schwer zu verstehen? Komm endlich auf den Punkt. Dann werden vielleicht Bauteile vorgeschlagen, die Du gar nicht verarbeiten kannst. Und ganz ehrlich, Deine bisher vorgetragenen Eckpunkte zum Projekt lassen mich zweifeln, ob Du überhaupt ein praxistaugliches Konzept hast. Und „möglichst klein“ kann sehr wohl im Widerspruch zur Anforderung stehen. Viel Erfolg. *Kostprobe:* gubbelgubbel schrieb: > Der Host gibt über ein definiertes Protokoll vor was geschaltet werden > soll. Das läuft bis jetzt über das FTDI-Kabel an einen ATMEGA2560. Meinst Du ein USB- oder RS232-Kabel? > Der ist aber für die kommenden Anwendungen zu groß und hat zu wenig Physisch zu groß? > Ausgänge. Der MC meldet dann zurück, was geschaltet wurde. Das darf > nicht allzu viel Zeit brauchen. Die Kontrolle der Daten soll bei den 595 Du ließt die 595 zurück um sicherzustellen, dass Du zuvor das Richtige rausgeschoben hast? Im Eröffnungspost steht ja „ein paar Ausgänge“.
:
Bearbeitet durch User
Uwe D. schrieb: > *Kostprobe:* > gubbelgubbel schrieb: >> Der Host gibt über ein definiertes Protokoll vor was geschaltet werden >> soll. Das läuft bis jetzt über das FTDI-Kabel an einen ATMEGA2560. > Meinst Du ein USB- oder RS232-Kabel? Diese vermeintliche Kostprobe wurde schon mehrfach beantwortet, ua direkt im Eingangspost: gubbelgubbel schrieb: > FTDI TTL-234X-5V Uwe D. schrieb: > Du ließt die 595 zurück um sicherzustellen, dass Du zuvor das Richtige > rausgeschoben hast? Im Eröffnungspost steht ja „ein paar Ausgänge“. Das mache ich vorallem um sicherzustellen dass auf der doch recht langen Übertragungsstrecke keine Bits geflippt wurden. Uwe D. schrieb: > Physisch zu groß? Natürlich physisch zu groß, darum dreht sich doch der gesamte Thread. Uwe D. schrieb: > Dann werden vielleicht Bauteile vorgeschlagen, die Du gar nicht > verarbeiten kannst. Die Platinen werden von einem professionellen Bestücker verarbeitet, also geht im Notfall auch 0,5mm BGA. Aber naja, es wird vermutlich auf den STM32F042G6 oä hinauslaufen, der ist (hoffentlich, mal gucken was für Anwendungen noch kommen) ausreichend klein und trotzdem noch gut zu verarbeiten.
gubbelgubbel schrieb: > Ist "möglichst klein" tatsächlich so schwer zu verstehen? Also das nackte Die ohne Gehäuse, zum Selberbonden. Abder dafür muß man ganze Wafer abnehmen :-)))
Ich verstehe noch nicht, was du mt einem FTDI Chip zusätzlich zum Mikrocontroller willst, wenn es doch möglichst klein werden muss. Wenn du Platz für den FTDI Chip hast, dann hast du auch Platz für eine Variante mit SPI, woran du die Schieberegister direkt anschließen kannst. Wenn du dich für einen Mikrocontroller entschieden hast, um den FTDI einzusparen: Wie bringst du Windows dazu, dafür keinen Treiber zu brauchen? Was ist mit dem virtuellen COM port, bauchst du den noch, oder nicht? Was mir auch noch nicht einleuchtet: Du hast von einer sehr langen Platine mit vielen SN74HC595 geschrieben. Da dafür genug Platz vorhanden ist, wieso muss dann der steuernde Mikrocontroller so klein wie ein Sandkorn sein?
:
Bearbeitet durch User
Steve van de Grens schrieb: > Ich verstehe noch nicht, was du mt einem FTDI Chip zusätzlich zum > Mikrocontroller willst, wenn es doch möglichst klein werden muss. Ich auch nicht. Vielleicht fehlt dem Fragesteller Basiswissen dafür. > Wenn du dich für einen Mikrocontroller entschieden hast, um den FTDI > einzusparen: Wie bringst du Windows dazu, dafür keinen Treiber zu > brauchen? Stichwort CDC-ACM. Das ist eine USB-Standard-Geräteklasse, wo die Treiber bereits bei jedem Betriebssystem dabei sind - und ab Windows 10 hat auch Microsoft das endlich hinbekommen. > Was mir auch noch nicht einleuchtet: Du hast von einer sehr langen > Platine mit vielen SN74HC595 geschrieben. Da dafür genug Platz vorhanden > ist, wieso muss dann der steuernde Mikrocontroller so klein wie ein > Sandkorn sein? Gute Frage. fchk
gubbelgubbel schrieb: > ich bin auf der Suche nach einem möglichst kleinen Microcontroller der > Hardware-UART spricht, das für ein paar SN74HC595 übersetzt, ohne Quarz > auskommt und gleichzeitig in einem möglichst kleinen Package daher > kommt. UART zu PC wird von einem FTDI TTL-234X-5V übernommen und es > müssen nur alle paar Minuten ein paar Ausgänge an den 595 umgeschaltet > werden. Dein FTDI 232X-5V kann auf CBUS0 einen recht genauen 6/12/24 MHz Takt ausgeben, damit läuft auch der IC intern. Das reicht für den UART. Damit tut es fast jeder x-beliebige ATtiny, selbst mit Soft-UART.
:
Bearbeitet durch User
Angehängte Dateien:
-
P1000336.JPG
240 KB
ich hab hier son kleinen Tiny2313 im QFN -Gehäuse der ist schon erstaunlich winzig.
Axel R. schrieb: > ich hab hier son kleinen Tiny2313 im QFN -Gehäuse der ist schon > erstaunlich winzig. Passt doch perfekt zum FT234XD, der hat ein DFN-12 Gehäuse mit 3x3mm
:
Bearbeitet durch User
Mir wird das ganze Projekt schon einige Zeit zu anspruchsvoll um da noch mithelfen zu können. Der werte TO muß sich da besser selber durchschlagen, da nur er die engen Randbedingungen wirklich zu beherrschen scheint. Ich wünsche viel Erfolg.
gubbelgubbel schrieb: > Uwe D. schrieb: > gubbelgubbel schrieb: >> FTDI TTL-234X-5V DANKE, nicht als Kabel wahrgenommen. > Uwe D. schrieb: >> Physisch zu groß? > Natürlich physisch zu groß, darum dreht sich doch der gesamte Thread. Mach‘ das für Dich Implizite für die Leser explizit. Zu groß kann auch die bisherige Lösung (ATMega) aus Kostengründen sein. Bin gespannt wie es am Ende aussieht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.