Hallo zusammmen, ich bin auf der Suche nach einem Programmieradapter(ISP)(SW-DP) für einen STM32 um meine Abschlussarbeit realisieren zu können. Ich würde gerne über Ethernet mittels .NET SDK auf den Adapter zugreifen können, um so den Flashvorgang zu starten bzw. die Firmware auf den Adapter zu spielen oder zu löschen. Neben diesem würde ich auch gerne Daten aus dem STM32 über den Adapter lesen können. Gibt es vielleicht auch schon Programmieradapter die serviceorientierte Schnittstellen anbieten? Als Firmware wird eine ganz normale .bin-Datei verwendet, welche in das Image eingebunden werden können muss. Ich habe schon verschiedene Adapter betrachtet (PeMicro,Segger,..), aber irgendwie scheitert es immer an irgendeiner Kleinigkeit. Kennt Ihr noch Hersteller die einen entsprechenden Adapter im Angebot haben können? Über eine Antwort würde ich mich freuen. Mit freundlichen Grüßen Arne
Ich benutze als JTAG-Adapter ein OLIMEX ARM-USB-OCD zum flashen und debuggen. Angesprochen wird der bei mir vom OpenOCD, das ist ein GDB-Server. Der kann auf dem gleichen Rechner laufen oder auf einem anderem, weil sich der GDB über TCP/IP mit dem OpenOCD verbindet.
Hallo Christian, vielen Dank für deine Antwort. Im Prinzip suche ich einen Adapter der fertige Firmwareimages auf meinen STM32 schreibt ohne Debbuging-Funktionalitäten. Das ganze würde ich gerne aus einem C#-Service steuern. Da scheint der OLIMEX nicht der richtige Adapter zu sein oder? Mit freundlichen Grüßen Arne
Das GDB-Protokoll ist ja kein offen, da kannst du ja deinen eigenen Client in C# schreiben
Was macht den nder GBD-Server überhaupt? Ist das einfach nur ein Tunnel für meine Anwendung über Ethernet , sodass sich am Server der USB Programmer befindet?
Hallo Arne, Du kannst dn olimex jtag mittels kommandozeilenaufruf überreden, da image zu brennen. Dazu musst du aus dem c# den system aufruf anwenden. Es geht auch mit dem jlink von segger. Adib.
Meine Kenntnis bzgl. STM32 ist eher rudimentär, ich kann also nur sterotyp als dummer Anwender antworten. Ich kenne im Prinzip eigentlich nur den ST-LINK (V2). Mein erster STM32 war ein DiscoveryF3, das kam incl. ST-LINK Anhängsel. Zusätzlich habe ich kürzlich einen chin. Nachbau im USBASP_Format erstanden, beide habe mit der aktuellen FW ausgestattet. Das Programmieren div. STM32F1 geht mit dem STM32 ST-LINK Utility problemlos. Zusätzlich habe ich meiner Arduino-IDE eine STM-Anpassung spendiert. Damit kann man sowohl serial über Uart als auch über den ST-Link proggen. Alternativ kann man einen Bootloader installieren, gibt mehr verfügbare IOs. Um erneut via ST-LINK zugreifen zu können, muss der Bootloader erst entfernt bzw. der Flash gelöscht werden.
Vielen Dank für deine Antwort. Ich bin auf der Suche nach einer Lösung die ich auch im Produktionsumfeld einsetzen kann. IST GDB nicht eher als eine Art Debug-Schnittstelle zu Programmierumgebungen gedacht? Oder wird sowas auch in der Produktion eingesetzt? Mit freundlichen Grüßen Arne
Arne V. schrieb: > ich bin auf der Suche nach einem Programmieradapter(ISP)(SW-DP) für > einen STM32 um meine Abschlussarbeit realisieren zu können. Aha. > Ich würde gerne über Ethernet mittels .NET SDK auf den Adapter zugreifen > können, um so den Flashvorgang zu starten bzw. die Firmware auf den > Adapter zu spielen oder zu löschen. 1. das Leben ist kein Wunschkonzert. 2. anscheinend braucht niemand außer dir so etwas. Also mach es dir halt selber! Das GDB-Protokoll wurde ja schon genannt. Dann braucht man nur noch ein Stück Hardware das an einem Ende USB hat und an einem anderen Ethernet und auf dem ein Betriebssystem läuft das einen zum Adapter passenden GDB-Server unterstützt. Ein Raspberry-Pi mit Linux, Texane stlink und ein ST-Link Adapter reichen ja schon. Alternativ darfst du auch gerne das st-flash Utility aus dem stlink Paket mit einem Netzwerkprotokoll verheiraten um ihm das Image über das Netz zuzuschicken. Und wenn es sein muß kannst du das andere Ende des Netzwerks auch von .Net aus bedienen. Sonderlich sinnvoll ist das natürlich alles nicht, denn der Pi kann das Image ja genauso gut über ein Netzlaufwerk beziehen. Und man kann ein Programm direkt auf dem Pi ausführen (sogar ein .Net/Mono Programm wenn es denn sein muß).
Hi Arne, Der gdb kommuniziert nicht direkt mit dem stm32. Dazu braucht es noch das open-ocd Programm. Das setzt dann die Befehle mittels olimex jtag in die jtag Befehle für den stm32 um. Per script kann openocd auch ohne gdb ein neues image brennen. Du kannst es sicher auch in der Produktion einsetzen. Open ocd, also das treiberprogramm für den olimex arm jtag hat erst mal nichts mit gdb zu tun. Mit open ocd kannst du auch andere jtag adapter benutzen. Adib.
Der STlink V2.1 z.B. von einen Nucleo 32 oder 64 Board stellt auch eine virtuelle Disk bereit. Dann geht das Programmieren auch durch einfaches Kopieren des Programmes. Kann man auch ohne die eigentliche Nutzlast fuer externe STM32 verwenden.
Im Produktionsumfeld benutzen wir ISP Programmer, z.B. von Elnec. Oder gar DataIO...
Arne V. schrieb: > Ich bin auf der Suche nach einer Lösung die ich auch im > Produktionsumfeld einsetzen kann. Kannst Du das genauer erklären? Was ist bei Dir "Produktionsumfeld"? Um was für Stückzahlen geht es? Willst Du da eigene Mitarbeiter ransetzen die da produzieren sollen oder macht das ein externer Auftragsfertiger? Normalerweise verwendet man für das Entwickeln und Debuggen eine andere Lösung als hinterher für die Produktion in größeren Stückzahlen. Beim Entwickeln kommt es auf einfaches Anschließen und schnelles Debuggen an. Hinterher bei der Produktion ist das Debuggen egal, da kommt es auf die Einbindung in die automatisierte Produktions- und Testumgebung und die Programmiergeschwindigkeit an. Oft sind bei der Produktion dann auch noch Dinge wie Boundary Scan und andere automatisierte Testsysteme relevant. Seriennummernverwaltung, Testreports erstellen,... Wenn Du mit einem Auftragsfertiger arbeitest dann würde ich als erstes den fragen was er für Lösungen schon fertig da hat. STM32 sind jetzt keine Exoten, da sollte eigentlich jeder Auftragsfertiger ne Lösung für anbieten können.
Google -> openocd ethernet oder stlink v2 ethernet http://spin.atomicobject.com/2014/04/01/ethernet-adapter-jtag/ bzw. was passt denn an den Flashern von Segger nicht? Ethernet und USB vorhanden, Dokumentation auch https://www.segger.com/flasher-arm.html
Hallo zusammen, man merkt sicherlich an meinen Fragen das ich noch nicht soviel mit dem Flashen von Mikrocontrollern zutun hatte ;). Daher nochmal vielen Dank für die vielen konstruktiven Antworten. Stückzahlen sind überschaubar ich plane in Richtung 7k pro Adapter pro Monat. Das ganze würde ich gerne in eine automatisierte Anlage integrieren steuern will ich den Vorgang aus einem C#-SOAP-Service der auf einem IIS gehostet wird (nicht lokaler PC). Deswegen das SDK, weil ich hier nicht mit Batch-File und irgendeiner GUI arbeiten kann. Im Prinzip bietet PEmicro ein schickes handhabbares SDK an mit welchem man die Firmware auf einem Flasher updaten kann und den Flasher kontrollieren. Leider unterstützt das nicht das .bin Format und man kann nicht über das SDK Daten vor dem Flashvorgang aus dem yC auslesen (Was ich benötige). Es ist derzeit einfach so das wenn man eine hohe Varianz in den Firmwareversionen hat es einfach schlecht zu handhaben ist in der Produktion. Elnec und DataIO betrachte ich heute mal. Bei den Segger-Adaptern arbeite ich gerade noch dran ob sich meine Anforderungen damit decken. Mit freundlichen Grüßen Arne
Bei 7 k/pro Monat auch zu ueberlegen: - vorprogrammierte Bausteine benutzen - Bootloader benutzen
Hallo Uwe, das geht in meinem Fall aus technischen Gründen nicht. Gruß, Arne
Arne schrieb: > das geht in meinem Fall aus technischen Gründen nicht. Ach, du kannst aus technischen Gründen den im Chip bereits vorhandenen und wohldokumentierten Bootlader NICHT benutzen? Sehr seltsam - oder eben ein Designfehler deinerseits. Es ist klar, daß ein SWD-Brenner deutlich schneller sein kann als ein Programmer via Bootlader. Aber das Geschirre für den Bootlader ist deutlich einfacher und deswegen auch einfacher per eigenem Programm zu handhaben. Aber bei 7000 Stück/Monat würde ich auf eine professionelle Technik setzen und dazu einfach Segger kontaktieren. Jaja, kostet Geld, aber so ist das im Leben. W.S.
W.S. schrieb: > Arne schrieb: >> das geht in meinem Fall aus technischen Gründen nicht. > > Ach, du kannst aus technischen Gründen den im Chip bereits vorhandenen > und wohldokumentierten Bootlader NICHT benutzen? Sehr seltsam - oder > eben ein Designfehler deinerseits. > > Es ist klar, daß ein SWD-Brenner deutlich schneller sein kann als ein > Programmer via Bootlader. Aber das Geschirre für den Bootlader ist > deutlich einfacher und deswegen auch einfacher per eigenem Programm zu > handhaben. Aber bei 7000 Stück/Monat würde ich auf eine professionelle > Technik setzen und dazu einfach Segger kontaktieren. Jaja, kostet Geld, > aber so ist das im Leben. > > W.S. Hallo W.S., vielen Dank für deinen Beitrag. Es gibt einfach technische Vorgaben die ich erfüllen muss und dazu gehört es eben keinen Bootloader zu benutzen. Mit Segger stehe ich bereits in Kontakt ;). Es ging mir bei meiner Frage einfach nur darum ob jemand von Euch vielleicht schon mal einen Flasher eingesetzt hat der entsprechende Schnittstellen mitbringt. Geld spielt in meiner Fragestellung weniger einer Rolle deswegen fehlt mir ein bisschen der Bezug zu diesem Punkt. Mit freundlichen Grüßen Arne
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.