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.
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.
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.. 🙈
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.
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?
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.
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.
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.
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
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).
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.
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:
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?
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
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.
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.
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.
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.
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.
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
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.
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.
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 im Beitrag #7332348:
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“.
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.
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?
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?
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.
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.
