Nabend Zusammen, ich möchte für meine Anwendung aus verschiedenen Gründen einen STR730 (ARM7-Core) nutzen. Ich plane unter anderem große Datenmengen, die ich von AD-Wandlern und vom CAN aufzeichne auf einer CF-Karte abzulegen. Um die Daten dort wieder runterzukriegen, würde ich gern USB verwenden. Nun kriegt man mit den FTDIs meines Wissens nach nur max 3Mbit/s hin. Daher habe ich überlegt einen PIC oder AVR mit direktem USB-Interface zu verwenden, um dann per UART oder wie auch immer mit diesem zu kommunizieren und eine schnellere Verbindung herzustellen, da ich mit 3 Mbit/s bei Datenmengen von bis zu 2 GByte sonst Stunden zum runterladen benötige. Hat jemand ne Idee oder fällt euch vielleicht ne deutlich einfachere Möglichkeit zur Datenübertragung ein? Die CF-Karte zu entfernen und direkt an den Rechner zu stöpseln kommt nicht in Frage. Gruß Tobi
USB 480Mbps ist in Controllern eher selten anzutreffen, daher sind's ohnehin nicht mehr als 12Mbps (theoretisch). Gibt's keine STR7 mit USB drin?
Habt Ihr Erfahrungen aus der Praxis, was die ARMs effektiv über das USB-Interface schauffeln können? Den 730er habe ich wegen der 3 CANs genommen. Die 750er haben nur einen und damit genau einen zu wenig für meine Anwendung. Wobei ein externer CAN-Controller vermutlich weniger kritisch ist, als externes USB, oder? Gruß Tobias
Der unguenstige Aspekt an USB ist einen PC Treiber zu schreiben.
Wenn du es beim Datentransport eilig hast, scheint mir ein µC mit internem 100Mbps Ethernet sinnvoller. Fehlende CAN Kanäle kannst du ja ggf. extern erweitern, da ist die Datenrate ja nun erheblich geringer. Ausserdem ist die Softwareseite auf dem PC bei Ethernet erheblich einfacher.
Naja, nicht zwingend, soweit ich weiss. Zumindest die FTDIs liefern ja schon Treiber mit, die über die emulierte Com-Schnittstelle hinausgehen. Wie es bei den ARMs ist, weiss ich ehrlich gesagt nicht.
@Andreas: Daran habe ich auch schon gedacht, allerdings muss ich dann auf dem µC TCP/IP oder UDP implementieren. Das ist vermutlich auch kein Zuckerschlecken...
Hi, vielleicht könntest du auch einfach nur einen anderen externen USB Controller als den FTDI nehmen. Es gibt da ja durchaus auch welche, die High Speed unterstützen. Ist dann natürlich nicht mehr das Rundum-Sorglos-Paket wie mit dem FTDI. Optimale Lösung denke ich wäre sicherlich, wenn du den MCU bei der USB-Kommunikation aussen vorläst. Du schließt also ein USB High Speed Controller und deinen MCU parallel an die CF-Karte. Wenn du deine Daten aufnimmst, spricht nur der MCU mit der Karte. Wenn du die Daten ausliest, spricht nur der USB Controller mit der Karte. Dabei könnte das ganze als Mass Storage Device angesprochen werden. Ein Beispiel für einen USB Full Speed Controller ist z.B. der TUSB6250. Auch von Cypress gibt es ähnliche. Viele Grüße Michael
UDP ist ziemlich einfach. Einfacher als USB. Und für TCP gibt's fertige Lösungen.
Wenn du die Daten auf der Karte in einem für den PC lesbaren Dateisystem speichern kannst, dann könntest du sie auch mit einem Kartenleser auslesen.
Das hört sich ja alles ganz gut an: Ich hätte den Vorschlag sich den Blackfin Prozessor anzusehen und sich ein Application Board zu besorgen. Der läuft mit Linux oder auch native mit einfachen Programmen. Datendurchsatz ist da massig vorhanden und wenn man Linux benutzen würde hätte man sofort auch Netzwerkunterstützung. Eine AD-Wandler Platine muss man ja denke ich sowieso erstellen, die könnte man dann einfach mit einem Linux Treiber über die IOs abfragen. Somit würde sich also vom Know-How ergeben: - Compiler und/oder Toolchain anschauen - Linux Treiber entwickeln (man kann da mit einfachen Beispielen anfangen) - Platine mit AD-Wandlern designen - Server Applikation schreiben die die Daten vom Board über TCP/IP bereitstellt - Client Applikation z.B. für Windows schreiben Gruß Sven
> ich möchte für meine Anwendung aus verschiedenen Gründen einen STR730 > (ARM7-Core) nutzen Sorry, im ersten Satz überlesen.
@Thomas: leider werde ich die Karte nicht entfernen können, wenn das Gerät erstmal in Betrieb ist. @Sven: Rein vom Prinzip her ging es mir bei der Auswahl des µCs um eine einigermaßen erprobte Plattform, mit 2 CANs integriert, wenn möglich, und Peripherie in Form von UART, SPI, Timern usw. Von daher ist der Blackfin wohl auch keine schlechte Wahl, zumal in meinem Projekt auch ein sehr fitter Linuxprogrammierer involviert ist und ich mich auf die Hardware konzentrieren könnte. Offensichtlich ist aber noch kein Chiphersteller auf die Idee gekommen, mehr als einen CAN zu spendieren, wenn man schon Ethernet und oder USB an Board hat. Nach kurzem Infos sammeln im Netz ist der Blackfin wohl doch etwas oversized für meine Anwendung. Im Grunde wird das nur ein konfigurierbarer Datenlogger. Gruß Tobias
@Andreas: Ich las leider schon viel vom verbuggtem CAN in den LPCs, hast Du Erfahrung damit? Gruß Tobi
Das dürfte sich auf den CAN Controller vom alten LPC2129 (sowie LPC2194,...) beziehen. Der hat einige Bugs, darunter einer der FullCAN in Hardware ausschliesst. Aber wenn man diese Bugs umschifft funktioniert er. Hat mir jedenfalls keinen Ärger bereitet, andererseits ist meine App auch nicht sonderlich anspruchsvoll. Die Errata-Liste vom LPC2300 sieht deutlich zivilisierter aus, da scheint man nur auf Overruns aufpassen zu müssen. Allerdings ist das Teil recht neu, und Errata-Listen pflegen mit den Jahren zu wachsen.
@Andreas: Ja, das mit den leeren Erratas bei jungen Controllern kenne ich leider auch...allerdings gibt es den auch mit integriertem SD/MMC Interface, was sehr reizvoll für die Datenspeicherung ist. Gruß Tobias
ich würde mir den Controller nach dem Flaschenhals aussuchen, also in deinem Fall die externe Verbindung. CAN ist leicht dazugestrickt. Wenn möglich, nimm auf jeden Fall Ethernet.
Ich nehme an mit Ethernet wird der Lesezugriff auf das Speichermedium der Flaschenhals. Hat einer von euch Erfahrung mit dem möglichen Datendurchsatz über Ethernet mit ARMs? Gruß Tobias
Bin ich erst mal froh, dass ich nicht als erster die LPCs in Spiel gebracht habe ;-) Die LPC23xx haben schone einen hohen Durchsatz wenns um Ethernet geht, sogar einen eigenen Bus, eigene 16k SRAM, eigene DMA Controller sind spendiert worden, damit im Spitzenbelastungsfall die CPU noch was anderes tun kann, z.B. CAN messages abzuholen oder USB (ebenfalls unterstuetzt mit einer eigenen DMA). Soweit ich weiss sind so langsam die Teile der Rev "B" zu haben, die haben fast alle Erratas soweit bekannt beseitigt und laufen auch volle Geschwindigkeit bei 72 MHz. Die kommen und gehen sehr schnell bei Digikey. Zu meinem Erstaunen gibt es dort einige LPC24xx, im Grunde dasselbe Teil aber zusaetzlich mit einem externen Bus. STR73x wuerde ich deshalb nicht unbedingt empfehlen, weil es sich um wirklich alte Technologie handelt und sobald die Automotive Anwendung mal nicht mehr in Serie produziert wird es wohl auch mit der Restlebensdauer des STR73x nicht mehr so lange hin sein. Der STR75x ist da eine ganz andere Geschichte, der ist noch recht jung, gefertigt in viel neueren Prozessen und kann auch 5V, den wird es wohl noch lange Zeit geben, ebenso den STR9x, der zwar dafuer, dass es ein ARM9 ist in der Performance zu wuenschen uebrig laesst aber sich definitiv mit den schnellsten ARM7 messen kann. Also wenn ST, vielleicht muss es nicht gerade der 730 sein. Gruss, Robert
Hallo Robert, wo ich dich gerade am Wickel habe: Ich habe mich eben mal durch das Errata des LPC2378 http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2378.pdf gewühlt. Da ist der CAN.1 Fehler nach wie vor nicht behoben. Allerdings verstehe ich die Fehlerlösung nicht so richtig: Workaround:1. Recovering from this situation is only possible with a soft reset to the CAN controller. 2. If software cannot read all messages in time before a third message comes in, it is recommend to change the acceptance filtering by adding further acceptance filter group(s) for messages, which are normally rejected. With this approach, the third incoming message is accepted and the Data Overrun condition is avoided. These additional messages are received with the corresponding group index number can be easily identified and rejected by software. 1. Mit einem Softreset des CAN controllers kriege ich ihn wieder zum Laufen. 2. Wenn die Software es nicht packt, die Receive Buffer zu leeren, bevor eine dritte Nachicht den Data Overrun auslöst, dann soll man die Acceptance Filter so anpassen, dass Sie Nachrichten durchlassen, die sie vorher geblockt haben, weil dann die dritte Nachricht ohne auslösen des Overruns akzeptiert wird? Das widerspricht sich doch irgendwie...denn gerade wenn diese dritte Nachricht dann durchkommt, versucht er sie in einem der Receive Buffer abzulegen und merkt, dass die noch nicht gelesen worden ist und schon ist der Overrun da...oder nicht? Gruß Tobias
tja, das scheint ne ewige und schwierige Geschichte zu sein, so ein CAN-Controllerchen zu integrieren. Ich hätte da echt keinen Bock drauf, mich mit solchen Dingen rumzuschlagen. Für kleines Geld gibts den MCP2515 oder SJA1000. Damit habe ich immer schnell und effektiv alle CAN-Probleme erledigen können und auf getestete und funktionierende Software zurückgreifen können. Nebenbei erlaubt das mir,den Controller meiner Wahl zu nehmen. Ein Design läuft mit dem AT90CAN128, dass hat mich ne Menge Zeit gekostet :-(.
crazy horse wrote: > tja, das scheint ne ewige und schwierige Geschichte zu sein, so ein > CAN-Controllerchen zu integrieren. Und die Ironie daran ist, dass auch Microchip selbst von dieser Seuche befallen ist. Auch da hat der Versuch, µCs mit integriertem CAN rauszubringen, vor allem für deftig gewürzte Buglisten gesorgt (PIC18Fx58,2580,PIC30,PIC24-ECAN). Während der MCP2515 in der aktuellen Version vergleicherweise sauber ist.
Hmm, ich habe schon in mehreren Designs PIC18F4580 und PIC18F8680 benutzt. Da hatte ich überhaupt keine Probleme mit den integrierten CAN-Controllern. Gruß Tobias
Mag sein, aber dessen Bugs sind ärger als die vom MCP2515. Was mich besonders stört, ist ein Bug, der scheinbar in allen integrierten Versionen drin steckt und bislang nur im MCP2515 behoben wurde: Wenn aus irgend einem Grund an passender Stelle in der Interframe Gap eine Störung kommt, dann kann ein Frame mit falscher ID rausrutschen, dessen CRC zur defekten ID passt, somit nicht als defekt erkennbar ist. Das muss allerdings kein Problem sein - ist das Timing aller Nodes in Ordnung und der Bus sauber, dann passiert nichts. Auch ein paar andere Bugs von 2580 stören mich etwas. Insgesamt wirkt der alte 258 auf mich diesbezüglich besser als der 2580.
Andreas Kaiser wrote: > Und die Ironie daran ist, dass auch Microchip selbst von dieser Seuche > befallen ist. Auch da hat der Versuch, µCs mit integriertem CAN > rauszubringen, vor allem für deftig gewürzte Buglisten gesorgt > (PIC18Fx58,2580,PIC30,PIC24-ECAN). Während der MCP2515 in der aktuellen > Version vergleicherweise sauber ist. Das ECAN Modul in den neuen dsPICs ist wesentlich überarbeitet im Vergleich zum "alten" MCP2515. Die haben zB DMA. Ich hab die ECAN Module der 33er schon benutzt und ich kann berichten, dass die Sache funktioniert. Die im Errata beschriebenen Probleme beziehen sich eher auf Randanwendungen die wohl sogut wie nie vorkommen (zB: Loopback Mode). Die Erratas der LPC hingegen haben mich bis jetzt immer davon abgehalten diese mal zu testen.
Willivonbienemaya .. wrote: > Die im Errata beschriebenen Probleme > beziehen sich eher auf Randanwendungen die wohl sogut wie nie vorkommen > (zB: Loopback Mode). Mich stören die Probleme mit den Error Countern. Denn ein Randproblem ist das mitnichten - eine Node allein am Bus und man ist in nullkommanix am Limit. Auch die Overflow-Problematik ist ärgerlich. Und das erwähnte Interframe Gap Problem ist trotz der Überarbeitung drin.
Ja, eigentlich hast du da recht. Bei mir funktioniert der CAN zwar ganz gut, aber wenn ich mir anschau was da schon alles als "workaround" im code steht stimmts schon. das muss nicht sein.
Nochma zum Anfang zurück: Wenn du eh schon eine CF-Karte da dran hast, ist doch das einfachste, parallel an den ATA-Bus, den der ARM zur Verfügung stellt, einen Cypress 68300 dran zu hängen. Der kann Bus-Sharing, wenn du dann das USB Kabel ansteckst und den einen Pin da freigibst, meldet der sich als Massenspeicher an, und du kannst die Daten von deiner CF-Karte mit einigen MByte/s runter ziehen. So machen wir das. Eine Logik sorgt dafür, dass jeweils der andere ATA-Master den Bus auf Tristate schaltet.
Hi Chris, dann müsste ich aber die Daten in FAT auf der Karte ablegen, oder? Gruß Tobias
Jain, nur das auslesen unter Windows wird schwerer da du direkt auf den Speicher zugreifen musst. Du kannst die auch im Rechner formatieren und dann eine Große Datei anlegen und dann nur zwischen den End und Anfangsblöcken der Datei auf die Karte schreiben. Kannst du nicht auch ne 2te Karte reinbauen? Kann ja auch SD oder so sein, dann kannst du bei bedarf auf die Karte kopieren und dann per Kartenleser auslesen. Dann kann der auch weiter loggen. Es gibt auch CF Sata converter.
Hi, eine 2te Karte geht leider nicht, da die Größe der Schaltung kritisch ist und sie im Fahrzeug so verbaut sein wird, dass man nicht rankommt. Gruß Tobias
Hik, danke für den Link. Allerdings wäre da natürlich das Problem, wie man beides zusammen nutzbar auf einer Platine vereint. Also auf der einen Seite auf die SD-Karte schreiben, auf der anderen Seite per USB auslesen. Da müsste ich vermutlich auch per FAT auf die Karte schreiben. Warum ich immer auf FAT rumreite: Die Datenraten, die von meinem Logger auf die Karte fließen, könnten so hoch werden, dass FAT deutlich zu viel Overhead erzeugt, abgesehen von der Implementierung, die ich ja auch noch hinbekommen muss :) Mein momentaner Favorit wäre daher doch das Auslesen per LAN, da es vermutlich auch von der externen Beschaltung die kleinste Lösung ist. Leider hat sich noch niemand dazu geäußert, ob er Erfahrung mit dem LAN-Durchsatz der LPCs hat. Gruß Tobi
FAT muss nicht sein. Kannst die Karte dann auch über die Windows API Funktionen als RAW-Device öffnen und blockweise auslesen. CreateFile(..) in der MSDN ma suchen. Das geht dann auch von beiden Seiten recht fix. Also µC und Windows. Kannst ja dann immer blockweise sehr schnell schreiben, ohne auf Dateien usw. zu achten.
Hmm, damit wäre der Cypress doch wieder im Spiel. Habt Ihr gute Erfahrungen damit gemacht? Gibt es irgendwelche Fallen, auf die ich achten sollte? Gruß Tobias
Also wir haben den mittlerweile in 2 Projekten im Einsatz. In der beschriebenen Konfiguration. Wichtig ist vor allem ein sauberer und SCHNELLER Reset. Da gibts aber ein Dokument bei Cypress. Reset Conditions oder sowas. Ein RC-Glied am Reset geht nicht, es muss ! ein Reset-Chip sein. Ansonsten Plug&Play. Einstecken, EEPROM Programmieren, neu anstecken Festplatte. Wenn du ohne FAT arbeitest, musst du vorher abklären, ob Windows überhaupt einen Laufwerksbuchstaben vergeben will....aber soweit ich das in Erinnerung hab, kann man auch auf physikalische Laufwerke zugreifen....müsste man dann bloß rausfinden, wo genau das Laufwerk hängt. Aber das lässt sich ja mit einem Kartenleser und einer unter Linux auf EXT2 oder so formatierten Karte im Vorfeld abklären. Ansonsten ist FAT ja nicht sooo aufwendig, und bei einer nicht-fragmentierten Karte kannst du ja die Daten auch ein einem Fort draufschreiben. Achso, und lies dir GENAU das Dokument zum Sharen des ATA-Bus durch.
Das ist gut zu wissen, danke! Man neigt ja doch zum Überlesen, wenn man nur bestimmte Infos sucht ;) Ich muss zugeben, dass ich noch nicht das ganze Datenblatt gelesen habe bzw. nur überflogen, kann man das EEPROM des Chips per USB programmieren? Gruß Tobias
Ja, da gibts eine Manufactoring Software samt Treiber von Cypress. Ohne progr. EEPROM meldet der sich als Manufactoring Device. Dann einfach das passende File rein und gut ist. Ist aber alles gut beschrieben. Beim Layout solltest du gleich einen Jumper in der SDA-Leitung des EEPROMS vorsehen, da kannst du immer wieder programmieren. Einmal als Massendatenspeicher programmiert lässt es sich schwer wieder in den Urzustand zurück versetzen. Mit Jumper gehts prima. Machen wir immer so.
2921 wrote:
> Der unguenstige Aspekt an USB ist einen PC Treiber zu schreiben.
Es gibt ne Firma "Thesycon", die bieten einen selbstkonfigurierenden
Treiber an... Ist allerdings kommerziell und kostet etwa 1500 Euro für
die nicht-share/free-ware-Version
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.