Hallo Zusammen Ich habe versucht die Dauer eines Befehls aus der Docu heraus zulesen, ich möchte errechnen ob ich einen externen UART mit SPI (Max. 18Mbps) oder einen UART mit parallem Bus als Ansteuerung verwenden soll. Beim UART verwende ich als Baud 4Mbps, das Gegenstück (die Peripherie Baugruppen) gibt es schon. Ich benütze zwar C aber über die diverse Listing kann ich das sicher herausrechnen oder hat jemand eine andere Idee. Bitte. Danke. Lg. Johann K.
Bei immer gefüllter Pipeline und Caching 12.5ns je Befehl. Aber das ist eher als theortisch zu sehen, da aufgrund von Sprüngen etc. die Pipeline nie ganz voll ist bzw. geflusht werden muss. UART mit parallel Interface mit SPI gibt es nicht. Die meinst wohl die normalen SPI und PMP Module. Der SPI kann mit max 40MHz laufen, das PMP mit 80MHz PCLK. Dann kannst du ja abschätzen was schneller ist... PMP wird so bei 5 bis 6 PCLK liegen (siehe PMP Datenblatt), SPI 8 PCLK für den Takt. Dann kommt noch ein wenig Delay bis die entsprechenden Bit gesetzt sind und der Controller merkt dass etwas empfangen / gesendet wurde, sowie Zeit für CS etc. Nur du kannst wissen was besser ist, da nur du die Specs kennst...
Hallo Johann, leider ist es bei (fast?) keinem 32Bit µC möglich die Programmlaufzeit einfach nur anhand einer Tabelle aus dem ASM Code zu berechnen. (Direkt aus C geht sowieso nie, dazu muss man sich immer den (generierten) ASM code ansehen, auch bei 8Bit wo solch eine Laufzeitanalyse in der Regel problemlos möglich ist) Es gibt zwar Tabellen wo man die "typische"(eher "minimale") Zahl der benötigten Systemttakte für einen Befehl nachschlagen kann, aber die tatsächliche Ausführungsdauer für jeden einzelnen Befehl kann trotzdem stark abweichen. So ist es durchaus nicht unüblich das bei bestimmten Befehlen wie Speciher- oder Periepheriezugriffen automatisch sogenannte WaitStates durch den µC durchlaufen werden müssen weil das Angesprochene Ziel noch gar nicht bereits ist oder aber auch weil es einfach nicht schnell genug reagieren kann. Diese WaitStates sind somit Abhängig von angesprochenem Ziel, von der Geschwindigkeit des µC, von der Geschwindigkeit der Peripherie (bei interner Peripherie des PIC vom Periepherietakt) und auch manchmal vom vorher abgearbeiteten Befehl. Aber auch bei de rProgrammausführung selber kann es zu eingeschobenen Verzögerungen kommen. So wird ja bei der Abarbeitung des aktuellen Befehls die Ausführung der nächsten Befehle bereits vorbereitet, die folgende Befehle werden in eine Art "Pipeline" geschoben daher der Begriff Pipelining. Bei bestimmten Befehlen wie bedingten Sprüngen aber wird diese Ababeitung unterbrochen und die Pipeline muss quasi geleert und neu gefüllt werden, einfach weil der µC ja vorher da Sprungziel noch gar nicht kennen konnte. Aus dies bringt dann wieder WaitStates mit sich. Natürlich ist es in der Theorie möglich al das mit zu berücksichtigen und so doch eine Timinganalyse zu machen, ABER in de rRealität ist das zu komplex als das man dies von hand könnte. Für eine µC gibt es da sicher Softwaretools, aber ob für die PIC32... Habe ich bisher zumindest nicht gebraucht. Aber zu deinem aktuellen Problem: 4Mbit sind schon eine Menge holz, aber wenn die richtigen Vorraussetzungen vorliegen für einen potenten µC wie dem PIC32 noch sehr bequem machbar. MAn darf halt nicht mehr von den vorrausetzungen für Software UART ausgehen wie man es in den µC Frühzeiten gemacht hat sondern man bedient sich der Peripherie. Bei der Entscheidung ob SPI oder Parallel würde ich als erstes mal Prüfen ob die Problemlos mit der internen Peripherie des PIC zusammenarbeiten. Für SPI ist das wohl kein Problem bei Parallel muss man sich dann den PMP ansehen. Wenn da keine einache Zusammenarbeit möglich ist, dann fällt das schon mal raus. Das rein in Software abzuhandeln ist unnötig kompliziert und bei 4Mbit auch sehr Auslastend. Und dann würde ich mal schauen was deinem sonstigen Programm so entgegen kommt. über den PMP kannst du mit DMA Transfer arbeiten, dieser muss aber bei jedem Wort stattfinden. Die "Verarbeitung kann dann ja beliebig säter stattfinden. Die Häufigkeit der Transfers ist dabei natürlich umgekehrt Proportional zur Bandbreite... Bei SPI kannst du die internen FIFO Buffer nutzen. der PIC32 hat ja je einen 128Bit Buffer für Senden und empfangen, was beispielsweise 16 Byte = 16 8Bit Datenwörter über UART entspricht. Wenn du auf der Unteren KAnnte agierst und dabei trotzdem annimmst das der UART voll ausgelastet ist, was bedeutet das du in einem einzigen Event das alle (ca.) 32µs erfolgen muss reagieren musst und die Buffer TX füllen/ RX leer musst. 32µs sind bei einer Taktdauer von 12,5ns eine Menge Zeit für andere Dinge, ganze 1256 Takte... (Wobei der Aufruf natürlich nicht ZEitgesteuert erfolgen soll sondern durch den internen Interrupt des FIFOS) Da ein mit 4MBit spezifizierter UART aber nur selten -eher so gut wie nie aufgrund Start & Stopbit + unspezifizierter Pausenzeit wirklich mit 4Mbit Nutzdaten überträgt ist die Reale zwischenzeit viel viel länger. Wenn der externe UART selber auch noch mal Buffer hat und du noch schneller auf SPI die Daten überträgst (18Mbit sind für den PIC KEIN Problem) dann verlängert sich die Pause zwischen den NOTWENDIGEN Events noch um ein entsprechendes. NAtürlich würde ich nicht so auf Kante planen und noch GUT Reserven lassen falls der PIC gerade in einem höher Priorisiertem Interrupt feststeckt, aber allgemein denke ich das sich das über SPI fast bei jeder Programmstruktur gut händeln lässt. Ich habe diese Betrachtung jetzt hier nur für SPI gemacht, für PMP musst du das dann selber machen. Im Anschluss kannst du dann sehen ob dir die 128 Buffer oder aber der DMA Transfer bei deinem Programm die größeren Vorteile bringen. ICh persöhnlich würde aber SPI bevorzugen, alleine schon da man da nur drei Leitungen verbinden muss. Zudem bleiben mehr Leitungen für andere Dinge frei. Anders sähe es natürlich aus wenn der SPI schon ausgelastet währe. Gruß Carsten
Angehängte Dateien:
-
Bild.jpg
870 KB -
Bild_001.jpg
1,2 MB -
Bild_002.jpg
830 KB -
Bild_003.jpg
880 KB
Danke für eure Anworten Hallo Carsten deine ist ja wieder riesig augefallen. Mit dieser Schnittstelle, die sich auf der MCU (Master) befinden wird, muss ich je nach Bestückung max.16 ext. Baugruppen bedienen die wie gesagt schon vorhanden sind und mit einem UART (ST16C2552_4MBPS)mit Parallem Bus arbeiten. Das ganze arbeitet im Master/Slave Verkehr und im Normalbetrieb werden zwischen MCU und einer Baugruppe max. 30 - 40 Byte ausgetauscht. Im Hochlauf, wenn die Parameter in die Baugruppen eingespielt werden ist dies nicht zeitkritisch, kommt es zu einer größeren Anzahl von Daten. Bei einer Diagnose kann das Auslesen einige Daten verursachen. Die Baud von 4Mbps habe ich mal angenommen weil ich doch in einer sehr kurzen Zeit 16 Baugruppen zyklisch mit Ausgabedaten versorgen und von den Eingabebaugruppen die Eingagnsinformationen abholen können muss. Bei den Anlagen von der Firma Siemens, mit denen ich beruflich als Fernwirkler arbeite, werden zum Beispiel die 4Mbps verwendet. Meine Überlegung war nun, die SPI Geschwindigkeit die mein UART kann ist ca. 4 mal schneller als der Peripheriebus mit den 4Mbps. Wenn nun der UART mit dem parallelen Bus noch schneller wäre hätte ich noch mehr Zeit um Daten von und zur Schnittstelle zu bringen. Auf meinem Testprint befindet sich die SPI Variante und diese werde ich nun testen bevor ich dann den entgültigen Print für die MCU erstelle. Ich hab einige Bilder meiner Prototypen hinzugefügt. Lg. Johann K.
Eine andere Möglichkeit wäre, eben keinen SPI-UART zu verwenden, sondern z.B. einen PIC32MX110F016 oder PIC24F08KL301, der dann lokal das Protokollhandling übernimmt, sodass nur die Nutzdaten per SPI zum Hauptcontroller fließen. Damit reduzierst Du die per SPI zu übertragene Datenmenge, da solche Dinge wie Datenflusskontrolle (ist Byte da? kann nächstes Byte gesendet werden?) von Peripherie-PIC selbständig abgearbeitet werden kann. Und so ein kleiner PIC24 ist nicht teurer und größer als ein SPI-UART. fchk
> Und so ein kleiner PIC24 ist nicht teurer und > größer als ein SPI-UART. Vielleicht nicht aber er erfordert ein eigenes Programm das geschrieben und geflasht werden muss. Das ist aufwändig bei der Entwicklung und wehe es ändert sich später einmal das Protokoll. Das kann bei Softwareupdates zum Albtraum werden da es nicht ausreicht nur eine Firmware zu aktualisieren. Wenn es nur ein Einzelstück ist, kann man das so machen. Ansonsten kann ich davor nur warnen. "Coprozessor" nur wenn der "Master" ihn flashen kann. Und zwar auch initial direkt nach der Bestückung. Da Microchip sich konsequent weigert seine Controller mit Bootloadern auszustatten, wird das mit den PICs eher schwierig.
M. G. schrieb: >> Und so ein kleiner PIC24 ist nicht teurer und >> größer als ein SPI-UART. > > Vielleicht nicht aber er erfordert ein eigenes Programm das geschrieben > und geflasht werden muss. Das ist aufwändig bei der Entwicklung und wehe > es ändert sich später einmal das Protokoll. Das kann bei Softwareupdates > zum Albtraum werden da es nicht ausreicht nur eine Firmware zu > aktualisieren. Das sehe ich absolut nicht so dramatisch wie du es beschreibst... Wo liegt denn da hinsichtlich der Programmpflege des Betriebsprogrammes wirklich der Unterschied zwischen einem fertig gekauften UART und einem einem konventionellen µC der anstelle eines speziellen UART Bausteins als "Co-Prozessor" eingesetzt ist? Klar, die Firmware für den kleinen Co. muss man natürlich erst einmal schreiben, aber ehrlich: Für eine SPI UART Umsetzung gibt es einige Beispiele von Microchip, das dann mit den eigenen Anpassungen versehen und es ist innerhalb eines Vormittages incl. Doku abgehakt! HAt man die Firmware dann kann man den programmierten "Uart-Prozessor" im Hauptprogramm des "großen" Haupt-µC einfach genauso wie jeden anderen zugekauften fertigen UART Baustein als "BlackBox" behandeln. Jetzt mal ehrlich, was ist denn ein solcher externer UART Baustein wirklich... Das ist doch nichts weiter als ein "kastrierter" und Maskenprogrammierter µC dem man alles ausser der für seine Funktion notwendigen Peripherie weggenommen hat. Es gibt also keinen wirklichen für den Nutzer relevanten Unterschied zum "selbstgebauten" UART Baustein ausser das man bei der Eigenentwicklung die Funktionen oder bei Bedarf noch anpassen kann - Aber nicht muss. WEnn man dies vernünftig macht so hat eine Protokolländerung mitnichten Auswirkungen auf beide Firmwareversionen, denn das hat man ja - wie auch bei "normalen" externen UARTS auch, schön getrennt. ICh würde es beispielsweise so auslegen das die Schichten (OSI Modell) eins bis vier NUR im UART µC abgehandelt werden und ab schicht fünf NUR im Master µC. NAtürlich kann eine Änderung auch SO gewaltig sein das es beide Firmwareversionen betrifft - In so einem Fall muss man wirklich an beide Firmwaregeschichten ran, aber das ist doch immer noch besser als die Alternative die man mit einem festen Baustein hätte: Da geht dann nur austauschen! > Wenn es nur ein Einzelstück ist, kann man das so machen. Ansonsten kann > ich davor nur warnen. "Coprozessor" nur wenn der "Master" ihn flashen > kann. Und zwar auch initial direkt nach der Bestückung. Da Microchip > sich konsequent weigert seine Controller mit Bootloadern auszustatten, > wird das mit den PICs eher schwierig. Also da kann ich dir jetzt wirklich nicht Folgen... Auch in der SErienproduktion spielt es doch keine Rolle ob ich nun drei oder sechs Testpunkte auf der Platine vorsehe. Ein Flashen des zweiten µC durch den ersten brauche ich doch nur dann zwingend wenn ich das Gerät selbst ein Firmwareupdate durchführen lassen möchte. Gerade aber im Bereich kleiner Steuerungen ist das aber doch eher unüblich. Kalr, bei großen und komplexen GEräten die in der heute geforderten kurzen Zeitspanne auf den MArkt kommen wie in der Unterhaltungsindustrie beispielsweise üblich, da geht es gar nicht anders, denn die Firmware ist einserseits so komplex, andererseits so schnell zusammengeschustert worden das kaum ein hersteller es schafft in der erstversion auch nur einigermaßen FEhlerfreie Firmware vorzuhalten. Also muss einfach ein Update beim Kunden in Eigenregie des Kunden durchführbar sein wenn man nicht laufen Gewährleistungsansprüche aufgrund der fehlerhaften Firmware abarbeiten will. Aber wie gesagt, das gilt LANGE nicht für alle Produkte... Und selbst wenn ich das so vorsehe dann ist immer noch nicht gesagt ds ich den zweiten µC überhaupt ohne Programmiergerät flashen können muss. Wenn der einfach seinen einfache Funktion erfüllt und diese gut geprüft ist gibt es doch keine Notwendigkeit - Wenn es anders währe, dann dürfte es ja auch gar keine Fertigen Interface Bausteine geben da diese ja auch nur eine Einmal vom Hersteller programmierte Funktion bieten und überhaupt keine Firmwareänderung zulassen. Davon mal abgesehen verstehe ich auch die letzten Bemerkungen zu deinem Beitrag nicht. Selbst wenn ich den zweiten µC durch den ersten flashen lassen möchte, dann ist das doch auch überhaupt kein Problem. Selbst ohne jede Vorprogrammierung. Der "Master" kann doch problemlos einen ganz normalen Flashvorgang in die Wege leiten. Was meinst du was einer der Hauptgründe für die Einführung der LVP war? Von daher ist gerade für den zweiten µC ein Bootloader absolut unnötig. Wenn, dann würde nur ein Bootloader für den Master überhaupt einen Sinn ergeben, denn damit könnte man sich das spezielle Programmierzubehör sparen. Wobei aber oft gerade das Programmieren über die PRogrammierschnittstelle in der Produktion deutlich bevorzugt wird da meiste schneller und unkomplizierter als wenn das über den Bootloader geschehen müsste. Und da bei Serienproduktion Zeit == Geld ist... Wenn man dann für spätere Autoupdates unbedingt einen Bootloader möchte, dann kann man den ja in der Produktion mit der initialen Firmware direkt aufspielen. Microchip bietet ja welche zum Download an die man auch noch selbst anpassen kann. Und es ist auch mitnichten so das Microchip sich weigert die Pic mit Bootloader auszuliefern. Da steckt eher dahinter das sie aus den OG Gründen einfach keinen Sinn darin sehen entweder Chipfläche für einen MAskenprogrammierten Bootloader zu verschwenden was bedeutet das die ICs für ALLE teurer werden nur damit einige Wenige davon etwas haben - Oder aber alle Bausteinen einem initialen Flashvorgang mit den verbundenen Kosten zu unterziehen wo dann die Mehrzahl der Kunden den Aufgeflashten Bootloader einfach wieder löscht. Allerdings ist es überhaupt kein Problem von Microchip PIC mit Bootloader zu bekommen wenn man es unbedingt möchte. Es kostet nicht einmal die Welt und ist auch für Kleinstserien bezahlbar. Microhip bietet es an das die Programmierung mit einem beliebigen Programm von denen im Auslieferungslager vorgenommen wird. Für den PIC32MX795F512 (den Johann verwendet) bedeutet dies pro Chip Mehrkosten von gerade einmal 24cent (bei 8 Euro Grundpreis für den nakten µC). Dazu kommen dann noch ca. 26 Euro einmalige Einrichtunggebühren. Der Mindestauftragswert liegt dabei bei 50 Euro. Dafür hst du dann einen fertig Programmierten, auf Wunsch auch gelabelten, µC der anstelle eines Standard-Bootloaders genau den auf deine Wünsche angepassten Bootloader hat und dazu gleich auch noch mit der Firmware versehen ist, so das eine Zeitlang zumindest überhaupt keine Programmierung nach der Bestückung mehr nötig ist. (Diese Programmierung im Auslieferungslager ist nicht zu verwechseln mit der Programmierung im Werk wo bereits direkt bei der Herstellung das Programm eingebracht wird. Dies ist erst aber eine (hohen) Mindeststückzahl möglich, bei sehr großen Abnahmemengen aber irgendwann deutlich günstiger...) Aber genug der OFF TOPIC Diskussion: Es ist also durchaus Möglich einen zweiten µC als UART Interface zu verwenden. ICh kann wie Frank da auch für Serienprodukte kein NAchteile entdecken wenn man es richtig macht. Die Frage die man einzig prüfen muss ist ob es hier wirklich Vorteile bringt. NÖTIG ist es von der Geschwindigkeit sicher noch nicht, man könnte aber einerseits schauen wie es sich mit den Materialkosten verhält und andererseits ob es vtl. die Lösung für das im anderen Thread genannte Problem vereinfacht. ICh verwende übrigens soetwas ähnlich für USB bei mir desöfteren Auch schon in Kommerziellen Designs. Ich habe mir (auf Basis des CDC Serial Demos aus dem MC USB Framework) eine Firmware für den Pic18F13K50 gebastelt mit der er als zuverlässiger USB-RS232/I2C/SPI Wandler arbeitet. (Initale Wahl durch drei Lötbrücken). Diesen setzte ich häufig für die Dinge ein wo andere dann einen der FTDI Bausteine einsetzen wenn ich USB Brauche, aber aus diversen Gründen keinen µC mit USB für die eigendliche Aufgabe einsetze. Die Programmierung ist mittlerweile immer gleich und der Programmierte µC läuft bei mir vom Handling genauso wie jeder andere zugekaufte Schnittstellenbaustein. Dies mache ich so, weil es mir einfach eine Reihe Vorteile gegenüber dem Einsatz der normalen FTDI USB Wandler bietet. Ich habe die Funktionen reingebracht die ich brauchte (u.A. Vorkonfiguration über die Beschaltung von vier IOs, entweder im Layout fest verdrahtet oder mit Jumper/Lötbrücken bzw. Dip Schalter wählbar), der Preis ist geringer, Die Verfügbarkeit ist besser, ich kann mit einer Vielzahl von Quarzfrequenzen arbeiten und aus eine großen Auswahl verschiedener Gehäuse wählen. Beispielsweise auch DIP wo dann auch wieder ein Sockeln möglich ist usw. usf. Seit über zwei Jahren habe ich die Firmware die auf diesem PIC läuft nicht mehr angefasst. Es ist einfach nicht nötig. Aber ich KÖNNTE es wenn ich es wollte, was beim FTDI ja nicht geht. Gruß Carsten
Genau. Schaut Euch mal den MCP2200 an. Das ist einfach ein vorprogrammierter PIC13K50. Den kann man sogar löschen und umprogrammieren. Ein weiterer Vorteil ist die Vermeidung von schlecht lieferbaren Spezialbauteiteilen. PICs sind Standardteile, und Microchip hat einen sehr guten Ruf, was die Lieferfähigkeit angeht. Die Programmierung von PIC24/dsPIC/PIC32 durch einen anderen Prozessor ist übrigens auch nicht das Problem. Es gibt hier keine High-Voltage Programmierung wie bei PIC16 und den alten PIC18-Typen (das vereinfacht die Schaltungsentwicklung), und egal was man auch macht, man kann sich nicht aussperren, egal wie dumm man sich anstellt. fchk
Hallo Wie man sieht führen viele Wege nach Rom. Ich werde trotzdem mal mit meinem Testprint das Auslagen finden und den Peripheriebus aufzubauen. Vielleicht benötige ich dennoch einen Co für weitere Aufgaben wie eine mögliche Netzwerkanbindung und noch zwei serielle Kommunikationen (RS232, RS485) zu der Aussenwelt, sprich andern Kompunenten wie WIN230 (Visualialisierung) und Zentralkomponenten. Danke. Lg. Johann K.
Lieber Carsten, um bei der Ehrlichkeit zu bleiben: Wenn ein Coprozessor eingesetzt wird, dann wird er mit hoher Wahrscheinlichkeit nicht auf eine reine SPI->UART Funktion beschränkt bleiben. Es ist einfach zu verlockend ihn auch noch mit anderen Aufgaben zu betrauen. Und ruck-zuck hast du deine Protokolländerung weil es nicht mehr eine in sich geschlossen Funktionalität ist um die es geht. Je nach Produktlebensdauer (bei uns mind. 5 Jahre) kommen da schnell die unterschiedlichsten Versionsstände zusammen. Sei es durch Bugfixes oder Programmerweiterungen. Ausserhalb von Auftragsarbeiten für die Industrie sind die Anforderungen an eine Firmware nicht genau festgelegt. Sie orientieren sich an den Möglichkeiten der Hardware, den (schwankenen) Kundenwünschen und natürlich an der Konkurrenz. Ich sage ja nicht "lass es!" oder "geht nicht". Ich warne nur davor. Das kann ins Auge gehen wenn der Coprozessor nicht sauber durchdacht ist oder vernünftig mit Softwareupdates umgehen kann. Irgendwann fällt alles auf einen zurück. Wir betreiben bei uns einen großen Aufwand um Softwareupdates einspielen zu können. Dadurch können wir fast alle Controller online automatisch oder halbautomatisch per Fernwartung aktualisieren. Auch Coprozessoren, die wir durchaus einsetzen. Das habe ich letzten Dienstag erst bei einer Installation in der Schweiz gemacht. Ein Bugfix aus fast 200km Entfernung. Das hätte im Prinzip auch ein Servicetechniker des Händlers machen können. Der hätte aber erst hinfahren müssen und dem letzten "Techniker" mit dem ich zu tun hatte musste ich erstmal erklären wie man bei einem Windows Rechner die IP-Adresse umstellt (war kein Schweizer). Und LVP ist für sich genommen keine Lösung. Es ist eine Eigenschaft mit der es überhaupt erst möglich wird das sich Controller gegenseitig ohne zusätzliche Hardware flashen können. Das Protokoll nennt sich ICSP, das mehr als nur etwas aufwändiger ist als ein paar ISP Kommandos die über einen - dank Autobaud - unkritischen UART zu verschicken. Die ICSP Kommandos ändern sich zu allem Übel bei jedem dritten PIC. Damit wären wir wieder beim Bootloader. Das heisst natürlich nur wenn Microchip nicht eine weitere, einfachere Schnittstelle hat von der ich nichts weiß. Das Microchip auch bei kleinen Stückzahlen fertig programmierte Controller liefert war mir neu. Klar, wenn es einer macht dann die. Aber auch das muss eingeplant und diese Spezialtypen entsprechend bestellt werden. Wer macht das schon? Also gibt es eben keine Updates. Warum auch? Geht ja auch so. Bis zum grossen Knall. Muss ja nicht kommen. Aber es ist noch ein Unterschied ob man einfach nur Pech hat oder man sehenden Auges in ein Schlamassel gerät. Klatec schrieb: > Vielleicht benötige ich dennoch einen Co für weitere Aufgaben wie eine > mögliche Netzwerkanbindung und noch zwei serielle Kommunikationen > (RS232, RS485) zu der Aussenwelt Jaja, sehr vielseitig so ein kleiner CoPro ;-)
M. G. schrieb: > Lieber Carsten, > > um bei der Ehrlichkeit zu bleiben: Wenn ein Coprozessor eingesetzt wird, > dann wird er mit hoher Wahrscheinlichkeit nicht auf eine reine SPI->UART > Funktion beschränkt bleiben. Es ist einfach zu verlockend ihn auch noch > mit anderen Aufgaben zu betrauen. Und ruck-zuck hast du deine > Protokolländerung weil es nicht mehr eine in sich geschlossen > Funktionalität ist um die es geht. Ok, dieses Risiko ist durchaus gegeben wenn man vorraussetzt das jemand unüberlegt an die Sache herangeht und jetzt nach gutdünken einfach mal alles so löst wie es nur für dieses eine Projekt am einfachsten ist. Von einem professionellenm Entwickler aber erwarte ich zumindest das dieser eine vernünftige Abwägung trifft und sich an vorgegebene oder selbst auferlegte DesignRules hält. Dazu gehört dann auch das eine solche Ausweitung der Firmware eines selbsterstellen Schnittstellenbausteines nur dann stattfindet wenn es einfach gar keinen anderen Weg gibt. Wenn es aber doch passiert liegt also an anderer Stelle etwas im argen! Und wenn es soweit ist das ich ernsthaft darüber nachdenken muss um solch ein "Ausweiten" zu verhindern anstelle der oft billigeren und viel besser verfügbaren universellen µC einen speziellen Schnittstellenbaustein einzusetzen nur damit ja niemand die darauf laufende Firmware ändern kann, dann ist aber ein Punkt erreicht wo ich mich fragen muss ob ich mich vielleicht in der Tür geirrt und statt in der Entwicklungsabteilung in der Kinderbetreuung gelandet bin. Und in den Fällen wo es dann aufgrund der Anforderungen DOCH zu einer abweichenden Firmware kommen muss, weil sich erst im Laufe der Entwicklung oder gar erst nach der Auslieferung herausstellt das die vorderfinierte Funktion nicht ausreicht - DANN gibt es diese Möglichkeit zumindest. Bei der von dir favorisierten Methode anstelle der eigenen Bausteine einen "fertig gekauften" Schnittstellenbaustein einzusetzen hat man diese Möglichkeit dann nicht und muss dann das ganze Design revidiert werden und wenn es ganz arg kommt sogar ausgelieferte Hardware zurückgenommen und vernichtet werden. Ist das wirklich die bessere Alternative im vergleich zu etwas mehr Aufwand bei der Versionskontrolle? Woebi ich hier auch noch einmal ganz klar sage das es sich hier GANZ SICHER NICHT um Co-Prozessoren im eigentlichen Sinne handelt, deine Bezeichnung also eher verwirrend ist. Es handelt sich schlicht um SELBST DEFINIERTE Schnittstellenbausteine auf basis eines general Purpose µC mit selbsterstellter Firmware. Der einzige Unterschied zu einem "Zugekauften" Schnittstellenbaustein ist dabei NUR das die Firma in Eigenregie die Eingriffsmöglichkeit hat. Siehe auch meinen "eigenen" Schnittstellenbaustein auf Basis des PIC18F13K50 und dem vom Frank genannten MCP2200. Der einzige Unterschied ist der Aufdruck auf dem Gehäuse und das ich beim MCP2200 die Firmware einfach nicht kenne. Der Rest des IC ist völlig identisch. Und für dich ist jetzt das vorhanden sein der eigenen Firmware ein Nachteil und es ist vorzuziehen den MCP2200 zu kaufen? > Je nach Produktlebensdauer (bei uns mind. 5 Jahre) kommen da schnell die > unterschiedlichsten Versionsstände zusammen. Sei es durch Bugfixes oder > Programmerweiterungen. Ausserhalb von Auftragsarbeiten für die Industrie > sind die Anforderungen an eine Firmware nicht genau festgelegt. Sie > orientieren sich an den Möglichkeiten der Hardware, den (schwankenen) > Kundenwünschen und natürlich an der Konkurrenz. JA, das ist durchaus alles so bekannt - Aber wenn man sich davor einmal vernünftige DesignRules überlegt hat ist das alles überhaupt kein Problem. Ein Schnittstellenbaustein ist ein Schnittstellenbaustein, die Firmware muss einfach universell sein und darf einfach -ausser im absoluten Notfall- keinen, aber auch wirklich keinen spezifischen Bezug zum Einzelprojekt haben. Für das einzelne Projekt hat dieser Baustein dann ganz einfach nur eine "BlackBox" zu sein dem man im Gedanken als "unveränderlich" ansieht. NAtürlich kommt es dann mal vor das einem die Pinbelegung irgendwie nicht so gefällt und die Versuchung ist nah das dann zu ändern. Aber da ist dann einfach soviel Professionalität gefordert das man dies ebend nicht jedesmal macht sondern eher die Kröte beim Layouten schluckt. Beim zugekauften Baustein kann ich doch auch nicht die Belegung ändern! Wenn es doch mal eine Funktionserweiterung geben muss, dann ist diese so auszuführen das die Abwärtskompatiblität gewährleistet ist. Bei "Meinem" USB-RS232 Wandler auf 13K50 ist das durchaus so. Die allererste Version war auch nur ein einfacher RS232 Adapter. SPI/I2C konnte der noch gar nicht. Trotzdem könnte ich einen solchen µC in einem der ersten Designs die aktuellste Firmware mit deutlich erweiterten Funktionsumfang einspielen und das würde noch genauso funktionieren. Man muss es nur von Anfang an richtig planen... > > Ich sage ja nicht "lass es!" oder "geht nicht". Ich warne nur davor. Das > kann ins Auge gehen wenn der Coprozessor nicht sauber durchdacht ist > oder vernünftig mit Softwareupdates umgehen kann. Irgendwann fällt alles > auf einen zurück. JA, eine vernünftige Planung ist schon wichtig, da stimme ich dir zu. aber noch einmal: Es geht hier ja gar nicht um "Co-"Prozessoren die an der Abarbeitung der Anwendungssoftware beteiligt sind, sondern es geht ganz einfach nur um Schnittstellenbausteine mit einem ganz klar definierten Funktionsumfang die so universell wie möglich gehalten werden sollen. Bei den frühen PCs hat man den 8255 bzw. 8250 sowie dessen NAchfolger doch auch nicht als Co-Prozessor bezeichnet. Und hier geht es ja nur um Peripherieelemente. Die Aufteilung eines Anwendungsprogramms auf mehrere Mikrocontroller ist wieder eine ganz andere GEschichte - und da greift dann auch dein Argument viel eher. Auch stimme ich soweit zu, das WENN man eine Aufgabe ohne Nachteile in einem µC zusammenfassen kann, man dies auch machen sollte. Dabei lieber einen großen als viele kleine µC verwenden. (Nur geht das nicht immer) Aber wenn man einen Schnittstellenbaustein verwenden muss und man hat entweder schon eine passende Firmware oder kann die relativ schnell erstellt bekommen (Bzw. die Vorteile wiegen den Zeitansatz auf.) spricht nichts dagegen anstelle des fertigen Bausteins einen eigenen zu entwerfen. > Wir betreiben bei uns einen großen Aufwand um Softwareupdates einspielen > zu können. Dadurch können wir fast alle Controller online automatisch > oder halbautomatisch per Fernwartung aktualisieren. Auch Coprozessoren, > die wir durchaus einsetzen. Das ist ja auch in Ordnung wenn bei euch der Bedarf besteht. Aber das geht ja sowieso auch nur wenn die Baugruppen erst einmal an einem Datennetz hängen an dem Ihr aus der Ferne drankommt. Das ist nicht immer gegeben und selsbt wo es gegeben ist ist es nicht immer gewünscht. Zudem kommt dazu das während der Fernwartung die Schaltung unter Spannung steht aber ja keine richtige Funktion bietet. In vielen Bereichen ist das auch gar nicht zulässig. Das muss man auch bedenken. Es ist halt so das die Bedingungen so vielfältig sein können das man niemals die eigenen Vorraussetzungen als allgemeingültig annehmen sollte. > Und LVP ist für sich genommen keine Lösung. Es ist eine Eigenschaft mit > der es überhaupt erst möglich wird das sich Controller gegenseitig ohne > zusätzliche Hardware flashen können. Das Protokoll nennt sich ICSP, das > mehr als nur etwas aufwändiger ist als ein paar ISP Kommandos die über > einen - dank Autobaud - unkritischen UART zu verschicken. Die ICSP > Kommandos ändern sich zu allem Übel bei jedem dritten PIC. Damit wären > wir wieder beim Bootloader. Das heisst natürlich nur wenn Microchip > nicht eine weitere, einfachere Schnittstelle hat von der ich nichts > weiß. Das ist mir alles schon klar, wobei die "Änderung bei jedem dritten PIC" eher völlig übertrieben ist. NAtürlich gibt es schon eine Stattliche Anzahl an "Flash Programming Guides" die jeweils für andere Bausteine gelten. Aber teilweise sind die Unterschiede so marginal und einfach den technischen Gegebenheiten geschuldet. So hat ein PIC mit nur 1kByte Programmspeicher halt ganz andere Adressaufteilungen als einer mit 10KByte usw... Wenn man wollte, dann wäre das in den Griff zu kriegen. Schaffen eine reihe andere ja auch. Und wenn man die ICSP Schnittstelle nicht nutzen will, dann kann man immer noch in der Fertigung einen Bootloader selbst aufspielen (oder vorprogrammiert bestellen)- das ist doch kein Problem. Und jedes neue Softwareupdate läuft dann über den Bootloader. > Das Microchip auch bei kleinen Stückzahlen fertig programmierte > Controller liefert war mir neu. Klar, wenn es einer macht dann die. Aber > auch das muss eingeplant und diese Spezialtypen entsprechend bestellt > werden. JA, das ist halt eine vernünftige Vorplanung. Es wird eine Abwägung getroffen - Brauchen wir den Bootloader oder nicht. Wenn die Entscheidung auf Bootloader fällt dann wird geschaut ob die Produktion während der Baugruppenfertigung bzw. Erstinbetriebnahme erfolgen soll oder ob man besser vorprogrammiert bestellt. Danach wird dann passend bestellt. Bei Lieferzeiten von 48 Stunden nun auch kein großer Verwaltungsakt der Vorplanung! Das ist gerade mal EIN WERKTAG mehr als bei den schnellsten Distris. Und selbst wenn da mal etwas schief äuft wird halt im eigenen HAus nachprogrammiert. sind dann 10sekunden Aufwand pro Gerät mehr. > Wer macht das schon? Also gibt es eben keine Updates. Warum > auch? Geht ja auch so. Bis zum grossen Knall. > Muss ja nicht kommen. Aber es ist noch ein Unterschied ob man einfach > nur Pech hat oder man sehenden Auges in ein Schlamassel gerät. Also ich kenne MASSIG Firmen die sich durchaus ihre µC passend bestellen. GERADE wenn es "nur" um soetwas wie einen Bootloader gehen soll. Der kann ja dann so ziemlich bei allen µC identisch sein wenn passend geschrieben... Das bekommt dann selbst die Sekräterin hin da einen passenden Auftrag zu generieren wenn das Warenwirtschaftssystem das Unterschreiten der Warnmenge meldet... Und warum das etwas mit dem "großen" Knall zu tun haben soll wenn man PEripheriebausteine auf Basis selbst programmierte Universal-µC anstelle vom Halbleiterhersteller MAskenprogrammierter µC mit eingeschränktem Anwendungsbereich verwendet ist mir immer noch nicht klar. Peripherie ist Peripherie und hat nichts mit der Anwendungsprogramm zu tun. Der "eingene" Baustein ist einfach ein Alternativbaustein aus einer REihe von Bausteinen die zur Wahl stehen und wo ich den für mich günstigsten heraussuche. Für ein Update der Betriebssoftware muss der Schnittstellenbaustein ganz einfach nicht angefasst werden - wenn doch hat man einfach irgendwo gewaltig Mist gebaut! Gruß Carsten
Klatec schrieb: > Wie man sieht führen viele Wege nach Rom. Ich werde trotzdem mal mit > meinem Testprint das Auslagen finden und den Peripheriebus aufzubauen. JA, das mit den vielen Wegen stimmt schon ;-) Manche haben dabei Vorteile, andere Nachteile und sehr viele sind Gleichwertig. Der von Frank vorgeschlagen zwei µC als Peripheriebaustein ist halt auch nur ein weiterer weg aus dem halt diese obige Diskussion entstanden ist. In meinem Fall ist diese Diskussion dabei auch entstanden weil ich den WEg in letzter Zeit immer häufiger gehe und bis jetzt nur Vorteile sehe, wohingegen ich mich manchmal wundere wie andere so viele "exotische" Bausteine einplanen - und gerade insbesondere bei reinen Hobbyisten das die mrkwürdigsten Blüten treibt wo dann Klimmzüge gemacht werden nur um diesen einen speziellen Baustein zu bekommen oder vornehmlich bei älteren Semestern oder denejnigen die nur mit Lochraster und Fädeldraht arbeiten dann die tollsten Künstlerisch wertvollen Aufbauten nötig sind nur um den "feinen" SMD Käfer auf der Lochrasterplatine verbauen zu können - Obwohl ein passender µC für weniger selbst beim Elektronikkrämer um die Ecke verfügbar ist. Und darauf angesprochen kommen dann immer die tollsten Argumente. Deshalb bin ich jetzt etwas zu sehr empfindlich auf dem Ohr. Wenn man aber passende Schnittstelenbausteine gut verfügbar hat und auch der NAchschub gesichert ist, dann spricht grundsätzlich auch nichts gegen deren Einsatz. Man muss ja nicht alles selbst anfertigen. > Vielleicht benötige ich dennoch einen Co für weitere Aufgaben wie eine > mögliche Netzwerkanbindung und noch zwei serielle Kommunikationen > (RS232, RS485) zu der Aussenwelt, sprich andern Kompunenten wie WIN230 > (Visualialisierung) und Zentralkomponenten. Dann würde ich das aber wie schon erwähnt nicht als "Co-Prozessor" ansehen sondern wirklich wie Peripheriebausteine beahndeln und ie Firmwareversionen unabhängig halten! Aber was mir gerade noch nicht klar ist, vielleicht habe ich es auch bloß überlesen oder falsch verstanden: Warum MUSS es den unbedingt ein EXTERNER UART sein. Was spricht gegen den Internen UART. Oder müssen es zwei getrennte Baugruppen sein. (Ich habe es jetzt so verstanden das die Gegenseite schon vorhanden ist, aber du bei der MCU seite noch in der Entwurfsphase bist. U.a. da du ja noch zwischen Parallel und SPI Ansteuerung wählen kannst...) Gruß Carsten
> JA, eine vernünftige Planung ist schon wichtig, da stimme ich dir zu. > aber noch einmal: Es geht hier ja gar nicht um "Co-"Prozessoren die an > der Abarbeitung der Anwendungssoftware beteiligt sind, sondern es geht > ganz einfach nur um Schnittstellenbausteine mit einem ganz klar > definierten Funktionsumfang die so universell wie möglich gehalten > werden sollen. Das reduziert lediglich die Notwendigkeit eines Softwareupdates auf Bugfixes. Und genau darum geht es mir die ganze Zeit: ein µC als Co oder was auch immmer muss programmiert werden. Initial kann man das sicherlich noch manuell machen auch wenn es etwas umständlich ist. Oder auch vorprogrammiert ordern. Nur später ist es üblicherweise nicht akzeptabel mit spezieller Programmierhardware zu hantieren. Da spielen die Kunden nicht mit. Naja, Industriekunden vielleicht. Es ist aber üblich Firmwareupdates per USB-(Kabel/Stick) oder Ethernet zu übertragen. Falls nun ein "Schnittstellenbaustein" buggy ist und er eine neue Firmware braucht, wäre es schon gut wenn man (der Kunde) die auch einspielen kann. Dafür braucht es den Bootloader oder halt das kompliziertere ICSP. Die nötigen Verbindungen zwischen Master und Slave müssen dazu aber vorhanden sein.
Klatec schrieb: > Ich benütze zwar C aber über die diverse > > Listing kann ich das sicher herausrechnen oder hat jemand eine andere > > Idee. Bitte. Danke. Einfache Möglichkeit zur Bestimmung der Laufzeit einer Routine ist: Beginn der Routine: freien Portpin setzen Ende der Routine: Portpin rücksetzen. Mit Oszilloskop messen: Impulslänge = Programmlaufzeit.
M. G. schrieb: >> JA, eine vernünftige Planung ist schon wichtig, da stimme ich dir zu. >> aber noch einmal: Es geht hier ja gar nicht um "Co-"Prozessoren die an >> der Abarbeitung der Anwendungssoftware beteiligt sind, sondern es geht >> ganz einfach nur um Schnittstellenbausteine mit einem ganz klar >> definierten Funktionsumfang die so universell wie möglich gehalten >> werden sollen. > > Das reduziert lediglich die Notwendigkeit eines Softwareupdates auf > Bugfixes. Und genau darum geht es mir die ganze Zeit: ein µC als Co oder > was auch immmer muss programmiert werden. Initial kann man das > sicherlich noch manuell machen auch wenn es etwas umständlich ist. Oder > auch vorprogrammiert ordern. Ja OK, soweit ist das richtig und ich stimme dir zu. Einen "eigenen" Schnittstellenbaustein muss man dann entweder irgendwann vor Auslieferung initial programmieren oder vorprogrammiert bestellen. KLAR. Aber auch ein fertiger Schnittstellenbaustein ist nichts anderes als ein vorprogrammiert gelieferter µC - nur das hier dessen Quellcode nicht kennt > Nur später ist es üblicherweise nicht akzeptabel mit spezieller > Programmierhardware zu hantieren. Da spielen die Kunden nicht mit. Naja, > Industriekunden vielleicht. > Es ist aber üblich Firmwareupdates per > USB-(Kabel/Stick) oder Ethernet zu übertragen. WO ist das "Üblich"? Überall? SCIHER NICHT! ICh wiederhole noch einmal: Du schließt immer noch von deiner Situation auf eine ALLGEMEINGÜLTIGKEIT. In sehr vielen Bereichen ist es absolut nicht üblich das der Kunde über universelle Schnittstellen ein Update einspielen kann. Oft ist es gar nicht gewünscht - manchmal auf grund diverser Vorschriften sogar unzulässig. Natürlich macht es bei sehr umfangreichen Projekten, womöglich noch mit aufwendigen Betriebssystem, durchaus sinn wenn möglich eine Updatefunktion vorzusehen da solch komplexe Systeme auf absolute Fehlerfreiheit zu testen derart TEUER ist das man es nur für eine sehr kleine Anzahl von Produkten macht wo wirklich Leben oder extrem hohe Sachwerte von der Ordnungsgemäßen Funktion abhängen. Da ist die implementierung einer durch den Nutzer zu bedienenden Updatefunktion einfach um ein vielfaches Billiger, die Firmware reift dann einfach erst beim Kunden... Gerade aber im Bereich eher einfacher Aufgaben ist das so nicht üblich. Ja, es werden jedes JAhr auch noch huinderte Millionen von Geräten mit MAskenprogrammierter Firmware gebaut wo ein Update technisch nicht möglich, bzw. nur durch Austausch des µC möglich ist. Und es ist gerade einmal 11 Jahre her das ich meine Ausbildung bei einer Firma abgeschlossen habe wo es regelmäßig zu meinen Aufgaben gehörte OTP µC mit den diversen Firmwareversionen zu Programmieren. Da hat man halt ausreichend lange vorher getestet und keine "grünen" Bananen auf den Kunden losgelassen weil ein Bugfix das Demontieren ganzer Produktionschargen zum µC Tausch bedeutete. (ICh kann mich an einen einzigen Fall in meinen drei Jahren erinnern wo wir eine Klein-Charge so ändern mussten) Einige Firmen arbeiten auch heute noch so. > Falls nun ein > "Schnittstellenbaustein" buggy ist und er eine neue Firmware braucht, > wäre es schon gut wenn man (der Kunde) die auch einspielen kann. Dafür > braucht es den Bootloader oder halt das kompliziertere ICSP. > Die nötigen Verbindungen zwischen Master und Slave müssen dazu aber > vorhanden sein. Das Einspielen durch einem selbst oder den Kunden mag bei BUGs hilfreich sein, ja, es mag es nicht nur, es ist es sogar. ABER DAS IST DOCH GERADE DAS ARGUMENT für eigene Schnittstellenbausteine! Gerade Bausteine die nur eine einfache Funktion erfüllen, wie Schnittstellenwandler kann man ja noch recht einfach testen. Zwar wird es auch hier nicht ökonomisch vertretbar sein wirklich JEDE mögliche Betriebssituation nachzustellen, aber die Grundsätzliche Funktion in 99% aller Betriebssituationen ist noch recht gut darstellbar. Dadurch ist die Wahrscheinlichkeit eines Bug schon sehr gering. Wenn ich aber doch der meinung bin ich muss vorkehrungen für einen BuGfix treffen, dann kann ich das. Entweder im WErk oder durch qualifizierte Servicetechniker vor Ort OHNE jede weitere Maßnahme, oder wenn ich der Meinung bin das sollte der Kunde selbst auch können ja wie gehabt auch über Ethernet oder ICSP. NICHTS Hindert mich daran. Ich muss nur die nötigen ICSP Leitungen mit dem MAster-µC verbinsen. JA- Ich muss für die Initiale Firmware des MAsters ja noch nicht einmal die UpdateRoutine für den Slave implementieren. Ich muss nur sicher stellen das die für ICSP notwendigen Leitungen auf einem "sicheren" Pegel liegen. Wenn denn dann ein Bugfix für den Slave nötig ist, dann kann ich die notwendige Routine immer noch in die Aktualisierte Version der Firmware hineinschreiben. Ich habe beim eigenen Baustein also ALLE Möglickeiten! Und das stht im eindeutigen Widerspruch zu der von dir favorisierten Methode nur vorgefertige Bausteine zu verwenden. DENN DA HABE ICH WEDER DIE CHANCE AUF EINEN BUGFIX DES BAUSTEINS, noch kann ich bei einem schweren nicht durch ein simples Update des Hauptprozessors zu behebenden Problem doch die Firmware des Peripheriebausteins abändern um noch etwas zu retten. Da MUSS ich dann ALLE Geräte ins Werk kommen lassen, die alten Bausteine müssen entfernt und neue -hoffentlich gerade lieferbare- müssen von Hand eingelötet werden. Mit all den Folgen. Da ist ein Simples Anstecken eines ICSP Kabels für 5 sekunden ein Klacks gegen... Und jetzt behaupte NICHT das zugekaufte Bausteine keine Fehler haben. ICh habe zu so gut wie jedem von mir je eingesetztem Schnittstellenbaustein mindestens ein ErrataSheet in den Unterlagen. Egal ob der Baustein nun von Microchip, FTDI oder sonstirgendjemanden kommt. Gruß Carsten
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.