Ich schreibe mal auf was ich beim STM32 vermisse. Der STM32F2xx/F4xx sind jetzt schon sehr gut geworden, aber dennoch habe ich Wünsche... 1) UART5 lässt sich beim F4xx nur auf einen einzigen Port-Pin mappen, wenn man SDIO haben will, kann man UART5 nicht mehr nutzen. Da könnte man etwas mehr flexibel sein, denn die neue Matrix ist genial. (Ich hätte gerne 6 UART's + SDIO genutzt) 2) Die internen PullUp / PullDown Widerstände können schön einzeln im STM32F4xx aktiviert werden und die wirken einfach immer. Außer: im Reset-Zustand. Und wegen dem muss ich extra externe PullUp/Down's rein löten und das ist lästig, braucht Platz, es können Lötfehler entstehen und kostet somit extra Geld. Besser wäre es, wenn man Option-Bytes im Flash hätte, die man programmieren könnte: 0x3 je PortPin = System default wie bisher !0x3 je PortPin = Setze den PullUp/Down/kein bei Reset. Leider habe ich keinen direkten Draht zu ST, vielleicht kennt jemand einen von ST und teilt das denen mit ;-)
Markus Müller schrieb: > Reset Markus Müller schrieb: > 0x3 je PortPin = System default wie bisher > !0x3 je PortPin = Setze den PullUp/Down/kein bei Reset. Haha. Du weißt schon wozu ein Reset da ist oder? Markus Müller schrieb: > Leider habe ich keinen direkten Draht zu ST, vielleicht kennt jemand > einen von ST und teilt das denen mit ;-) Meinst du dass 100.000 selbe Meinung auch nur dazu führen würden, dass man es sich überlegen würde? Meinst du ST interessieren Hobbybastler mit eingeschränkten Kenntnissen?
Ich bin schon seit 20 Jahren Entwickler von Embedded Schaltungen und nicht irgend ein dahergelaufener FH Schulabsolvent. Und falls Du noch nicht die Doku vom STM32F4xx kennst, dann lese mal ganz genau durch, denn da werden während dem Reset einige PullUp/Down Widerstände bereits gesetzt!
Verstehe ich nicht. Zumindest beim ersten Starten des µCs werden die Settings geladen und bis die dann umgesetzt sind, sind die Pins des µC undefiniert. Die angeschlossene Hardware macht dann was sie will. Dafür gibt es PullUp/PullDown-Widerstände in der Schaltung, damit direkt beim Anlegen der Betriebsspannung und während der Init-Phase des µCs definierte Pegel z.B. an Enable-Leitungen liegen. Nebenbei sind die konfigurierbaren internen Widerstände meistens sehr hochohmig und haben eine große Wertetoleranz. Wenn man damit klar kommt, OK. Ich hätte aber schon gerne bei 3V3-Logik einen 4k7, um Beeinflussungen durch Schmutznebenwiderstände zu vermeiden.
Sicher ist bei den mir bekannten µCs ein nicht konfigurierter IO-Pin meistens Input + weak PullUp, aber mit diesem kleinen internen Strom, der den Eingang auf "High" hält kann man stabilitäts- technisch nicht viel ausrichten.
Bei mir geht es um Outputs die z.B. einen Mosfet ansteuern. Wenn da während der Reset/Init-Phase der Output als Input mit definiertem PullUp/Down deklariert wäre, dann müsste ich nicht extra einen 47K Widerstand in die Schaltung legen, so dass der Mosfet während dieser paar ms nicht irgendwas tut. Nach der Initialisierung ist der PortPin ein Ausgang und hat entsprechend den korrekten Pegel. Inputs sind mir grad egal, denn dafür müssen entweder ohnehin Pull-Widerstände rein oder die kommen von anderen Logik-Teilen.
Markus Müller schrieb: > Ich bin schon seit 20 Jahren Entwickler von Embedded Schaltungen und > nicht irgend ein dahergelaufener FH Schulabsolvent. Ohhhh, soll ich mich jetzt vor seiner Majestät Entwickler verneigen? Meine Fresse gibt es Leute die arrogant sind.
Zu Markus' Verteidigung: Lies mal, worauf er mit zitiertem Text antwortet. Das geht für mich unter "Wie man in den Wald ruft...". Wenn mich jemand mit so strümperhaften Argumenten wie Michael als Hobbybastler bezeichnen würde, würde ich dem auch mal was erzählen. :-)
Angehängte Dateien:
-
Bild1.png
310 KB
In meiner aktuellen Schaltung brauche ich nur wegen der ersten Initialisierung 22 Widerstände extra, die für den eigentlichen Betrieb sinnlos sind. Nur damit keine undefinierten Dinge während dem Reset passieren. Platz habe ich ohnehin kaum (Gehäuse ist schon vorgegeben), Bestücken will ich nur einseitig weil günstiger, auch will ich nur 2 Lagen nutzen, da 4 wiederum zu teuer wird. Wenn ich diese 22 Widerstände sparen könnte, dann hätte ich auch Platz für einen 144er STM32F417 und somit noch mehr Möglichkeiten. Mein Verbesserungsvorschlag für ST hat praktische Hintergründe
Also da du den Chip nicht mal eben geändert bekommst würde ich dir zum Platzsparen empfehlen die Wiederstände nicht einzeln sondern in Form von Wiederstandsarrays einzusetzen. Bei vielen Widerständen mit dem gleichen Wert bringt das schon einiges an Platzgewinn. So hab ich mir das angewöhnt z.B. für Serienwiderstände bei schnellen Bussen. Das hat auch den Vorteil, dass die Sückzahl die plaiert werden muss runter geht und es dann billiger zu bestücken ist.
Ja, stimmt. Jetzt wo das Layout steht kann ich auch gut an dieser Position die Widerstände zusammen fassen.
Markus Müller schrieb: > In meiner aktuellen Schaltung brauche ich nur wegen der ersten > Initialisierung 22 Widerstände extra, die für den eigentlichen Betrieb > sinnlos sind. Nur damit keine undefinierten Dinge während dem Reset > passieren. Kannst du die Betriebsspannung fuer die kritischen Teile nicht extra schalten - dann waer es nur ein Mosfet, den du bei nem Reset in nen definierten Zustand bringen muesstest...
Mache ich zum Teil schon. CAN, Ethernet und SD-Card werden geschaltet. Hauptsächlich um Strom sparen zu können.
Markus Müller schrieb: > Ich schreibe mal auf was ich beim STM32 vermisse. Der STM32F2xx/F4xx > sind jetzt schon sehr gut geworden, aber dennoch habe ich Wünsche... Siehe auch myst.com, https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTM32F4%2C%20wish%20list%20for%202012&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=797 > UART5 lässt sich beim F4xx nur auf einen einzigen Port-Pin mappen, > wenn man SDIO haben will, kann man UART5 nicht mehr nutzen. Da könnte > man etwas mehr flexibel sein, denn die neue Matrix ist genial. (Ich > hätte gerne 6 UART's + SDIO genutzt) Generell würde ich mir eine "pin crossbar" wünschen, d. h. freie Zuordnung. Die PIC32 haben das m. W., und auch die neuen lpc8xx (aber auch nur bei den kleinen). Für welche Zwecke benötigst Du 6 UARTs und CAN und Ethernet, wenn man fragen darf? Meine Punkte wären: - Keine "shared" IRQ-Handler - Registerkompatibilität wie beim lpc. Wenn sie das nicht hinbekommen, dann wenigstens eine kompatible Library. - RAM an einem Stück, alles DMA-fähig - Mir sind das zu viele verschiedene Timer. Ca. fünf Gruppen mit verschiedenen Eigenschaften. - Internes echtes EEPROM wie beim AVR Und sie könnten endlich mal linker script und startup unter eine sinnvolle Lizenz stellen.
Du wirst ja immer einen Zeitraum haben, in der die Peripherie schon bestromt ist und der µC sich noch in der Init-Phase befindet (in der er ja erst dann seine Pins in einen definierten Zustand bringen kann). Deswegen kommst Du nie um Push-/Pull-Widerstände herum, um die notwendigen Default-Zustände zu erzeugen. Daher konnte ich in meinen Applikationen auch interne Push-/Pull -Widerstände (wenn denn überhaupt vorhanden) nie nutzen. Hinzu kommt noch, dass der eine diesen Wert, der anderen einen anderen Wert gerne hätte. Es passt doch sowieso nie richtig. Dann haben die internen "Widerstände" noch eine Streuung zwischen Gut und Böse und sind meistens typisch sowieso zu hochohmig. Im Ganzen gesehen habe ich persönlich nichts dagegen, wenn ein µC diese Option gar nicht hat. Muss man sich halt Gedanken machen, den passenden Widerstand einsetzen oder halt nicht, man sieht ganz genau schon in der Schaltung, dass das so ist, wie es sein soll und hat keine Fehlermöglichkeiten in der Software. Provokativ gesagt: Von mir aus könnte man diese Option abschaffen und die Chipfläche für andere Features nutzen.
>Für welche Zwecke benötigst Du 6 UARTs und CAN und Ethernet, wenn man >fragen darf? Das gibt ein Multi-Protokolliergerät, das alle möglichen Schnittstellen kann, 4x RS232/485, LIN, 2xCAN oder SW-CAN. Den 6. UART hätte ich gerne als Debug-UART (U5). Geht leider nicht da die Pins mit der SD-Card AF im weg sind. Die jetzige Umschaltung mit den 15 AF Funktionen ist ja schon mal eine deutliche Verbesserung gegenüber dem STM32F10x. Nur hätten die schon ein wenig mehr dort reinpacken können, um noch flexibler die Pins zuordnen zu können. Eine Multiflexible "pin crossbar" finde ich jetzt nicht so nötig. Leider kann man in den CCM Ram den Stack nicht legen, klappt nicht. Ansonsten nutze ich den gerne für größere Datenstrukturen per define:
1 | #define __ccmdata __attribute__ ((section(".ccmdata")))
|
ist der relativ leicht nutzbar.
Der CCM-RAM ist doch gerade für so dinge wie den Stack oder Heap gedacht. Was spricht dagegen ihn auch dafür zu nutzen?
Markus Müller schrieb: > Leider kann man in den CCM Ram den Stack nicht legen, klappt nicht. IAR kann das und Keil auch.
Ich hatte die Adresse mal in der Vector Tabelle eingetragen und dann lief mein Programm nicht mehr. Aber wenn das doch geht, dann liegt das wohl daran:
1 | RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_CCMDATARAMEN, ENABLE); |
Dass man erst den CCM RAM enabeln muss und dann erst den Funktionsaufruf nach "AHB1PeriphClockCmd" machen darf >> Schwanzbeißer :-/ (Nutze GCC/Eclipse, liegt wohl nicht am Compiler) Edit: Habe es gerade in meinem Programm umgestellt und jetzt klappt der Stack auch aus dem CCM-RAM, danke für den Tipp.
Also ich wünsche mir einen gescheiten CAN-Core. Das was ST da implemenitiert hat ist die totale Krücke...
Was hat es eigentlich mit diesem ccm ram auf sich?
Achso: ich wuensche mir ethernet phy im chip.
CCM = Core Coupled Memory Wenn die CPU auf diesen RAM zugreift, so ist während dieser Zeit die Busmatrix wohl nicht belegt und frei für andere Aufgaben wie z.B. DMA. Siehe RM0090 Figure 1. "System architecture for STM32F40x and STM32F41x devices" Daher auch die Trennung der einzelnen RAM Bereiche.
Markus Müller schrieb: > Den 6. UART hätte ich gerne als Debug-UART (U5). Warum dann dann nicht eine SW-UART, für Logs sollte das ja ausreichen. hal9001 schrieb: > Also ich wünsche mir einen gescheiten CAN-Core. Das was ST da > implemenitiert hat ist die totale Krücke... Geht das etwas genauer? Im Vergleich wozu?
Also sollte man alle DMA Transfers aus dem "normalen" RAM ablaufen lassen (z.B. indem man den heap in den "normalen" RAM legt) und CCM RAM für alles andere (stack, globale Variablen etc.) benutzt wird? DMA kann nicht aus dem CCM RAM ablaufen, richtig? Welche anderen Einschränkungen gibt es?
Markus Müller schrieb: > Platz habe ich ohnehin kaum (Gehäuse ist schon vorgegeben), Bestücken > will ich nur einseitig weil günstiger, auch will ich nur 2 Lagen nutzen, > da 4 wiederum zu teuer wird. > Wenn ich diese 22 Widerstände sparen könnte, dann hätte ich auch Platz > für einen 144er STM32F417 und somit noch mehr Möglichkeiten. Mein > Verbesserungsvorschlag für ST hat praktische Hintergründe Schau Dir mal den KSZ8031 an und überlege ob Du den nicht statt Deinem bisherigen PHY nehmen willst. Der ist in QFN24 und sollte damit gegenüber Deinem jetzt gewählten einiges an Platz sparen. Billiger ist er auch noch. Ich würde mich für den Einschaltmoment nicht auf irgendwas Prozessor-internes verlassen wollen. Außerdem müsste man bei den Prozessor-internen Pullups/Pulldowns auch die Zeit vor dem Flashen des µC beachten - wenn da was das oszillieren anfängt oder gar abfackelt bekommst Du das Ding gar nicht erst geflasht.
Der CCM-RAM ist nur an den Datenbus des Core angebunden. Er kann nur vom Core aus benutzt werden und dort auch nur für Daten. Es kann also keine code daraus ausgeführt werden und es kann keine Peripherie auf dieses RAM zugreifen, sprich DMA. Der Vorteil ist, dass der core ungehindert zugriff auf das RAM hat auch wenn z.B. der DMA gerade Daten aus dem normalen RAM kopiert.
Roland H. schrieb: > Geht das etwas genauer? Im Vergleich wozu? Mit einer großen Anzahl von mailboxen, wie das alle Welt bisher gemacht hat. Siehe Bosch cc770, necv850, 80167, atmega usw......
hal9001 schrieb: > Mit einer großen Anzahl von mailboxen, wie das alle Welt bisher gemacht > hat. Siehe Bosch cc770, necv850, 80167, atmega usw...... Automotive-Welt :-) ? Der erste ist stand-alone, den dritten kennt Google nicht, der vierte hat nicht gerade viel RAM/MHz. Wird der V850 mit µcLinux verwendet oder "direkt" programmiert? Ich kann es nicht einschätzen, ich kenne nur noch den lpc, welcher die gleiche Anzahl RX/TX-Puffer hat. Kann es sein, dass die genannten Teile aus diversen Gründen mehr Puffer benötigen? Mir geht's nicht um besser/schlechter, mich interessieren nur die Hintergründe bzw. die Systeme, welche 64 Puffer benötigen :-)
Der dritte ist natürlich ein 80c167 oder ST10. Wusellinux kommt mir nicht ins Haus. Wenn Du z.B. einen CANOpen oder DeviceNet Slave hast ist es doch viel einfacher wenn du für jede "Telegrammsorte" eine Mailbox hast. Ich betreue bei meinem Arbeitgeber alle CAN-Feldbusse und habe über das Teil ganz schön geflucht. Ich musste extra für dafür einen Ringspeicher implementieren.
Markus Müller schrieb: > Außer: im Reset-Zustand. Und wegen dem muss ich extra externe > PullUp/Down's rein löten und das ist lästig, Es ist aber genau so richtig und gut. Wenn deine Peripherie im Moment des Hochfahrens Bockmist baut, dann solltest du sie so konstruieren, daß sie eben auch vom Reset bedient wird und damit in den Grundzustand geht, den sie anschließend nur per geeignetem Setup verläßt. So herum macht man das. Man verläßt sich bei sowas nie auf irgendwelche hochohmigen Pullups. Nebenbei ne kleine logische Frage: Kurz vor dem Einschalten sind ja alle Signale auf Low (weil 'nix Saft') und sollen dann per Hochzieher auf High kommen - was macht denn deine Peripherie bei einer Reihe von LH-Flanken, die nach dem Powerup so langsam daherkommen? W.S.
>LH-Flanken, die nach dem Powerup so langsam daherkommen?
Das ist eigensicher. Die verwendeten Logik-Chips haben alle einen
Überlast/Kurzschlussschutz schon drin. Daher passiert nichts.
Ich wollte nur eventuelle Störungen während dem Einschalten vermeiden.
6 4-Fach Widerstände konnte ich heute unter bringen, somit 17
Widerstände gespart und ich konnte noch einen SMD Quarz als
Bestückungsoption unter bringen.
Der KSZ8031 hat den Vorteil, dass der deutlich weniger Strom verbrät als
der DP83848. Leider kann ich den nicht löten.
Ich habe auch den DP83848 ausgewählt, weil damit die LwIP Democodes von
ST funktionieren sollten, bzw. weniger zum Anpassen ist (MII > RMII).
Somit muss ich den wohl oder übel erst mal drin lassen.
Oder gibt es noch andere Vorteile des Micel Chips, die ich noch nicht
kenne?
Markus Müller schrieb: > Der KSZ8031 hat den Vorteil, dass der deutlich weniger Strom verbrät als > der DP83848. Leider kann ich den nicht löten. Geht einfach mit Heißluft, auch ohne Lötpaste: http://www.youtube.com/watch?v=c_Qt5CtUlqY Mit Preheater drunter ists noch bequemer. > Ich habe auch den DP83848 ausgewählt, weil damit die LwIP Democodes von > ST funktionieren sollten, bzw. weniger zum Anpassen ist (MII > RMII). Ich kenne jetzt zwar Deine Democodes nicht, aber die wichtigsten Register der PHYs sind standardisiert. Daher kann man die PHYs normal einfach so tauschen ohne was an der Software anpassen zu müssen. Nur die erweiterten Register für so Kram wie wann welche LED blinken soll sind modellabhängig. RMII hat den Vorteil daß Du weniger Leitungen zwischen PHY und µC brauchst. Du sparst also noch mehr Platz, das war doch das was Du wollstest. Dafür musst Du natürlich die Initialisierung des Ethernet-Moduls im µC anpassen.
Ja, ich nutze schon RMII, muss ich da ich so viel Peripherie vom Controller benötige und die Pins für MII anders belegt sind.
Ich habe mir das App-Note zum KSZ8031 mal näher angeschaut: http://www.micrel.com/_PDF/Ethernet/app-notes/an-143.pdf Wenn ich das richtig lese, braucht es nur noch einen einzigen 6K49 Widerstand, ansonsten kann man direkt anschließen. Sehe ich das richtig? (+ Quarz, Übertrager, C's an Vcc-Pins)
Markus Müller schrieb: > Ich habe mir das App-Note zum KSZ8031 mal näher angeschaut: > http://www.micrel.com/_PDF/Ethernet/app-notes/an-143.pdf Das ist eine Appnote zum KSZ8051. Wie wäre es mit einem Blick ins Datenblatt vom KSZ8031? Da ist hübsch erklärt was Du alles brauchst. > Wenn ich das richtig lese, braucht es nur noch einen einzigen 6K49 > Widerstand, ansonsten kann man direkt anschließen. Sehe ich das richtig? > (+ Quarz, Übertrager, C's an Vcc-Pins) Im Grunde schon. Nur wenn Du ins Datenblatt schaust, empfehlen die noch ein paar Cs und ein Ferrite Bead an den Versorgungspins. Hmm. Oben schreibst Du was von 20 Jahren Entwicklungserfahrung - daß man ins richtige Datenblatt schauen muß hab ich schon im ersten Monat gelernt...
Das ist die richtige App-Note. Darin ist die Migration von KSZ8041 >> KSZ8051 beschrieben und da steht auch dass der 8021/8031 beschaltet wird wie der 8051. Mir kam es auch spanisch vor, dass nur zu Beginn der KSZ8021/31 erwähnt wird, ist aber so. Mich hat es einfach etwas stuzig gemacht, da alle anderen PHY's die ich bisher in den Fingern hatte deutlich mehr drum herum benötigten, insbesondere noch 49,9R Widerstände beim Übertrager. In der Zwischenzeit habe ich auch ein Schaltplan vom Demo-Board gefunden und ich werde mich danach richten.
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.