Hallo miteinander Ich habe eine keine Frage: Kennt jemand von euch einen SPI-Analyser? Daten werden von einem ARM über SPI versendet. Diese müssen möglichst schnell zum PC, da alle 1ms 128Bytes über SPI geschrieben werden, und das ca 60s lang. Puffern muss er es also nicht. Gibts solche Analyser oder muss man sich hier etwas selber zusammenbasteln? Ach ja, die Daten sollen auf dem PC weiter verarbeitbar sein (eigene GUI). Besten Dank MFG Patrick
Patrick B. schrieb: > Daten werden von einem ARM über SPI versendet. Diese müssen möglichst > schnell zum PC, da alle 1ms 128Bytes über SPI geschrieben werden Das ist ja Schneckentempo... Patrick B. schrieb: > Gibts solche Analyser oder muss man sich hier etwas selber > zusammenbasteln? Viele dieser neuen USB-LAs haben einen SPI-Decoder in der Software eingebaut, so z.B. der saleae logic Außerdem: http://dangerousprototypes.com/docs/Features_overview
ich hab hiermit: http://www.ikalogic.com/scanalogic2/ gute Erfahrungen gemacht. Wobei ich den Live-Modus nie verwendet hatte.. hab immer auf ein Event getriggert
Lukas K. schrieb: > Patrick B. schrieb: > >> Daten werden von einem ARM über SPI versendet. Diese müssen möglichst > >> schnell zum PC, da alle 1ms 128Bytes über SPI geschrieben werden > > Das ist ja Schneckentempo... Ja, ich weiss, dass dies nicht sehr schnell ist. Das USB-Gerät müsste ein SPI-Slave simulieren und dann die Daten wie gesagt an den PC senden. Diese Daten müssten weiter verarbeitbar sein (z.B. aus den 8Bit Packeten 32Bit Variablen machen und dann sortiert in ein Excel schreiben. Dies ist nicht das Problem, man müsste einfach an die Daten kommen über exportfunktion oder so ähnlich. Dann einfach einen Converter...)
Genau das kann der bus pirate http://dangerousprototypes.com/docs/Bus_Pirate_binary_SPI_sniffer_utility
Diverse Geräte der Firma Totalphase können SPI-Spy. Sind aber nicht wirklich billig... Gruß, Jörg
Lukas K. schrieb: > Genau das kann der bus pirate Mhm, hab ich jetzt was falsch verstanden, oder nimmt der Bus Pirate im binary mode nur Daten entgegen, wenn er auch welche sendet? Dies wäre dann sehr ungünstig, da ich nur ein Empfänger brauche.
Hi, Lukas K. schrieb: > Patrick B. schrieb: >> Daten werden von einem ARM über SPI versendet. Diese müssen möglichst >> schnell zum PC, da alle 1ms 128Bytes über SPI geschrieben werden > Das ist ja Schneckentempo... Also Schneckentempo... KANN SEIN, MUSS aber nicht sein... Es werden einmal pro ms 128Byte übertragen. Aber das muss ja nicht heißen das die GEschwindigkeit auch tatsächlich bei 128kb/s liegt. Wenn du eines USB FullSpeed Anwendung hast wird es durchaus ähnlich sein, Das USB Device bekommt einmal pro ms seinen Aufruf zum Datensenden, bläst mit maximaler Geschwindigkeit seine Pakete über den Bus, dann ist das nächste Device dran. Möglichst ALLE Devices am BUS wollen aber einmal pro ms Aufgerufen sein. Ich habe hier eine USB FullSpeed Anwendung die überträgt sogar nur 64Byte alle 1ms. Allerdings laufen die Datenpakete selber mit 12Mb/s, also sehr lange Zeiten dazwischen wo dieses Device einfach nichts macht. Das muss man unterscheiden. Ersterer Fall, also 128kb/s als tatsächliche Datenrate könnte man noch ganz bequem mit einem eigenen Test µC als "Sniffer" der die Daten selbst an den PC sendet (USB-CDC) auf dem ein TerminalProgramm läuft mitlesen. In weniger als einer Stunde hat man das so am laufen. Der letztere Fall wird für alle reinen USB basierenden echtzeit Sniffer die nur davon leben das die Daten in echtzeit über die USB Schnittstellt abtransportiert werden (wie Saleae oder USBee) eine echte Bewährungsprobe. Evtl kann der TE dazu genaueres sagen wie groß die Baudrate nun tatsächlich ist! > > Patrick B. schrieb: >> Gibts solche Analyser oder muss man sich hier etwas selber >> zusammenbasteln? > Viele dieser neuen USB-LAs haben einen SPI-Decoder in der Software > eingebaut, so z.B. der saleae logic > Außerdem: http://dangerousprototypes.com/docs/Features_overview Ja, wie schon geschrieben gibt es massig solcher Analyzer. Entweder als reine Protokollanalyzer mit 2 - 4 Eingängen die dann die gängigen Seriellen Modi beherschen oder aber als "echte" Logikanalyzer mit 8 bis teilweise deutlich über 32 Kanälen die noch deutlich mehr können. Von diesen gibt es dann wieder zwei Familien, einmal die USB basierenden "Einfachst-LA" die selber in der Hardware nichts anderes machen als die Daten zu sampeln und sofort jedes Datenpaket an den PC übertragen. Die maximale Geschwindigkeit ist hier dramatisch von der "tatsächlich verfügbaren" USB geschwindigkeit abhängig. Der Speicher ist aber nur durch die Festplattengröße begrenzt. Oder aber die reinen Hardware Sampler die einen Teil der Datenverarbeitung direkt im Gerät erledigen und auch dort erst einmal zwischenspeichern. Diese können tatsächlich viel schneller arbeiten, sind von der USB Geschwindigkeit unabhängig, aber leider ist der interne Speicher begrenzt. Die gängigen Speichern die gesamten Signalverläufe in der HArdware, die Protokollanalyse erledigt der PC nachdem die Daten übertragen werdem. Die noch hochwertigeren können zumindest eine rudimentäre Protokollanalyse bereits in HArdware und so sogar auf einzelne serielle Datenpakete mit speziellen Inhalt triggern. Da ist man aber ganz schnell in "höheren" Preisregionen. Die "USB basierenden" LAs sind recht einfach selbst nachzubauen. Viele basieren sogar auf der selben Hardware (einen Cypress 8051µC mit FullSpeed usb) Hardwarekosten (nur Elektronik) liegen so bei unter 20Euro. Der Saleae ist ein solcher Vertreter. Der USBee ein anderer. Das Gerät hält das was die Saleae Werbung verspricht, auch der Originalpreis ist grunsätzlich noch akzeptabel. Die Funktionalitäten die der Hersteller des USBee verspricht und die über die Saleae Werbung hinausgehen sind teilweise aber Praktisch nicht wirklich nutzbar. (USB Fullspeed geht nur mit maximaler Samplerate, die ist aber nur mit Glück nutzbar wenn man einen schnellen Rechner UND so gut wie keine weiteren Devices an USB hat UND das Betriebssystem kaum sonstige Arbeit verrichtet!) Ein Thread wo auch der NAchbau dieser Geräte besprochen wird ist: Beitrag "Logikanalzyer mit FT232BL" Die "besseren" LA sind im Nachbau schon etwas aufwendiger. Beispiel ist hier der MiniLA der hier im Forum schon öfter beahndelt wurde und wo es auch Sammelbestellungen gibt. Bin gerade am Überlegen ob SPI in der SW vorhanden ist. Glaube aber schon. Beitrag "[S] Leute die einen Logic Analyzer (MiniLA) bauen wollen" http://www.mikrocontroller.net/articles/Minila_Version_MockUp BEi den Kommerziellen gehört SPI bei so gut wie allen zur Grundausstattung. Die hier bekanntesten Kommerziellen sind sind wohl die GEräte von Zeroplus und Intronix. http://www.pctestinstruments.com/deutsch http://www.zeroplus.com.tw/logic-analyzer_en/products.php Bei diesen Geräten ist neben maximaler Samplerate und Kanalzahl unbedingt die Speichertiefe zu beachten. Wobei man darauf achten muss wie die Angabe zu verstehen ist. Einige Hersteller geben die Speichertiefe pro Kanal an, andere dann wieder -weil es ja viel toller klingt- für das Gesamtgerät! Es ist aber ein Riesenunterschied ob man nun 2MBit pro Kanal hat oder sich die 2MBit auf 32Kanäle verteilen. Auf jeden Fall MUSS man überlegen ob der Speicher für die eigenen Anforderungen reicht. Was nutzt ein 500Mhz 32KAnal LA mit dem selbt bei kleiner Samplefrequenz 10Mhz nur 50ms Aufzeichnen kann? Es gibt also massig Auswahl. Was für dich am besten ist kannst nur du selbst sagen, oder du musst weitere Informationen geben. Wenn es in erster Linie nur um serielle Protokolle wie SPI geht, DIESE aber recht langsam sind (max. um die 5Mbit/s Datenclock würde ich sagen ) dir aber reine lange Aufzeichnungsdauer wichtig ist, dann ist ein Saleae (Original oder Clone) nicht schlecht. Usbee als Original finde ich im Vergleich zu den sonstigen auf dem MArkt erhältlichen Geräten schlicht überteuert... Clone - OK. Wobei ganz klar sein Muss. Die verwendung von Clones ist rechtlich -zumindest- eine Grauzone! (GRAU meiner ansicht nach deshalb, weil die SW frei herunterladbar ist und das Design selbt wohl auf eine AN des Chipherstellers zurückgeht.) Aber vielleicht sieht es auch ja auch ein Richter anders... Sobald die Übertragung schneller wird ist es aber mit diesen Geräten ein echtes Glücksspiel ob man noch zuverlässig schnell genug samplen kann. (FSample min. = 2x F_Daten) Bei den rein kommerziellen Vertretern Ihrer Zunft würde ich sagen das für jemanden der als ersten Anspruch hauptsächlich serielle Protokolle hat im Moment der Zeroplus C16032 das beste Preis/Leistungsverhältniss bietet. http://www.tigal.com/product/1491 (Achtung: Preis von 89Eur, ist OHNE MwSt! Ergibt 109Eur. Endsumme) Dieser ist durch eine Änderung der PID/VID ohne jeden Hardwareeingriff zu einem 16128 Aufrüstbar. (gibt wohl sogar ein Programm dafür). http://www.tigal.com/product/1699 Wenn man die 100Eur für einen 72MB Speicherchip investieren will und es wagt am ASIC GEhäuse herumzufeilen soagr auf 162000... Der Umbau auf 32 Kanäle der im Netz zu finden ist, der ist aber NICHT mehr möglich! Für diesen gibt es neben den Standartprotokollen noch 30 Protokolle freier Wahl zusätzlich gratis! (Will man "aufbohren" die Protokolle erst NACH dem Aufbohren Freischalten!!!) Zum Vorgang selbst werde ich hier aber keine weiteren Angaben machen... Braucht man 32Kanäle oder noch höhere Samplegeschwindigkeit ist der Intronix Logikport wohl die bessere Wahl, allerdings unterstützt dieser nicht so viele verschiedene Protokolle. Die Benutzeroberfläche soll beim Intronix wohl etwas organisierter sein. Beim Zeroplus ist die teilweise "gewöhnungsbedürftig". Aber auch damit kommt man zurecht! Gruß Carsten
Patrick B. schrieb: > Lukas K. schrieb: >> Genau das kann der bus pirate > > Mhm, hab ich jetzt was falsch verstanden, oder nimmt der Bus Pirate im > binary mode nur Daten entgegen, wenn er auch welche sendet? Nein, wie kommst du darauf?
Patrick B. schrieb: > Lukas K. schrieb: >> Genau das kann der bus pirate > > Mhm, hab ich jetzt was falsch verstanden, oder nimmt der Bus Pirate im > binary mode nur Daten entgegen, wenn er auch welche sendet? Dies wäre > dann sehr ungünstig, da ich nur ein Empfänger brauche. Ohne mir etwas über den Piraten durchgelesen zu haben ... Wie funktioniert eine SPI Schnittstelle? Es gibt einen Master einen Takt für ein Schieberegister sendet. Nun hat ein SPI Gerät zwei von diesen Schieberegistern. Eins zum Senden und eins zum Empfangen die werden beide mit diesem Takt versorgt. Also schiebt das Sendeschieberegister seine Daten auch beim Empfang raus. Also was tun? Die Sende Leitung einfach nicht anschließen!
Patrick B. schrieb: > Das USB-Gerät müsste ein SPI-Slave simulieren und dann die Daten wie > > gesagt an den PC senden. Diese Daten müssten weiter verarbeitbar sein > > (z.B. aus den 8Bit Packeten 32Bit Variablen machen und dann sortiert in > > ein Excel schreiben. Dies ist nicht das Problem, man müsste einfach an > > die Daten kommen über exportfunktion oder so ähnlich. Dann einfach einen > > Converter...) Ok.. Man sollte wenn man das schreiben wg. Abendessen unterbricht zumindest mal nachsehen ob sich was im Thread getan hat ;-) Das was du hier schreibst ist dann definitiv nicht mehr die Funktion eines SPI-Schniffers... ICh verstehe das jetzt so, das du nicht mitlesen willst, sondern das Gerät AKTIV am geschehen als Slave teilnehmen soll. Richtig? (Ein Sniffer ist ja für die "zu untersuchende Elektronik" sinnvollerweise praktisch einfach nicht vorhanden) Das was du möchtest, "also GEgenstelle" kann "GLAUBE ICH" der PicKit SErialAnalyzer. Da war auch was mit Datenübernahme. BIn da aber gerade nicht ganz im Bilde. Aber letzendlich ist das doch auch überhaupt kein Problem das ebend mit einem fast beliebigen µC selbst zu realisieren... ICh würde da jetzt einen USB PIC18F nehmen und eines der Beispielprogramme für CDC so abändern das dieser sich als COm Anmeldet und die Datenpakete dann über dne Emulierten COm an den PC sendet. Die COM Abfrage zur Weiterverarbeitung auf PC Seite ist ja mit so wziemlich jeder Entwicklungsumgebung nur eine Fiungerübung . Gruß Carsten P.S. sollte es jetzt doch von mir falsch verstanden sein und es geht nicht um die "aktive Teilnahme" sondenr nu um die Möglichkeit mitgeschriebene Pakete irgendwann mal weiterzuverarbeiten: Ds können viele LA auch. Die Daten werden dann als TXT ausgegeben und können dann wieder eingelesen werden.
Martin schrieb: > Patrick B. schrieb: >> Lukas K. schrieb: >>> Genau das kann der bus pirate >> >> Mhm, hab ich jetzt was falsch verstanden, oder nimmt der Bus Pirate im >> binary mode nur Daten entgegen, wenn er auch welche sendet? Dies wäre >> dann sehr ungünstig, da ich nur ein Empfänger brauche. > > Ohne mir etwas über den Piraten durchgelesen zu haben ... > > Wie funktioniert eine SPI Schnittstelle? > > Es gibt einen Master einen Takt für ein Schieberegister sendet. Nun hat > ein SPI Gerät zwei von diesen Schieberegistern. Eins zum Senden und eins > zum Empfangen die werden beide mit diesem Takt versorgt. Also schiebt > das Sendeschieberegister seine Daten auch beim Empfang raus. Also was > tun? Die Sende Leitung einfach nicht anschließen! In den meisten Fällen funktioniert das auch. Allerdings gibt es ja durchaus Implementierungen die nach jedem xten Datenpaket eine Reaktion erwarten. Das ist natürlich genaugenommen KEINE SAche der SPI Schnittstelle sondern der Firmware die auf dem sendenden Device läuft, aber das kommt vor. Wo ich gerade aber einen Blackout habe: Wie funktioniert die Spannungsversorgung beim High Pegel? Treibt der Master aktiv High oder geschieht dies mit einem Pull-Up (evtl. beim Slave) und de rMAster zieht mit OC nur nach Low? Das müsste man ggf. auch beachten. Gruß Carsten
>>> Daten werden von einem ARM über SPI versendet. Diese müssen möglichst >> >>> schnell zum PC, da alle 1ms 128Bytes über SPI geschrieben werden >> >> Das ist ja Schneckentempo... Bei z.B. 25MHz SPI Clock ist das alles andere als Schneckentempo.
>Wie funktioniert die >Spannungsversorgung beim High Pegel? Treibt der Master aktiv High Ja. > oder geschieht dies mit einem Pull-Up (evtl. beim Slave) und de rMAster >zieht mit OC nur nach Low? Nein. Was willst du eigentlich tatsächlich machen? Daten per SPI an den PC schicken oder die Übertragung zu einem Slave abhören?
Oh, da hat sich aber sehr viel getan. Ich kann eure Verwirrung nachfollziehen, habe gemerkt, dass ich hier wohl ein paar Dinge durcheinander gebracht habe. Der Master ist ein ARM, der einen Regler Implementiert hat. Jetzt möchte man diverse Regelparameter (Strom, Soll, Ist...) als 32Bit an den PC senden. Da der ARM keinen Speicher mehr frei hat, soll hier ein SPI-Slave hinzukommen, der vom Master die Daten empfängt und diese dann direkt ohne Puffer über das USB weiter an den PC sendet. Der Arm schiebt dann 128Byte mit ~2MHz alle 1ms heraus. @Carsten: Hattest du gerade nichts zu tun, oder wieso kommt so ein ausführlicher Bericht zustande? Die LAs sind sehr sehr umfangreich, zu umfangreich. Mir ist schon klar, dass uC + FT232/FT245 und Firmware sowie GUI etwa einen Tag Arbeit bedeuten, aber als Betriebsinterne Arbeit einen Elektroniker damit zu beschäftigen ist überrissen, da kann man bis 200Euro etwas kaufen und ist immer noch weit unter den Kosten des Elektronikers. Schönen Abend noch
Patrick B. schrieb: > @Carsten: Hattest du gerade nichts zu tun, oder wieso kommt so ein > ausführlicher Bericht zustande? NAja, zu tun eigendlich genug... Aber ich habe mir gerade an einem Problem die Zähne ausgebissen und musste auf andere Gedanken kommen. Und da ich mich die Tage selbst noch einmal etwas mit LA befasst habe. Allerdings passiert es mir durchaus öfter das ich "zu ausführlich" werde. Wobei ich das immer noch für besser halte als einfach ein paar Dinge in den Raum zu werfen und dem Fragenden ist damit immer noch nur begrenzt geholfen. Patrick B. schrieb: > Die LAs sind sehr sehr umfangreich, zu umfangreich. > Mir ist schon klar, dass uC + FT232/FT245 und Firmware sowie GUI etwa > einen Tag Arbeit bedeuten, aber als Betriebsinterne Arbeit einen > Elektroniker damit zu beschäftigen ist überrissen, da kann man bis > 200Euro etwas kaufen und ist immer noch weit unter den Kosten des > Elektronikers. Sol das jetzt erst einmal nur rein als Test laufen? Oder ist ds eine Anwendung wo es dann als Einzelstück später so bleiben soll. ICh weiß ja jetzt nicht wie groß die Anforderungen an die GUI sind, aber alles µC seitige ist incl. Aufbau auf Lochraster in einer Stunde abgehakt. Wenn es denn ordentlich mit LAyout auf geätzter Leiterplatte sein soll sind es 2h. Auch FT232 usw. braucht man nicht wenn man den richtigen µC nimmt. Eine GUI die nur die Daten Anzeigt und evtl. noch die PArametern ändern lässt sind vielleicht 45minuten. Wenn die Daten dann noch aufwendig bearbeitet werden sollen wird es natürlich komplexer. Aber das hat man mit jeder anderen Lösung unter Nutzung der Exportfunktion auch. Geht es nur uim eine Überprüfung reciht sogar ein Terminalprogramm ohne eigene GUI, dann muss auf dem µC halt eine CDC kompatible Firmware. Aber BTT: Wie geschrieben GLAUBE ich das man das mit dem PicKit SerialAnalyzer hinbekommen kann skripte Ausführen zu lassen und die Ergebnisse exportieren zu können. Etwas anderes fertiges ist mir so nicht bekannt wenn man von den "richtigen" LAs absieht die m.W. aber keine "automatisierten" Funktionen haben. Die Microchip Website ist seit einigen Stunden Down (und ich muss da dringend noch etwas anderes nachschlagen!) sonst hätte ich mal kurz das Anwendugnsprogramm geladen und mit meinem PK_SA nachgeschaut. (Habe zwar auch die CD, aber bis ich die gefunden habe...) Wenn das mit dem Pickit nicht geht und du anderweitig auch nicht fündig wirst musst du dich mal direkt bei mir melden. Für 200Euro könnt ihr von mir locker einen passenden SPI-USB Umsetzer incl. einfacher GUI bekommen. NAtürlich geätzt und mit Rechnung... ;-) Da liege ich noch gut in meinem Stundensatz. Gruß Carsten
>Der Master ist ein ARM, der einen Regler Implementiert hat. Jetzt möchte >man diverse Regelparameter (Strom, Soll, Ist...) als 32Bit an den PC >senden. Ok. >Da der ARM keinen Speicher mehr frei hat, Da machst du was falsch. >soll hier ein >SPI-Slave hinzukommen, der vom Master die Daten empfängt und diese dann >direkt ohne Puffer über das USB weiter an den PC sendet. >Der Arm schiebt dann 128Byte mit ~2MHz alle 1ms heraus. Wozu zum Teufel? Keinen UART mehr frei? Was soll der Quatsch mit dem SPI in Richtung PC? So ein Deppenkram.
Carsten Sch. schrieb: > Wenn das mit dem Pickit nicht geht und du anderweitig auch nicht fündig > wirst musst du dich mal direkt bei mir melden. Für 200Euro könnt ihr von > mir locker einen passenden SPI-USB Umsetzer incl. einfacher GUI > bekommen. NAtürlich geätzt und mit Rechnung... ;-) Da liege ich noch gut > in meinem Stundensatz. Ich habe den Auftrag so bekommen, jetzt geht es bei mir einmal um Varianten-Studium, und um zu sehen, ob es sich lohnt. Selber machen könnte ich es auch, aber nur mit FTDI-Chip, da ich bis jetzt den Durchblick bei einem USB-uC noch nicht habe (ist ein klein wenig komplizierter als die USART). Und bis ich eine solche Kommunikation am laufen habe, vergeht viel mehr Zeit, als wenn ich schon bekanntes nehme. Ausserdem kann man ja nicht einfach so ein USB-Device bauen (VID, PID). holger schrieb: >>Da der ARM keinen Speicher mehr frei hat, > > Da machst du was falsch. Der Regler ist eine bestehende Platine. Wie das aufgebaut ist, weiss ich nicht. holger schrieb: > Wozu zum Teufel? Keinen UART mehr frei? Was soll der Quatsch > mit dem SPI in Richtung PC? So ein Deppenkram. Es hat eine USART, die herausgeführt ist, als Debugg-Schnittstelle. Ich weiss aber nicht wieso sie die Daten nicht über diese herauslesen können.
Patrick B. schrieb: > Es hat eine USART, die herausgeführt ist, als Debugg-Schnittstelle. Ich > weiss aber nicht wieso sie die Daten nicht über diese herauslesen > können. So wie es mir gesagt wurde, ist die UART zu langsam...
Patrick B. schrieb: > Patrick B. schrieb: >> Es hat eine USART, die herausgeführt ist, als Debugg-Schnittstelle. Ich >> weiss aber nicht wieso sie die Daten nicht über diese herauslesen >> können. > > So wie es mir gesagt wurde, ist die UART zu langsam... >1 MBaud sollte der ARM doch schaffen?
Patrick B. schrieb: > Ich habe den Auftrag so bekommen, jetzt geht es bei mir einmal um > Varianten-Studium, und um zu sehen, ob es sich lohnt. > Selber machen könnte ich es auch, aber nur mit FTDI-Chip, da ich bis > jetzt den Durchblick bei einem USB-uC noch nicht habe (ist ein klein > wenig komplizierter als die USART). Und bis ich eine solche > Kommunikation am laufen habe, vergeht viel mehr Zeit, als wenn ich schon > bekanntes nehme. Ausserdem kann man ja nicht einfach so ein USB-Device > bauen (VID, PID). Naja, es kommt darauf an wie die Randbedingungen sind... GErade für solch triviale Sachen kann man wunderbar ein fertiges Framework nehmen. Idealerweise eines das direkt vom Prozessorhersteller herausgegeben wird, direkt läuft und auch für Kommerzielle Verwendung ohne Einschränkung freigegeben ist. Da kann die USB Kommunikation schon mal auf auf das Einbinden der richtigen Header und zwei bis vier Funktionen die aufgerufen werden müssen zusammenschrumpfen. Das ist dann genauso leicht wie UART. PID/VID ist dann so eine Frage... ISt es eine rein interne Anwendung kann man ja nehmen was man will. Wichtig wird das ja erst wenn man das "vertreiben möchte" Aber auch da bieten einige Halbleiterhersteller unterstützung. Für kmomerzielle Verwertung in Kleinserien bis hin zu einigen tausend Stück pro Jahr bekommt man z.B. von Microchip auf Antrag eine individuelle PID kostenlos zugewiesen die man dann zusammen mit der Microchip VID ganz offiziell und legal für seine Produkte verwenden kann. ICh schrieb ja schon das ich z.B. zu einem PIC18F unter verwendung des Microchip USB Frameworks greifen würde. Dazu gibt es eine reine Beispielprogramme die man als Ausgangsbasis für eigene Projekte nehmen kann (und zumindest als einsteiger auch sollte). Darunter ist zum Beispiel das USB-CDC Serial Demo. Dieses Programm macht aus dem PIC einen USB UART umsetzer. Im Prinzip 100% dasselbe wie ein käuflicher USB-RS232 Adapter. Dieses Programm würde ich aus Ausgangsbasis nehmen und nur die ConfigBits für den USART Port ändern um den Eingangsport von UART auf SPI umzustellen. Das währe dann wohl der schnellste Weg mit dem der "Käse" gegessen ist. Wenn es nicht über CDC laufen soll, dann dauert es halt statt 10minuten 20minuten bis es läuft... An Peripherie braucht man neben dem Prozesor nur einen Quarz sowie die beiden Kondensatoren für den Quarz sowie die Abblockkondensatoren für die Spannungsversorgung. Dann nur noch die Anschlüsse. Das war es auch schon. Allerdings bietet nicht jeder Halbleiterhersteller eine so umfangreiche Unterstützung an. Aber man kann ja entsprechend auch wählen. Wobei man natürlich immer bedenken muss das der Rückgriff auf vorgefertigte Lösungen auch nur bis zu einer gewissen komplexität ordentlich funktioniert. Aber das hier liest sich wirklich trivial. GRuß Carsten
Carsten Sch. schrieb: > Naja, es kommt darauf an wie die Randbedingungen sind... > GErade für solch triviale Sachen kann man wunderbar ein fertiges > Framework nehmen. Idealerweise eines das direkt vom Prozessorhersteller > herausgegeben wird, direkt läuft und auch für Kommerzielle Verwendung > ohne Einschränkung freigegeben ist. Da kann die USB Kommunikation schon > mal auf auf das Einbinden der richtigen Header und zwei bis vier > Funktionen die aufgerufen werden müssen zusammenschrumpfen. Das ist dann > genauso leicht wie UART. Naja, ich habe mir die ganze Microchip applicatin library einmal angesehen, und es schein, als hättenw wir unterschiedliche Ansichten von leicht: Es sollte nicht über CDC laufen, aber was soll genommen werden? Generic, MSD? HID fällt ja weg. Und leider hat Microchip nicht wirklich eine gute Doku, wo ersichtlich ist, welche Dateien man schlussendlich wie braucht, und was abgeändert werden muss, da ja das OTG Config Tool nur für OTG funktioniert und Peripherie-Devices nicht unterstützt (habe nachgefragt). Also, wenn du mir da etwas weiterhelfen kannst, wäre mir schon sehr geholfen. Die Frage ist sowieso ob PIC-USB oder einen Wandler...
Patrick B. schrieb: > Es sollte nicht über CDC laufen Warum eigentlich nicht? Für derartige Daten würde sich das doch anbieten.
Wäre die Geschwindigkeit dann nicht zu langsam, da CDC ein virtueller COM-Port ist? Direktes ansprechen des USB wäre doch schneller? Und die DLL von Microchip sieht auch nicht sehr schwer aus. Einziges Problem ist bei mir die uC Seite, da nicht wirklich klar ist, wie ich wo was anpassen muss und welche Dateien ich benötige. Jedes Demo-Projekt hat folgende Dateien: - main.c - HardwareProfile.c - usb_config.h - usb_descriptors.c Z.T - user.h - user.c Desweiteren wird immer in den Ordner USB verwiesen, wo wiederum ein HAL vorhanden ist, wieso also HardwareProfile.c?
Patrick B. schrieb: > Wäre die Geschwindigkeit dann nicht zu langsam, da CDC ein virtueller > COM-Port ist? Er ist doch nur virtuell. Im Gegenteil, es gibt Situationen, wo ein echter serieller Port deutlich schneller ist als USB insgesamt, bspw. wenn man ihn zum "Bitwackeln" missbraucht (wie bei einfachen ISP-Programmiergeräten). Dann wird man durch die USB-Framerate (1 ms) ausgebremst, aber das ist für dich kein Thema. > Direktes ansprechen des USB wäre doch schneller? Warum sollte das schneller werden? Der schlichte Vorteil von CDC ist es, dass man auf praktisch allen existierenden Betriebssystemen bereits einen Treiber dafür vorfindet. Man muss das Teil also nur anstöpseln. (OK, unter Windows muss noch einmal der Admin dann ran und trotzdem noch die "Hardware installieren", aber das ist dort ohnehin immer so. Andere Systeme leiden nicht an dieser Krankheit, bei denen ist USB wirklich "plug & play", wie es in USB's Selbstdefinition auch sein sollte.)
Jörg Wunsch schrieb: >> Direktes ansprechen des USB wäre doch schneller? > > Warum sollte das schneller werden? Warum nicht? FTDI hat ja auch unterschiedliche Geschwindigkeiten wenn der VCP oder D2XX verwendet wird. Wird bei VCP nicht zuerst auf das USB geschrieben, wass dann wieder der PC verabeiten muss? Beim USB-Treiber geht man doch direkt auf den PC los. Ich habe mir einmal das CDC Beispiel von Microchip angesehen, und da verwenden sie um die 15 Dateien. Aber soweit ich es überblickt habe, muss man nur die Device Descriptor und Configuration Descriptor, sowie die Strings anpassen? Und dann natürlich die eignetliche Software. Hat da jemand schon Erfahrungen?
Patrick B. schrieb: > Jörg Wunsch schrieb: >>> Direktes ansprechen des USB wäre doch schneller? >> >> Warum sollte das schneller werden? > > Warum nicht? Weil die Geschwindigkeit vom zugrunde liegenden USB und dessen Physik (insbesondere der maximalen Paketgröße und der Framerate von 1 ms) bestimmt wird. Es ist ja nirgends ein Flaschenhals in Form einer realen seriellen Schnittstelle eingebaut, der da irgendwas ausbremsen würde. > FTDI hat ja auch unterschiedliche Geschwindigkeiten wenn > der VCP oder D2XX verwendet wird. Dann haben sie was falsch gemacht. Oder sie wollen die Vorzüge ihres proprietären D2XX-Treibers herausstellen, und haben in den VCP-Treiber eine Bremse reingebaut. ;-) > Wird bei VCP nicht zuerst auf das USB geschrieben, wass dann wieder der > PC verabeiten muss? Beim USB-Treiber geht man doch direkt auf den PC > los. Tut mir leid, ich kann dir nicht folgen. Mir scheint, dass du dir manche Dinge umständlicher vorstellst, als sie am Ende sind. > Ich habe mir einmal das CDC Beispiel von Microchip angesehen, und da > verwenden sie um die 15 Dateien. Ja, die meisten Frameworks, die die Hersteller so anbieten, sind ziemlich generisch aufgebaut und dadurch reichlich umständlich. Ich habe mal für AT90USB ein CDC-Implementierung geschrieben (für das µracoli-Projekt), die kommt mit 1400 Zeilen C-Code in einer einzigen Datei aus, während sowohl das Atmel-Framework als auch Dean Cameras Opensource-Framework (LUFA) sich in endlosen Abstraktionen ergehen, verteilt auf einen relativ großen Baum an Quelldateien. Dafür können diese Frameworks eben alle gängigen device types implementieren, während ich mich auf das absolute Minimum für eine CDC-Implementierung beschränken wollte. Von der Benutzbarkeit her spielt das aber sicher keine große Rolle, solange man so ein Framework einfach 1:1 benutzen will und nicht unbedingt bis ins letzte verstehen. > Aber soweit ich es überblickt habe, > muss man nur die Device Descriptor und Configuration Descriptor, sowie > die Strings anpassen? Auf sowas läuft es bei USB mehr oder weniger immer hinaus, wenn man schon mal eine funktionierende Firmware hat.
OK, bin schon etwas weiter gekommen mit dem Verständnis. Aber hier happerts noch:
1 | /* Configuration 1 Descriptor */ |
2 | ROM BYTE configDescriptor1[]={
|
3 | /* Configuration Descriptor */ |
4 | 0x09,//sizeof(USB_CFG_DSC), // Size of this descriptor in bytes |
5 | USB_DESCRIPTOR_CONFIGURATION, // CONFIGURATION descriptor type |
6 | 67,0, // Total length of data for this cfg |
7 | 2, // Number of interfaces in this cfg |
8 | 1, // Index value of this configuration |
9 | 0, // Configuration string index |
10 | _DEFAULT | _SELF, // Attributes, see usb_device.h |
11 | 50, // Max power consumption (2X mA) |
12 | |
13 | /* Interface Descriptor */ |
14 | 9,//sizeof(USB_INTF_DSC), // Size of this descriptor in bytes |
15 | USB_DESCRIPTOR_INTERFACE, // INTERFACE descriptor type |
16 | 0, // Interface Number |
17 | 0, // Alternate Setting Number |
18 | 1, // Number of endpoints in this intf |
19 | COMM_INTF, // Class code |
20 | ABSTRACT_CONTROL_MODEL, // Subclass code |
21 | V25TER, // Protocol code |
22 | 0, // Interface string index |
23 | |
24 | /* CDC Class-Specific Descriptors */ |
25 | sizeof(USB_CDC_HEADER_FN_DSC), |
26 | CS_INTERFACE, |
27 | DSC_FN_HEADER, |
28 | 0x10,0x01, |
29 | |
30 | sizeof(USB_CDC_ACM_FN_DSC), |
31 | CS_INTERFACE, |
32 | DSC_FN_ACM, |
33 | USB_CDC_ACM_FN_DSC_VAL, |
34 | |
35 | sizeof(USB_CDC_UNION_FN_DSC), |
36 | CS_INTERFACE, |
37 | DSC_FN_UNION, |
38 | CDC_COMM_INTF_ID, |
39 | CDC_DATA_INTF_ID, |
40 | |
41 | sizeof(USB_CDC_CALL_MGT_FN_DSC), |
42 | CS_INTERFACE, |
43 | DSC_FN_CALL_MGT, |
44 | 0x00, |
45 | CDC_DATA_INTF_ID, |
46 | |
47 | /* Endpoint Descriptor */ |
48 | //sizeof(USB_EP_DSC),DSC_EP,_EP02_IN,_INT,CDC_INT_EP_SIZE,0x02, |
49 | 0x07,/*sizeof(USB_EP_DSC)*/ |
50 | USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor |
51 | _EP01_IN, //EndpointAddress |
52 | _INTERRUPT, //Attributes |
53 | 0x08,0x00, //size |
54 | 0x02, //Interval |
55 | |
56 | /* Interface Descriptor */ |
57 | 9,//sizeof(USB_INTF_DSC), // Size of this descriptor in bytes |
58 | USB_DESCRIPTOR_INTERFACE, // INTERFACE descriptor type |
59 | 1, // Interface Number |
60 | 0, // Alternate Setting Number |
61 | 2, // Number of endpoints in this intf |
62 | DATA_INTF, // Class code |
63 | 0, // Subclass code |
64 | NO_PROTOCOL, // Protocol code |
65 | 0, // Interface string index |
66 | |
67 | /* Endpoint Descriptor */ |
68 | //sizeof(USB_EP_DSC),DSC_EP,_EP03_OUT,_BULK,CDC_BULK_OUT_EP_SIZE,0x00, |
69 | 0x07,/*sizeof(USB_EP_DSC)*/ |
70 | USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor |
71 | _EP02_OUT, //EndpointAddress |
72 | _BULK, //Attributes |
73 | 0x40,0x00, //size |
74 | 0x00, //Interval |
75 | |
76 | /* Endpoint Descriptor */ |
77 | //sizeof(USB_EP_DSC),DSC_EP,_EP03_IN,_BULK,CDC_BULK_IN_EP_SIZE,0x00 |
78 | 0x07,/*sizeof(USB_EP_DSC)*/ |
79 | USB_DESCRIPTOR_ENDPOINT, //Endpoint Descriptor |
80 | _EP02_IN, //EndpointAddress |
81 | _BULK, //Attributes |
82 | 0x40,0x00, //size |
83 | 0x00, //Interval |
84 | }; |
Verstehe ich das richtig? Hier werden 2 Interfaces generiert, die dann dementsprechende Treiber laden? Das erste hat wohl mit dem CDC zu tun, und das zweite nur noch mit USB, wobei der 2. Endpunkt als In sowie Out verwendet wird. Aber je nach Datenmenge, die gesendet werden soll, wäre es doch besser wenn man mehrere als nur ein 64Byte Output oder Input hat (hier ist auch etwas unlogisch: beide verwenden 64Byte, wobei der Endpunkt nur 64Byte gross ist???)?
Patrick B. schrieb: > Verstehe ich das richtig? Hier werden 2 Interfaces generiert, Ja, das CDC-Modell braucht ein Interface für die Daten und eins als "abstract call management". Letzteres ist (war) eigentlich dafür da, dass man darüber Wählvorgänge eines Modems etc. anschieben kann, ohne dies mittels in-band signalling (vulgo "AT-Befehlen") zu tun. Das brauchst du zwar nicht gar nicht, aber das CDC-Modell besteht darauf, dass es dies gibt, und die meisten Betriebssysteme konfigurieren ihren CDC-Treiber folglich auch nur, wenn das Device das Ding drin hat. Lass es also einfach da ruhen, bis auf ein paar Bytes im Flash ist dir das nirgends im Weg. > die dann > dementsprechende Treiber laden? Nein. Das Betriebssystem lädt genau einen Treiber für all dies. > Das erste hat wohl mit dem CDC zu tun, > und das zweite nur noch mit USB, Versuch' doch nicht, CDC und USB trennen zu wollen. CDC heißt "communication device class" und ist eine der möglichen Geräte- klassen, die man in einem USB-Gerät implementieren kann. > wobei der 2. Endpunkt als In sowie Out > verwendet wird. CDC braucht 3 Endpunkte (was auch der Grund ist, warum man es offiziell nicht auf einem Lowspeed-Device implementieren kann: dieses soll laut Spec nur 2 Endpunkte unterstützen). Generell ist ein Endpunkt auf dem USB unidirektional, wenn man also eine bidirektionale Verbindung aufbauen will, braucht man davon zwei (wobei das Bit 7 in der Endpunkt-Nummerierung die Richtung unterscheidet, d. h. die haben dann die Nummern 0x02 und 0x82). Diese beiden Endpunkte sind vom Typ "bulk", d. h. sie dienen dem Massen-Datentransfer. Der dritte Endpunkt ist ein sogenannter Interrupt-Endpunkt (wobei USB gar keine wirklichen Interrupts kennt, aber das ist jetzt 'ne andere Geschichte). Ähnlich wie das abstract call management ist das eher "historisch gewachsen". Ich habe jetzt nicht ganz genau im Kopf, wofür der da ist, aber vermutlich könnte damit das Modem Dinge wie einen ankommenden Ruf vermelden. Der muss gemäß CDC-Spec auch einfach da sein, obwohl du ihn nicht wirklich brauchst. Aber wie oben: lass ihn, wie er ist, er stört dich nicht. > Aber je nach Datenmenge, die gesendet werden soll, wäre > es doch besser wenn man mehrere als nur ein 64Byte Output oder Input hat Nein, du brauchst für deine Daten nur einen Endpunkt in jede Richtung. Ob die Hardware dann dahinter mehr als einen FIFO setzen kann, um die Verarbeitung zu beschleunigen, ist 'ne andere Sache. Da kenne ich mich mit den PICs nicht aus, bei den USB-AVRs ist es aber so, dass sie mehr als einen FIFO-Block im Wechsel automatisch benutzen können. Man kann also die Hardware vom USB in den einen FIFO Daten schieben lassen, während die Firmware gerade den zweiten FIFO (desselben Endpunkts) verarbeitet. Erst, wenn alle FIFOs voll sind (weil die Firmware nicht hinterher kommt), dann würde es einen "stall" geben, d. h. die Datenflusssteuerung würde in Richtung Host vermelden, dass jetzt erstmal gewartet werden muss. Diese Datenrichtung interessiert dich ja allerdings gar nicht, du brauchst ja die andere Richtung. Für dein eigenes Verständnis tätest du gut daran, dich mal über den Aufbau des USB und der Übertragung darüber sowie ggf. dann auch die CDC zu informieren. Ob du dafür die (eher trockene) USB Spec nimmst oder irgendwo ein Tutorial findest, ist egal, aber wie das Zusammen- spiel von Endpunkten, Pipes, Interfaces etc. ist, dass kannst du besser nachlesen, als dir das hier aus dritter Hand vorkauen zu lassen.
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.