Hallo, ich möchte auf einer Leiterplatte 8 ATTiny zur Regelung von 8 Kanälen einsetzen. Die Kommunikation zur Aussenwelt (Webinterface) soll mit einem STM32 gemacht werden. Meine Frage: Wie kann ich mit dem STM32 alle ATTinys programmieren? Ich möchte nicht alle 8 Kanäle einzeln flashen bzw. Pins dafür auf dem PCB implementieren. Hat wer eine effiziente Idee? Gruß, Micha
PS: Ich würde statt der Tinys natürlich auch Alternativen verwenden. Bspw. PIC. Sollte nur ähnlich preiswert (~1,-€) sein und ADC und PWM bieten.
Micha Selen schrieb: > Hat wer eine effiziente Idee? einen Bootlader auf den Tinys, angesprochen über die nicht genannte Verbindung zum STM32
Dann muss doch aber trotzdem einmalig ein Bootloader auf die Tinys, oder nicht?
Hi >Die Kommunikation zur Aussenwelt (Webinterface) soll mit >einem STM32 gemacht werden. Warum machst du dann nicht gleich alles mit dem STM? MfG Spess
Kenne ich. Aber wie kann ich nun alle acht mit möglichst wenig Leiterbahnen, bspw. in einem Daisy-Chain, programmieren?
Hi, Micha Selen schrieb: > Hallo, > > ich möchte auf einer Leiterplatte 8 ATTiny zur Regelung von 8 Kanälen > einsetzen. Die Kommunikation zur Aussenwelt (Webinterface) soll mit > einem STM32 gemacht werden. > > Meine Frage: > Wie kann ich mit dem STM32 alle ATTinys programmieren? Ich möchte nicht > alle 8 Kanäle einzeln flashen bzw. Pins dafür auf dem PCB > implementieren. Hat wer eine effiziente Idee? Fuer die Urprogrammierung (Erstprogrammierung)? Die meisten AVR lassen sich doch per SPI programmieren. Dazu brauchst du die drei SPI Leitungen und die Reset Leitung welche als !CS funktioniert. Es kommt ein Wenig auf deine sonstige Schaltung an, aber wenn da von der Belegung sonst nichts im WEge steht könntest du die beiden Datenleitungen sowie CLK Leitungen aller 8 AVR parallel an einen SPI des STM hängen und den STM das Programmieren überlassen. Musst halt den Programmieralgorythmus implementieren. Die Resetleitungen musst du dabei natürlich getrennt zum STM führen, die sind ja das Chip Select signal mit dem ausgewählt wird welcher AVR gerade programmiert wird. Wird aber natuerlich schwierig wenn man ausgerechnet die zum programmieren notwendigen IO auch anderweitig benötigt. Sollte es dir aber nur um evtl. Firmwareupdates und nicht um die Erstprogrammierung gehen: ProgPunkte nahe der einzelnen AVR für die Erstprogrammierung, dann einen eigenen Bootloader schreiben der seine Progdaten über die Schnittstelle erhält über die der STM sowieso mit den AVR kommuniziert.. Micha Selen schrieb: > PS: Ich würde statt der Tinys natürlich auch Alternativen verwenden. > Bspw. PIC. Sollte nur ähnlich preiswert (~1,-€) sein und ADC und PWM > bieten. Ein Euro... So viel für einen kleinen PIC. ODer meinst du die Luxusversion mit goldenem GEhäuse. Schaue dir mal an was aktuelle "kleine" Pic kosten (60ct. bei 10pcs) und was die dafür an HArdware intus haben. BEispielsweise PIC16F1503 (Nur der vollständigkeit halber: Die Aktuellen PIC16 haben mit den alten PIC16 nicht mehr viel gemeinsam. Die entsprechen da eher den PIC18 beim Programmieren und sind auch ohne Abstriche fuer den Einsatz mit C Compilern gedacht. Bei den älteren 16er wurde das bei den kleineren Typen ja manchmal schon sehr kniffelig) Aber um das klarzustellen. Notwendig ist der EInsatz eines Pics für dein Problem nicht. ES würde es höchstens wegen der etwas einfacheren ICSP Schnittstelle Hardwaremäßig ganz geringfügig vereinfachen... Zudem sind die PICs wegen der großen Auswahl an HArdware gerade für Spezialfälle generell nicht schlecht. Aber für die allermeisten Anwendungen spielt die Frage ob PIC oder AVR keine Rolle. Und wenn es nur um die Fertigstellung des Projektes geht und du bereits AVR kennst kannst du dabei daher auch ruhig bleiben. Gruß Carsten
Hi
>Soll ein dezentraler Aufbau sein
Auf einer Leiterplatte?
MfG Spess
Ansonsten was auf der LPC Familie von NXP (STM dürfte auch gehen). Die lassen sich über die serielle Schittstelle programmieren (könnte man alle parallel schalten, nur die entsprechende "Aktivierungs"-Leitung müsste man separat führen. Auf TTL-Ebene alles was für wenige Centimeter auf dem Board. Dezentral im Sinne von mehreren Metern(?) würde sinnvoll nur mit Bootloader funktionieren. Um welche Stückzahl geht es denn? Zig-tausende?
Die einfachste Lösung wurde ja schon genannt, einen einzelnen SPI an alle AVRs und dann nacheinander via RESET selektieren (z.B. mit Schieberegister wenn nicht genügend I/Os am STM frei sind). Wenn unterschiedliche µCs möglich sein sollen kommt es darauf an ob alle einen identischen Programmiermodus haben (JTAG o.ä.) oder mit genanntem Bootloader z.B. via I2C oder UART oder OneWire programmiert werden können. Dann muß man halt vorher den Bootloader drauf haben. Günstige STMs mit USB samt Loader gibt's auch schon unter 5€. Was soll's denn konkret werden ? 8 Kanäle mit 8 einzelnen AVRs ist bissle wenig an Infos ... Vor allem wenn man einen dickeren STM mit genügend I/Os für Web und Kanäle nehmen kann. Oder meinst Du pro AVR 8 Kanäle ?
roflkopter schrieb: > Dann muß man halt vorher den Bootloader drauf haben. Ein Bootloader ist nett, wenn man öfter neu programmieren muss, z.B. während der Entwicklung. Für die Erst-Inbetriebnahme nützt er garnichts, es sei denn er ist ab Werk schon installiert, aber das ist nicht üblich. JTAG lässt sich kaskadieren, man braucht also keine Leitungen um einen bestimmten Prozessor zu adressieren, aber eine Software, die einen bestimmten Device in der Chain ansprechen kann - das könnte eher noch schwieriger werden, wenn die Programmierung automatisch für n Devices ablaufen soll. Normalerweise hat man da eine IDE und kann in der einen bestimmten Device selektieren, aber dann ist die Programmierung von 8 Chips eben doch Handarbeit. Alternativ kann man sich sowas anschaffen: http://www.goepel.com/jtag-boundary-scan/boundary-scan-instrumente/hardware/controller.html Georg
Georg schrieb: > Ein Bootloader ist nett, wenn man öfter neu programmieren muss, z.B. > während der Entwicklung. Was für ein Quatsch! Gerade da ist JTAG wichtig wegen der Geschwindigkeit. Georg schrieb: > Für die Erst-Inbetriebnahme nützt er garnichts Quatsch^2! Siehe unten. Georg schrieb: > es sei denn er ist ab Werk schon installiert, aber das ist nicht üblich. Quatsch^3. Die meisten neueren uC haben einen Bootloader im ROM. Genau dafür ist so ein Teil gut. Um ein FW update ohne spezielle Programmieradapter vor zu nehmen. Eine vernünftige Schnittstelle zwischen den Controllern reicht aus. z.B alle über UART verbunden (oder RS485 bei größeren Entfernungen). Beim ersten mal muss man da evtl nachhelfen mit einer Brücke am Slave (wird bei KNX auch so gemacht). Da bekommt er dann eine ID wo er später drüber adressiert wird. Bei den darauf folgenden Male schickt der Master ein Kommando an entsprechenden Controller (Adressiert über ID), der springt dann in den Bootloader. Anschließend wird das Programm übertragen. Ferdisch!
Allgemein spricht doch sicher nichts dagegen, am Prüfadapter die Tinys mit einem seriellen Bootloader zu programmieren? Das kostet nur ein paar Prüfpunkte. Alternativen: Die STM32 hätten einen Bootloader fix drin, der über fast jede Schnittstelle funktioniert. Da brauchts diese BOOTx-Pins, die setzt man richtig, und booteet dann z.B. über die UART. Man könnte daher statt den Tinys die billigsten STM32F030 nehmen. Hätte den Charme, alle µCs mit einer Toolchain bearbeiten zu können. Bei den PICs könnte man die kleinen PICs bei Microchip mit Bootloader fertig programmiert ordern. Microchip direkt macht das auch für 1 Stück: https://www.microchipdirect.com/programming/FAQNew.aspx Kostet halt was. Sicher kann man das auch für ATMELs machen lassen (natürlich nicht bei Microchip direkt...)? Am Besten ist, die ganzen µCs als JTAG-Chain verdrahten, dann kann man die mit einem einzigen Stecker programmieren. Dafür braucht man allerdings µCs mit JTAG. Keine Ahnung, ob die Tinys das haben.
Micha Selen schrieb: > ich möchte auf einer Leiterplatte 8 ATTiny zur Regelung von 8 Kanälen > einsetzen. Die Kommunikation zur Aussenwelt (Webinterface) soll mit > einem STM32 gemacht werden. Mit 95%-iger Wahrscheinlichkeit ist das ein konzeptioneller Fehler. Was "regelt" der Tiny? "Regelt" er tatsächlich? Wie ist er mit dem STM32 verbunden? Wie soll kommuniziert werden? Um welchen Tiny, um welchen STM32 handelt es sich? usw. usf. Das Problem steckt oft im Detail bzw. im Ansatz. Bitte beschreib Dein Projekt näher: http://www.mikrocontroller.net/articles/Netiquette#Klare_Beschreibung_des_Problems
Die 8 Kanäle entsprechen 8 SMPS die jeweils von einem ATTiny, PIC, oder auch dem 32F030 geregelt werden sollen. Die sollten dann per I2C oder SPI (müssste ich zum programmieren ja ohnehin benutzen) kommunizieren. Der "große" soll dann zur Überwachung/Steuerung ein Webinterface bereitstellen.
Micha Selen schrieb: > Meine Frage: > Wie kann ich mit dem STM32 alle ATTinys programmieren? Ich möchte nicht > alle 8 Kanäle einzeln flashen bzw. Pins dafür auf dem PCB > implementieren. Hat wer eine effiziente Idee? Ich stelle mal in den Raum, dass man während der Entwicklung von 8 gleichen Baugruppen, nicht bei jeder Programmänderung immer alle 8 Baugruppen flashen wird. Während der Entwicklung sind 7 Baugruppen stillgelegt und man arbeitet mit lediglich einer. Für diese eine die entsprechenden ISP Pins auf der Platine vorzusehen, sollte dann ja nicht das große Problem sein. Dir Tinys werden natürlich gesockelt. Man hat dann einen Sockel, in dem man einen Tiny flashen kann. Ist die Entwicklung soweit abgeschlossen, dass der eine 'Kanal' sauber funktioniert, so dass weitere Programmänderungen im Tiny selten werden, dann programmiert man nacheinander die 8 Tinys auf diesem einen Sockel und verteilt sie auf die nicht flash-faähigen Sockel. Das ist kein wirklicher Mehraufwand, keiner muss irgendein Protokoll oder Brennsoftware für den STM inklusive Brenn-Frontend auf dem PC schreiben, billig in Material und Arbeitszeit und ist nur eine Frage der Organisation während der Entwicklung. Um auf absehbare Zeit 2 oder 3 mal im Monat 5 Handgriffe einzusparen lohnt sich tage- oder wochenlange Sonderentwicklung nicht. Insbesondere nicht bei einem Einzelstück. Wenn der Service Techniker rausfahren muss um 500 derartige Schaltungen auf den neuesten Stand zu bringen, sieht es natürlich anders aus. Die gesparte Zeit steckt man lieber in eine möglichst gute Implementierung der Regelung für die Schaltnetzteile. Das wird schon schwer genug.
:
Bearbeitet durch User
Bitte 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.