Guten Morgen alle miteinander, Mich würde interessieren, was Ihr für die modernsten / ökonomischsten Programmierverfahren haltet um die oben genannten Bausteine zu programmieren? Dabei geht es vorallem um Schnelligkeit (Programmierzeit) aber auch um Flexibilität, d.h. kein zusätzlicher Lagerbestand an Programmieradaptern, kann man später beim Kunden direkt programmieren usw. Dankeschön! Beste Grüße Manuel
So komplett ohne weitere Rahmenbedinungen würde ich sagen: Der µC hat eine Internetverbindung und lädt sich die aktuelle Firmware selber runter und installiert sie.
Daher das massig Möglichkeiten offen gelassen wurden würde ich eine Handelsübliche Speicherkarte z.B. SD wählen. Hat fast jeder, kann nahezu jeder Beschreiben, ist günstig. Nachteil wäre natürlich das man ggf. zusätzliche µC / größere µC in jeder Schaltung haben müsste. Vorteil wäre das man es sehr leicht einheitlich aufbauen kann, auch wenn die Daten teilweise sehr unterschiedlich codiert sind. Weiterer Vorteil wäre zudem das es die Datenspeicher noch ewigkeiten geben wird (*Persönliche Meinung).
Ok, habe mich vielleicht etwas sehr schlecht ausgedrückt : Es geht vor allem um die Programmierung des embedded flashs bei STM32 Prozessoren aber auch um die Programmierung von externen Flash / EEProm Bausteinen. Internetverbindung ist dabei nicht vorgesehen, Als Peripherie würde ich die des STM32 Prozessors voraussetzen : http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_DIAGRAM/CIRCUIT_DIAGRAM/circuit_diagram_15060.pdf Werden heutzutage eigentlich noch Programmieradapter eingesetzt? Wenn ja wieso? Man kann ja theoretisch solche Bausteine auch in-circuit programmieren, somit ist man flexibler.. Oder ist diese Art der Programmierung deutlich langsamer? Danke!
eeproms kann man üblicherweise mit spi oder i2c beschreiben. im den chip zu beschreiben benötigt man den programmer/debuger ... den kannst du auch in-circuit raufbringen aber das nimmt ja dann wieder platz weg ;) und bei großen herstellungenszahlen nutzt man nicht unbedingt auf jeder platine diese dann, das sollte man sich gut überlegen
Ok, Danke für die Info.. hab mich jetzt noch etwas mit dem STM32 beschäftigt und da ist mir aufgefallen das dieser einen integrierten Bootloader vorzuweisen hat. Diesen kann man über USART CAN USB DFU seriell programmieren. Nun meine Frage : Hat dieses Verfahren Vorteile gegenüber einer Programmierung über JTAG? (Programmierzeit , Zuverlässigkeit usw..) Danke!
Beitrag "Flash Programmierzeiten vergleichen" Gestern war es noch ein anderer µC. Kannste nicht mal sagen, was Du eigentlich willst?
Das eine istn Beispiel das ich gefunden hatte, dass andere nen Microcontroller den wir verwenden.. Darf man denn nicht Informationen zu zwei Bausteinen einholen? Keine Ahnung, soll aber vorkommen das man sich über mehr als einen Baustein informiert.. Was ich genau will : Ich möchte verschiedene Programmierverfahren ( UART / JTAG ) usw. hinsichtlich ihrer Programmierzeit, Flexibilität usw miteinander vergleichen. Dabei geht es um den Prozessor STM32F103C4. Um dies zu tun muss ich erstmal wissen wie man die ganzen Zeiten berechnet. Über JTAG (Boundary scan) weiß ich mitlerweile wie ichs berechne, bei UART tu ich mir noch schwer. Außerdem möchte ich wissen obs vielleicht noch ökonomischere Verfahren als diese beiden gibt, wenn ja welche. Das ist ein Teil meiner Aufgabe Der andere handelt um Testverfahren und auch dort besonders um Boundary Scan..
Manuel Reisser schrieb: > Außerdem möchte ich wissen obs vielleicht noch ökonomischere Verfahren > als diese beiden gibt, wenn ja welche. Beim Hersteller programmieren zu lassen, kostet keine Zeit. Ich weiß immer noch nicht, wo das Problem ist. Geht es um 1 pro Tag, der zu programmieren ist, oder um 10000? Wenn Ihr den µC schon verwendet, probiere es doch einfach aus.
Ja, deine Fragen klingen sehr theoretisch obwohl du scheinbar kein Hintergrundwissen hast und sowas scheinbar noch nie selbst ausprobiert hast. Praktikum? So als Hausnummer, hier auf dem Schreibtisch STM32 256kB mit ULINKpro(50MHz) von Keil braucht das Flashen ca. 10 Sekunden. In der Produktion nehmen wir ein STlink, der braucht ungefähr 40 Sekunden. Hängt also auch von den Tools und der verwendeten Software ab. Bootloader dauert wesentlich länger weil der UART halt wesentlich langsamer ist.
Hallo ttl, Hallo Willi Bachelorarbeit und du hast recht, ich habe noch keine nennenswerte praktische Erfahrungen was das Thema angeht.. Im Studium (Elektrotechnik) lernt man halt viel Theorie aber am Ende hat man trotzdem keinen Plan ;-) Dort wird halt mit UART programmiert, ist ja auch nur für die Studenten im Labor und Programmierzeit interessiert dort keinen Menschen.. Ist mehr ne Theoriearbeit bei der ich Optimierungsmöglichkeiten in der Produktion aufdecken soll. Benutzt ihr den STM32 in der Produktion denn schon? Aus was für einem Grund verwendet ihr denn den langsamen Debugger zum Flashen in der Produktion? Gerade dort sollte es doch auf Schnelligkeit ankommen oder irre ich mich? @Willi : Naja, der wird die Programmierarbeiten schätze ich mal auch nicht umsonst machen, oder? Ausprobieren ist schlecht, der STM32 ist gerade erst im Einführungsprozess, er wird noch nicht in der Produktion verwendet! Und es soll um ein relativ hohes Volumen gehen, würde sagen 100++/Tag je nach Auftragsbestand Danke euch beiden!
Manuel Reisser schrieb: > Und es soll um ein relativ hohes Volumen gehen, würde sagen 100++/Tag je > nach Auftragsbestand Dann solltest du auch bedenken, was die Hardware für dein gewünschtes Programmierverfahren pro Board kostet. Wenns nur auf die Programmierzeit ankommt, JTAG, da braucht du aber auf jeden Fall den Header auf dem Board und die Zeit, die das Anstecken und Abstecken des Programmierers kostet. Hat das Teil sowieso schon Schnittstellen, nimmst du eine von denen - programmiert etwas langsamer, aber du hast null Hardwarekosten extra. Ist Hacken ein Problem? Wenn du befürchtest, das Kunden an der Firmware rumfummeln wollen, sind da ein paar extra Vorkehrungen zu treffen.
Hallo Matthias, was meinst du mit Hardware pro Board? Bei Programmierung über JTAG brauch ich doch nur die Steckerleiste auf dem Board und z.B. ein paar STlink, die sind ja relativ günstig.. Mit dem Anstecken und Abstecken hast du natürlich recht! Sicherheit ist ein Punkt der auch zu betrachten ist, aber was kann ich da für Vorkehrungen treffen? Welche der vorhandenen Schnittstelle würdest du denn bevorzugen? Danke, hilfst mir auf jedenfall weiter! Gruß Manuel
Hab grad zum Thema Sicherheit ein wenig nachgelesen was den STM32F103 angeht. Also der hat ne Read und ne Write protection die man durch setzen eines Bits "einschalten" kann. Sowas meinst du als Hackingschutz, oder?
Für mich stellt sich eine andere Frage: Geht es ausschließlich um die Erstprogrammierung oder auch um spätere Firmware-Updates? Ich würde sagen: - Nur Erstprogrammierung und (sehr) hohe Stückzahl: mal den IC-Hersteller oder den Bestücker fragen, ob es es macht. - Nur Erstprogrammierung und keiner macht's für Euch: JTAG oder Bootloader über externe Schnittstelle (USB, UART, CAN, Ethernet usw.) - Firmware-Update: Bootloader über externe Schnittstelle (USB, UART, CAN, Ethernet usw.)
Hallo Bronco, was hat denn eine Programmierung über den Bootloader für Vorteile gegenüber einer Programmierung über JTAG / SWD? Danke!
Manuel Reisser schrieb: > was hat denn eine Programmierung über den Bootloader für Vorteile > gegenüber einer Programmierung über JTAG / SWD? 1. Weil i.d.R. eine JTAG-Schnittstelle nicht aus dem Gehäuse herausgeführt ist. Wenn man nun den Bootloader über eine externe Schnittstelle (über die normalerweise andere Aufgaben laufen als das Firmware-Update) ansprechen kann, muß man das Gehäuse nicht öffnen. 2. Weil man für JTAG-Programmieren ein spezielles Hardware-Tool benötigt, während man den Bootloader über die externe Schnittstelle über die Gegenstelle (z.B. PC) ansprechen kann. 3. Weil man an die JTAG-Schnittstelle ggf. einen Debugger anschließen und damit die Firmware auslesen und hacken kann (z.B. bei Auto-Motorsteuergeräten ein Problem, weil "Chip-Tuning" den Motor überlasten kann). Bootloader sind Software und können mit beliebigen Sicherheitsvorkehrungen versehen werden. Was ist "SWD"?
Guten Morgen Bronco, Mit Punkt 1 und Punkt 2 hast du mit Sicherheit Recht, Punkt 3 kann man glaub ich weniger stark werten da der STM32F1 über eine Write/Read Protection verfügt die man aktivieren kann, somit sollte die Software auch bei Verwendung von JTAG/SWD vor Hacking geschützt sein. SWD sollte aber auch (laut dem Sheet von Uwe) schneller sein als die Programmierung über bootloader (anscheinend bis zu 4MB/s wohingegen Booloader über UART1 ca 115KB/S und Booloader über CAN ca 1MB/s hätte) Sind die von dir genannten Vorteile trotzdem stärker als die kürzere Progzeit von SWD? Danke!
Manuel Reisser schrieb: > Sind die von dir genannten Vorteile trotzdem stärker als die kürzere > Progzeit von SWD? Also das kannst wirklich nur Du wissen. Ich kenn Dein Projekt und die Anforderungen nicht.
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.