Hallo, in Fällen, in denen identische Firmware auf leicht unterschiedlicher Hardware läuft, gibt es meist irgend ein Schema, anhand der die Firmware die Version / Revision der Hardware erkennen kann. (sei es um zu erkennen, dass sie auf dieser Hardware nicht laufen soll, oder um die Funktionsweise leicht anzupassen). Wenn ich jetzt einen Controller habe, bei dem ich GPIO Pins als Eingänge und Ausgänge konfigurieren kann und zusätzlich noch pullup und pulldown Wiederstände an die Pins konfigurieren kann, dann fallen mir folgende Möglichkeiten ein, eine HW Version an ein paar GPIO Pins zu konfigurieren: - Pin offen lassen - Pin hart auf high oder low verdrahten - Pin sehr hochohmig auf high oder low verdrahten - Pin mit anderem Pin verbinden - Pin über Diode mit einem anderen Pin verbinden Fällt jemanden von euch noch andere, günstige Kodierungen ein? Wie komme ich bei obigen Schema auf die Summe aller möglichen Kodierungen, in Abhängigkeit von der Anzahl der Pins? Bei z.B. 3 Pins, wäre es 5 Kodierungen pro Pin plus die möglichen 3 Kodierungen (Verbindung, Diode in einer Richtung, Diode anders herum) in Kombination mit anderen Pins, wären: für den letzten Pin: 5 für den vorletzten Pin: 5 + 3 für den ersten Pin: 5 + 3 * 3 Summe: (5+0) * (5+3) * (5+9) = 560 Richtig? mfg Torsten
LKa schrieb: > Wären das nicht 3 hoch 5 Möglichkeiten? also 243? Aber nur, wenn Du die Kodierungen, die sich in Kombination mit anderen Pins ergeben unterschlägst ;-)
Also bin jetzt nur von 3 Pins mit 5 Möglichkeiten ausgegangen ohne die technische realisierung zu überprüfen.
Aus meiner Sicht würde das die Anzahl an Möglichkeiten eher einschränken als erweitern. Oder sprichst du dann von zusätzlichen Pins?
Wodurch unterscheidet sich deine Hardware? Prozessoren, Speicher und alles was so über SPI, UART, I2C angesprochen wird haben oft ID Regsiter in durch die man z.B. die Art des Prozessors prüfen kann. Ansonsten würde ich einen Spannungsteiler vorschlagen. Durch Änderung eines Bauteils im Bestückungsplan kannst du so >100 Versionen unterscheiden. Das setzt natürlich einen ADC vorraus.
Wenn man davon ausgeht, dass es sich nicht um eine Aufgabe aus der Schule handelt, sondern ein Bezug zur Praxis gegeben ist, kommt doch sofort die Frage, wie viele Hardware Versionen deine Wunderschaltung hat. Dazu dann die immer und überall gültige Regel KISS (keep it simple,stupid), kommt an auf die wenig exotische Lösung "Pin auf VCC oder GND" und kann 8 Versionen verwalten. Ich gestehe, dass ich nur wenig Erfahrung mit embedded Systemen habe, gerade mal 40 Jahre Berufserfahrung, aber mehr als 8 Versionen einer Schaltung hatte ich nie in Produktion.
Georg G. schrieb: > Ich gestehe, dass ich nur > wenig Erfahrung mit embedded Systemen habe, gerade mal 40 Jahre > Berufserfahrung, aber mehr als 8 Versionen einer Schaltung hatte ich nie > in Produktion. Oh, wie das schon wieder vor Sarkasmus trieft ;-) Wenn es nicht die große Menge der HW-Revisionen ist, dann könnte auch einen alten Hasen evtl. der Mangel an freien Pins zu solchen Überlegungen bringen.
Matthias x. schrieb: > Wodurch unterscheidet sich deine Hardware? Prozessoren, Speicher und > alles was so über SPI, UART, I2C angesprochen wird haben oft ID Regsiter > in durch die man z.B. die Art des Prozessors prüfen kann. Ja, guter Punkt. > Ansonsten würde ich einen Spannungsteiler vorschlagen. Durch Änderung > eines Bauteils im Bestückungsplan kannst du so >100 Versionen > unterscheiden. Das setzt natürlich einen ADC vorraus. Und das skaliert dann natürlich sehr schön :-)
:
Bearbeitet durch User
Torsten R. schrieb: > Fällt jemanden von euch noch andere, günstige Kodierungen ein? Du könntest die Pins auch ADC-Eingang konfigurieren und über Widerstandsbestückung Spannungsteiler mit deulich mehr als 5 Zuständen generieren.
Matthias x. schrieb: > Das setzt natürlich einen ADC vorraus Da funktioniert notfalls der Arme-Leute-ADC: Man schaltet einen Kondensator am Pin nach Masse (die Verfechter des wahren Glaubens hier im Forum dürfen einen kleinen Widerstand in Reihe schalten) und einen Widerstand nach VCC. Nun den Port auf GND, etwas warten, Port auf Eingang schalten und warten, bis am Port eine Eins erscheint. Mit wenigen Zeilen Code kann man so durchaus 10 verschiedene Kondensatoren hinreichend genau unterscheiden.
Ich würde eher Versuchen solche Versionsinformationen im Flash mit abzulegen. Die 32Bit Atmel Chips haben dafür eine sogenannte USER Page mit 512 Byte, Da kann man dann auch gleich Abgleichwerte, Seriennummer, und ähnliche Informationen ablegen. mfg
CPP schrieb: > Ich würde eher Versuchen solche Versionsinformationen im Flash mit > abzulegen. Wenn es einfach möglich ist (z.B. 2R + ein Analoger Eingang), dann würde ich immer versuchen, die HW-Version in der Hardware ab zu legen. Das Ablegen der HW-Revision in SW wäre für mich nur eine Notlösung.
Torsten R. schrieb: > dann würde > ich immer versuchen, die HW-Version in der Hardware ab zu legen und Flash ist für dich keine Hardware ???
Ein Jumperfeld mit 3 Pins und mit Dioden/Drahtbrücken bestückt erlaubt eine schier endlose Anzahl von Kodierungen. (Diode in beide Richtungen möglich, nicht bestückt, Drahtbrücke)
Torsten R. schrieb: > Oh, wie das schon wieder vor Sarkasmus trieft ;-) Wenn es nicht die > große Menge der HW-Revisionen ist, dann könnte auch einen alten Hasen > evtl. der Mangel an freien Pins zu solchen Überlegungen bringen. I2C braucht nur 2 Pins. 10 Stk. 24C02 gibt es bei Aliexpress für 0,50E, das sind für mich 5Ct pro Stück. Aber solch eine triviale Lösung kommt für solch einen alten Hasen wie du natürlich nicht in Frage - was soll man dann mit dem freien Pin machen ?
CPP schrieb: > und Flash ist für dich keine Hardware ??? Nein. Du kannst da beim initialen Flashen des Controllers schon einen Fehler machen, den Du nicht machen kannst, wenn Du ein HW-Schema hast. Von Updates mal ganz abzusehen. Hw und SW sind sicherlich unter Version-Kontrolle und da liegt dann sowohl in der HW, als auch in der SW die Versionen fest mit im Repository und es gibt weniger Möglichkeiten, das da etwas schief läuft.
Ein kleines i2c Eeprom das Seriennummer, Produkt ID und Hersteller Name enthält macht mehr Sinn als dein Gefrimmel.
LKa schrieb: > Aus meiner Sicht würde das die Anzahl an Möglichkeiten eher einschränken > als erweitern. Oder sprichst du dann von zusätzlichen Pins? Sorry, jetzt habe ich Dich verstanden. Klar, wenn ich einen Pin hart auf high verdrahte, dann kann ich von da keine Brücke mehr zu einem anderen Pin bauen. Wenn der Pin offen ist, oder hochohmig angebunden ist, dann gäbe es die Möglichkeit aber schon, sodass die Gesamtzahl der Kombinationen schon größer als 5^n wäre.
Agnus schrieb: > Ein kleines i2c Eeprom das Seriennummer, Produkt ID und Hersteller Name > enthält macht mehr Sinn als dein Gefrimmel. Wozu der Aufwand und vor allem die Fehlermöglichkeit? Hersteller Name kommt mir jetzt sehr überflüssig vor. Viele controller haben eine ID, anhand der sich eine Serien-Nummer implementieren läßt.
Agnus schrieb: > Ein kleines i2c Eeprom das Seriennummer, Produkt ID und Hersteller Name > enthält macht mehr Sinn als dein Gefrimmel. Die kann aber der Bestücker nicht unterscheiden. Also hat man keinen Vorteil gegenüber der Programmierung im EEPROM des MCs. Oder man müßte sie vorprogrammieren, extra labeln und extra Bezeichner im Bestückungsplan vergeben, also erheblicher Zusatzaufwand. Da bei mir die MCs meisten eh zuviel Pins haben, nehme ich einfach 8 Eingänge und sehe 8 0Ohm Widerstände vor. Das ergibt 256 Kombinationen. Damit kann auch leicht jeder optisch erkennen, welche Bestückungsversion das ist. Ich schreib daran im Bestückungsdruck: "80 40 20 10 8 4 2 1"
:
Bearbeitet durch User
Torsten R. schrieb: > Wozu der Aufwand und vor allem die Fehlermöglichkeit? Hersteller Name > kommt mir jetzt sehr überflüssig vor. Viele controller haben eine ID, > anhand der sich eine Serien-Nummer implementieren läßt. Ich weiss, du als alter Hase weisst das bestimmt besser, aber ich versuche es trotzdem... a) Weil das gar kein Aufwand ist: - ein 24C02 ist in weniger als 1 Sekunde fertig programiert, sogar mit Zeit und Datum. b) Weil es diese Dinger auch als DIP gibt: - Beim evtl. aufrüsten rausnehmen, neue Version drauf und fertig. Bei deiner genialen Lösung müsste man auslöten/einlöten.
In der Produktion ist es ja so, daß Bestücken und Programmieren verschiedene Abteilungen machen. Ohne harte Kodierung müßte der Bestücker darauf achten, daß er nach dem Bestücken das richtige Label draufpappt, das Label lesbar bleibt und nicht abgeht und der Programmierer müßte es lesen und die richtige Programmierung auswählen. Die Praxis zeigt aber, daß da gerne was schiefgeht. Die Kodierung mit den 8 Widerständen direkt beim Bestücken hat sich daher bestens bewährt. Und die Firmware stellt sofort fest, holla, da hat jemand ein 200V-Modul eingesetzt, ich brauche aber die 400V Bestückungsversion und meldet den Fehler.
:
Bearbeitet durch User
Hallo Marc, Marc V. schrieb: > Ich weiss, du als alter Hase weisst das bestimmt besser, aber ich > versuche es trotzdem... Ich weis nicht, woher jetzt wieder dieses geätzt kommt, schlecht geschlafen? > a) Weil das gar kein Aufwand ist: > - ein 24C02 ist in weniger als 1 Sekunde fertig programiert, > sogar mit Zeit und Datum. Ja, und ein paar passive Bauteile auf der Platine werden vom Bestücker einfach mit bestückt. Eine Änderung in den Produktionsdaten führt automatisch dazu, dass die neue Hardware-Revision sich selbst korrekt identifiziert. > b) Weil es diese Dinger auch als DIP gibt: > - Beim evtl. aufrüsten rausnehmen, neue Version drauf und fertig. Das setzt voraus, dass man eine Hardware hat, die aufrüstbar ist. Wenn ich das hätte, würde ich das in eine Hardware-Revision und eine Ausrüstungsvariante unterteilen. > Bei deiner genialen Lösung müsste man auslöten/einlöten. Wenn ich eine Aufrüstung vorsehen würde, dann würde ich sicher auch vorsehen, die Ausrüstungsvariante zu erkennen. Ich würde es aber auch dann vorziehen, die Ausrüstung eher direkt zu erkennen (z.B. durch irgend welche Tests), als über eine indirekte Beschreibung. Aber selbst wenn das nicht möglich wäre, würde ich dann diese Information eher mit im flash des Controllers ablegen, als in einem externen EEProm. mfg Torsten
Peter D. schrieb: > Die kann aber der Bestücker nicht unterscheiden. Also hat man keinen > Vorteil gegenüber der Programmierung im EEPROM des MCs. Und bei der "Lösung" mit Dioden/Widerständen muss man dem Bestücker gar nichts mitteilen ? Die wissen das im Voraus ? > Oder man müßte sie vorprogrammieren, extra labeln und extra Bezeichner > im Bestückungsplan vergeben, also erheblicher Zusatzaufwand. Vorprogrammieren ja, extra labeln nein - warum auch ? Die Dinger werden: a) Mitgeschickt und gleich mitbestückt. b) Als DIP vorgesehen und später (wenn die bestückte Platine zurückkommt) einfach reingesetzt.
Torsten R. schrieb: > Aber selbst wenn das nicht möglich wäre, würde ich dann diese > Information eher mit im flash des Controllers ablegen, als in einem > externen EEProm. Ich dachte, dein Controller bleibt unverändert nur die Peripherie ändert sich ? Oder soll dein Controller sich selbst anhand der Widerstände identifizieren ? LOL.
Marc V. schrieb: > Und bei der "Lösung" mit Dioden/Widerständen muss man dem Bestücker > gar nichts mitteilen ? Nein. Der lädt nur das gewünschte Pick&Place-File in seinen Bestückungsautomaten. Wir haben nur kleine Stückzahlen und daher wenige Basisplatinen mit vielen Bestückungsvarianten. Die Unterstützung von Varianten in Altium klappt ganz gut. Es kann auch vorkommen, daß Module nachträglich umgebaut werden. Dann enthält die Differenzstückliste auch die neuen Kodierwiderstände. Somit werden die Module immer richtig von der Firmware erkannt.
Peter D. schrieb: > Marc V. schrieb: >> Und bei der "Lösung" mit Dioden/Widerständen muss man dem Bestücker >> gar nichts mitteilen ? > > Nein. > Der lädt nur das gewünschte Pick&Place-File in seinen > Bestückungsautomaten. Sage ich doch. Der File ändert sich nicht von selbst. > Es kann auch vorkommen, daß Module nachträglich umgebaut werden. Dann > enthält die Differenzstückliste auch die neuen Kodierwiderstände. Oder die ganzen neuen Features werden ins eeprom geschrieben und der Bestücker kriegt gar nichts davon (ist auch besser so). > Somit werden die Module immer richtig von der Firmware erkannt. Auch bei der Variante mit eeprom, da wird sogar ein bisschen mehr erkannt. P.S. Nicht, dass ich die Variante mit Eingängen schlecht finde - wir haben das auch mal gemacht, nur mit DIP-Schaltern. Aber dieses Übertreiben mit 560 (!) Zuständen war einfach zu viel für mich...
:
Bearbeitet durch User
Marc V. schrieb: > P.S. > Nicht, dass ich die Variante mit Eingängen schlecht finde - wir > haben das auch mal gemacht, nur mit DIP-Schaltern. > Aber dieses Übertreiben mit 560 (!) Zuständen war einfach zu > viel für mich... 10 Bit sind zu viel, echt jetzt? Unterschiedliche Hardware muss unterschiedlich hardcodiert sein, es braucht ja sowieso einen anderen Bestückungsplan (meine Meinung). Von mir aus können dann die Konfigurationen aus einem EEPROM oder sonst was gelesen werden. Aber die Hardware aufgrund der Einträge in einem EEPROM zu identifizieren halte ich für gewagt / zu fehleranfällig.
Marc V. schrieb: > Oder die ganzen neuen Features werden ins eeprom geschrieben und der > Bestücker kriegt gar nichts davon (ist auch besser so). Ne, das geht bei uns nicht. Die Varianten bestehen immer aus anderen Bauteilen (Strom, Spannung, pos/neg). Nur die Firmware muß nicht neu geflasht werden, die hat ne Liste aller Varianten.
DanVet schrieb: > 10 Bit sind zu viel, echt jetzt? Nein, nur die Art wie das Ganze dekodiert werden soll. > Unterschiedliche Hardware muss unterschiedlich hardcodiert sein, es > braucht ja sowieso einen anderen Bestückungsplan (meine Meinung). Selbstverständlich. > Aber die Hardware aufgrund der Einträge in einem EEPROM zu > identifizieren halte ich für gewagt / zu fehleranfällig. Dem könnte ich auch zustimmen, nur ist die Variante mit Hochohmig/ Niederohmig/ HiZ etc. auch nicht viel sicherer, wenn überhaupt. Das ein ganzes eeprom gelöscht wird, ist nur in sehr, sehr seltenen Fallen möglich, eher einzelne Zellen oder Pages. Deswegen wird die Konfiguration doppelt oder dreifach geschrieben, Platz ist genug da. Wie gesagt, wir haben das mit DIP-Schaltern gemacht, 0Ohm Widerstände gehen natürlich auch, nichts dagegen einzuwenden. Aber 560(!) Versionen ? Blödsinn, einfach Blödsinn und nichts anderes.
Peter D. schrieb: > Ne, das geht bei uns nicht. Die Varianten bestehen immer aus anderen > Bauteilen (Strom, Spannung, pos/neg). Nur die Firmware muß nicht neu > geflasht werden, die hat ne Liste aller Varianten. Ich weiss was du meinst, finde es auch OK, nur die 560 Varianten beim TO halte ich für absoluten Blödsinn.
Georg G. schrieb: > Ich gestehe, dass ich nur > wenig Erfahrung mit embedded Systemen habe, gerade mal 40 Jahre > Berufserfahrung, aber mehr als 8 Versionen einer Schaltung hatte ich nie > in Produktion. Das will ich meinen. Man kann einfach mit pullups und downs arbeiten, macht bei 3 Pins 8 Versionen und 3 umzutötende Widerstände. Das geht auch in der Fertigung nochmal manuell. Schwierig wird es nur, wenn der Kunde nicht erkennen soll, dass eine neue HW-REV vorliegt. Wir hatten das mal so, daß ein RC-Glied mit einem wechselden Spannungsteiler versehen wurde. Dann konnte man den RC anschubsen und das Ausrollen der Kurve messen. Mit unterschiedlichen Rs ergab das 15 Kombinationen = Zeiten.
Hallo, Laufen die Platinen denn nicht über einen Testplatz? Der sollte ja die richtige Bestückung überprüfen können (Konfiguration) und im µC /EEProm die HW-Version festhalten. Die "Konfiguration" des Testplatzes auf eine bestimmte HW könnte über Bohrungen in der Platine vorgenommen werden (billiger als Widerstände und jederzeit erweiterbar, solange noch Platz auf der PCB ist). BG, Tom
Tom schrieb: > Laufen die Platinen denn nicht über einen Testplatz? Der sollte ja die > richtige Bestückung überprüfen können (Konfiguration) und im µC /EEProm > die HW-Version festhalten. Wo siehst Du den Vorteil gegenüber einer impliziten Festlegung der HW-Version in den Bestückungsdaten?
@Torsten Auch ein Widerstand kostet Geld und sei es nur über die Setzkosten beim Bestücken. Wie gesagt, ich würde erwarten, dass die Platine auch am Produktionsende mal getestet wird. Bei diesem Schritt kann die SW auch über die HW informiert werden. Und wenn dort falsch, d.h. mit der falschen Bestückungsoption getestet wird, ist sowieso was im Prozess faul. BG, Tom
In einer vernünftigen Fertigung gehört die konkrete Flash Inhalt genau so in die Bestückungsliste wie alle andere Bauteile. daher gibt es aus meiner Sicht keinen Unterschied ob man etwas per HW Pins oder über einen Speicherinhalt konfiguriert. Über eine Konfiguration im Speicher kann man auch dann noch ein unterschiedliches Verhalten der Firmware steuern, wenn die HW Bestückung identisch ist
Interessante Diskussion, wenn man genügend freie Pins hat gefällt mir die Lötbrücken- oder Widerstandslösung sehr gut. Mit einem Blick auf die Platine erkenne ich die Version. Aber die EEprom Lösung finde ich auch super. Viele Bedenken teile ich nicht - fehleranfällig warum ? Der Controller wird doch auch geflasht. Bestückungsaufwand welcher ? ob ich Widerstände bestücke oder ein IC macht doch keinen Unterschied. Dokumentation - tut mir leid beide Varianten müssen ordentlich dokumentiert werden, daß krank eher an den internen Prozessen als an dem Ansatz. Was mir noch gut gefällt ist die Tatsache weitere Infomation im Prom zu speichern wie Datum, PCB Hersteller, Bestücker, Tester, usw. Thema Rückverfolgung, Fehlersuche. Werden Geräte,Platinen 'Verhaltensauffällig' könnte man über diese Information (die ausgelesen werden können ohne das Gerät aufzuschrauben und die der Kunde selber ermitteln kann) versuchen Gemeinsamkeiten zufinden z.B. Montagsgeräte vom Bestücker X. Zum Aufwand: da der Controller auf der Platine sowieso programmiert werden muß könnte man im gleichen Arbeitsgang den Controller anweisen die Informationen ins Prom zuschreiben. Wo ich allerdings recht gebe ist die Tatsache das man sich die Tools (Software event.Hardware) erst noch erarbeiten muß.
:
Bearbeitet durch User
Wenn es denn doch ein EEPROM werden soll (ich hab die ganze Diskussion nicht gelesen), dann sieh dir diesen mal an: DS28E05 Der ist von Maxxim, kostet nicht viel aber das Gute kommt noch. Er kommt im SOT-23 Gehäuse, braucht nur Masse und Datenleitung. Letztere ist gleichzeitig auch die Spannungsversorgung und du brauchst nur einen zusätzlichen Pull-Up Widerstand. Er hat intern schon eine eindeutige 64Bit ID ab Werk vergeben. Einziger Nachteil du musst den 1-Wire Bus auf deinem Mikrocontroller implementieren. Dafür kannst du mehrere davon an einem einzigen Pin deines Controllers anschließen (z.B. wenn mehrere Hardware Boards im Spiel sind).
:
Bearbeitet durch User
Taz G. schrieb: > Zum Aufwand: da der Controller auf der Platine sowieso programmiert > werden muß könnte man im gleichen Arbeitsgang den Controller anweisen > die Informationen ins Prom zuschreiben. Warum dann nicht gleich mit in das flash des Controllers? (siehe Vorschlag von CPP)
> Warum dann nicht gleich mit in das flash des Controllers? (siehe > Vorschlag von CPP) Ich hatte schon auf Absenden geklickt. -> Super Idee Null Aufwand nur ein bisschen Software. Habs mir gerade bei meinem MC angeschaut.
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.