PIC32MX795F512L 80MHZ Berechnung der Programmlaufzeit

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

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

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.

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