Hallo :) bei mir war jetzt hmm 2 Jahre Pause in der µC-Entwicklung und ich wollte mich bei euch informieren, ob sich mittlerweile ein altes Problem gelöst hat. Damals war AVR und USB ja kaum möglich. Entweder per FT232 oder per Software-Emulation (als HID in Low-Speed) oder die sündhaftteuren und wenig verwendeten AVRs mit USB. War alles nicht so toll ... Ich verwendete daher die (ARM7) AT91SAM7-µCs, die echte Full-Speed USB hatten. Die sind aber auch schon überholt ... Abgelöst durch Cortex M3? Welche Controller sind denn derzeit "Inn"? Vielen Dank für eure Hilfe! Thomas
asdf1024 schrieb: > Welche Controller sind denn derzeit "Inn"? Wie du schon selbst sagtest: asdf1024 schrieb: > Cortex M Von welchem Hersteller (STM, NXP oder doch ganz was anderes) ist dann vermutlich eher wieder eine Geschmacksfrage
asdf1024 schrieb: > Ich verwendete daher die (ARM7) AT91SAM7-µCs, die echte Full-Speed USB > hatten. Die sind aber auch schon überholt ... Abgelöst durch Cortex M3? Nachfolger sind dann doch schnell gefunden ATSAM3S/4S. Gleiches USB Interface um weitere mögliche Endpunkte und entsprechenden Puffer-Speicher erweitert. USB Pullup Steuerung ist in die USB Pins gewandert (kein zusätzlicher GPIO mehr) Die Umstellung von SAM7S auf SAM4S ging hier ziemlich unproblematisch über die Bühne. Lediglich die Clock hat mich etwas gefoppt. Pin kompatibel obendrein. (Ein paar Sonderpins [z.B. VDDFLASH] sind jetzt GPIO, sprich ATSAM4 läuft im SAM7 Layout aber nciht zwingend umgekehrt)
Die stärkeren µC die gerade "IN" sind, sind eigentlich hier aufgelistet: http://www.coocox.org/CooCox_CoIDE.htm Siehe unter "Supported Device:" da gibt es eine große Auswahl vieler Hersteller. Alle mit Cortex-M0 und Cortex-M3/M4 Kern. Natürlich sind da auch einige dabei die kein USB dabei haben, aber auch welche die sogar Hi-Speed unterstützen (manche mit separatem USB PHY Chip). Welchen man davon nimmt ist Geschmackssache. Von Atmel und Holtec sind nur wenige Devices zur Auswahl, daher würde ich eher zu einem anderen Hersteller raten um einfach mehr Flexibilität zu haben (Speicher Größe/Gehäuseauswahl/Peripheriefunktionen). Für mich ist derzeit ein STM32 in - aber das weiß hier eigentlich ja schon jeder ;-)
:
Bearbeitet durch User
Markus Müller schrieb: > on Atmel und Holtec sind nur wenige Devices zur Auswahl Das dürfte am z.B. Atmel Studio liegen, dass die CooCox Gemeinde von der Seite wenig Zulauf bekommt. Digikey listet zur Zeit 27 Seiten á 25 Variationen von Atmel Cortex M0-4 Ich denke das wird also eher an der CooCox gemeinde liegen, dass die weniger Zulauf von dieser Seite bekommen aufgrund des Atmel-Studios.
Danke schonmal für eure Hinweise! Oh, das coocox-Dings gabs damals nicht ... > CoIDE is a new, free and highly-integrated software development > environment for ARM Cortex MCU based microcontrollers, which includes all > the tools necessary to develop high-quality software solutions in a timly > and cost effective manner. It integrates CoBuilder and CoDebugger for > simplicity and ease of use. Ist ja schonmal ein Super Tipp und ein (Neu-)Einstiegspunkt! Das war ja auch oft das Problem ... Der Kern war zwar fast immer gleich - mit Ausnahme der Peripherie - aber die Tools und Toolchain ... Je konfortabler und kostenloser desto besser natürlich ... Werd ich mir gleich mal im Detail anschauen :)
Bei USB ist NXP derzeit weit vor STM oder Atmel, dank USB-ROM Treiber.
Um MSC, CDC oder HID zu nutzen, muss man nur den Deskriptor übergeben
und die I/O-Funktionen füllen z.B.:
void GetInReport(uint8_t src[], uint32_t length)
...
void SetOutReport(uint8_t dst[], uint32_t length)
...
ROM **rom = (ROM **)0x1fff1ff8;
void USBIRQ_IRQHandler()
{
(*rom)->pUSBD->isr();
}
void Init(void)
{
HidDevInfo.idVendor = USB_VENDOR_ID;
HidDevInfo.idProduct = USB_PROD_ID;
HidDevInfo.InReportCount = 1;
HidDevInfo.OutReportCount = 1;
HidDevInfo.InReport = GetInReport;
HidDevInfo.OutReport = SetOutReport;
(*rom)->pUSBD->init_clk_pins();
(*rom)->pUSBD->init();
(*rom)->pUSBD->connect();
}
asdf1024 schrieb: > Danke schonmal für eure Hinweise! > > Oh, das coocox-Dings gabs damals nicht ... > >> CoIDE is a new, free and highly-integrated software development >> environment for ARM Cortex MCU based microcontrollers, which includes all >> the tools necessary to develop high-quality software solutions in a timly >> and cost effective manner. It integrates CoBuilder and CoDebugger for >> simplicity and ease of use. > > Ist ja schonmal ein Super Tipp und ein (Neu-)Einstiegspunkt! > > Das war ja auch oft das Problem ... Der Kern war zwar fast immer gleich > - mit Ausnahme der Peripherie - aber die Tools und Toolchain ... > > Je komfortabler und kostenloser desto besser natürlich ... > > Werd ich mir gleich mal im Detail anschauen :) Ich habe noch eine Lektüre die Einsteigern hilft, der Artikel: STM32 für Einsteiger Diese Infos sind weitestgehend für alle Chips mit Cortex-Mx Kern übertragbar. Alle Hersteller bieten entsprechende Demo-Boards und Software-Demos. Und gleich bekomme ich sicher wieder von irgendjemandem Haue - schnell wegrenn.
Lothar schrieb: > Bei USB ist NXP derzeit weit vor STM oder Atmel, dank USB-ROM Treiber. > Um MSC, CDC oder HID zu nutzen, muss man nur den Deskriptor übergeben > und die I/O-Funktionen füllen z.B. Ui, das ist ja praktisch! Das $%§$-USB war mit dem SAM7 schon relativ aufwändig ... Hast du einen Lieblings-LPC? Hatte mir damals die auch mal angeschaut, ich weiß aber nicht mehr, was mir da nicht gepasst hat ... Wars vlt die Toolchain? Hmm ...
Markus Müller schrieb: > Ich habe noch eine Lektüre die Einsteigern hilft, der Artikel: > STM32 für Einsteiger Danke, kuck ich mir auch an!
Lothar schrieb: > Bei USB ist NXP derzeit weit vor STM oder Atmel, dank USB-ROM > Treiber. > Um MSC, CDC oder HID zu nutzen, muss man nur den Deskriptor übergeben > und die I/O-Funktionen füllen z.B.: > ...und ist dann wahrscheinlich ziemlich von den Einschränkungen des ROM-Treibers enttäuscht. So zumindest auf dem LPC1343. Der kann HID, aber festhalten: es ist ein einziger simpler Report Descriptor hartkodiert im Treiber!
greg schrieb: > So zumindest auf dem LPC1343. Der kann HID, > aber festhalten: es ist ein einziger simpler Report Descriptor > hartkodiert im Treiber! Einer ist natürlich schon drin, nämlich 1 byte I/O bits :-) Das ist aber egal, man macht einfach structs für die gewünschten I/O Daten und dann: HidDevInfo.InReportCount = sizeof(InStruct); HidDevInfo.OutReportCount = sizeof(OutStruct); Im USB ROM Treiber sieht der Report vermutlich so ähnlich aus (sieht man ja nicht): HID_USAGE_PAGE_LED, HID_USAGE_LED_GENERIC_INDICATOR, HID_LogicalMin(0), HID_LogicalMax(1), HID_ReportCount(8), HID_ReportSize(1), HID_Output(HID_Data | HID_Variable | HID_Absolute)
Lothar schrieb: > Das ist aber egal, man macht einfach structs für die gewünschten I/O > Daten und dann: Das bringt leider gar nichts, wenn man tatsächlich ein Eingabegerät implementieren möchte.
morob65 schrieb: > Microchip PIC18, PIC32, ... Mit so einem obskuren Schrott fange ich nicht an :D Uhm, sorry ... Gibt sicher einige, die mit den beiden Familien erfolgreich arbeiten. Aber PIC18 oder ein PIC32 mit Mach32-Kern ... Ne, nicht unbedingt :)
greg schrieb: > Das bringt leider gar nichts, wenn man tatsächlich ein Eingabegerät > implementieren möchte. Dafür sind die USB ROM Treiber auch nicht gedacht, die Anwendung ist Kommunikation zwischen PC-Software GUI (z.B. VB, LabVIEW) und uC als RS232-Ersatz.
>Uhm, sorry ... Gibt sicher einige, die mit den beiden Familien >erfolgreich arbeiten. Aber PIC18 oder ein PIC32 mit Mach32-Kern ... >Ne, nicht unbedingt :) Hmm, MACH32. Da hab ich auch noch eine ISA-Grafikkarte in irgendeiner Kiste rumliegen. Wußte gar nicht das die auch als Prozessorkern taugt......
morob65 schrieb: > :-D > > Schrott ist immer relativ, Microchip wird auch sehr viel verbaut. hihi :) Ja sorry, ich musste einiges mit PIC16F84 und F873 basteln und das in Assembler und naja, seitdem hab ich eine permanente Abneigung gegen PICs :D PIC18 und PIC32 sind damit nicht vergleichbar, aber trotzdem :D
Lothar schrieb: > greg schrieb: >> Das bringt leider gar nichts, wenn man tatsächlich ein Eingabegerät >> implementieren möchte. > > Dafür sind die USB ROM Treiber auch nicht gedacht, die Anwendung ist > Kommunikation zwischen PC-Software GUI (z.B. VB, LabVIEW) und uC als > RS232-Ersatz. Autsch. Also eine "offiziell supportete Frickellösung" während der eigentliche Einsatzzweck von HID vernachlässigt wird :D Super, NXP sag ich nur ;-) Um auch was produktives zu leisten, als IDE hat Coocox mir zu viele Macken, daher werfe ich mal in den Raum: http://www.emblocks.org/ ist ein Ableger von Code::Blocks und unterstützt wesentlich mehr Chips als Coocox. Der ARM-GCC und der ST-Link GDB ist gleich mitgeliefert, man kann also für STM32 sofort loslegen. Segger J-LINK geht bei mir auch damit. Es gibt in der neuen Version sogar einen Import von Coocox-Projekten (habe ich aber noch nicht getestet) Einziges Manko bisher, was mir so aufgefallen ist: Symbole im Projekt suchen ("Find Definition", "Find Implementation" usw) funktioniert oft nicht.
Ich arbeite derzeit mit der ATxmega Reihe. Davon unterstützen auch einige USB 2.0 und dank ASF gibt es auch einige Hilfestellungen. Meine Erfahrung ist jedoch, dass schon noch diverse Bugs vorhanden sind, die einem das Leben nicht unbedingt einfacher machen.
Benjamin P. schrieb: > Meine Erfahrung ist jedoch, dass schon noch diverse Bugs vorhanden sind, > die einem das Leben nicht unbedingt einfacher machen. Was für Bugs wären das z.b.?
Warum gibt's diese integrierten IDEs (also z.B. CooCox und Em::Blocks) eigentlich nur für Windows 32 bit? Und viel schlimmer, warum findet man diese Information bei Em::Blocks nirgendwo auf der Website?
Falls die USB-AVRs doch in Frage kommen sollten, dann mal LUFA anschauen. Damit kommt man eigentlich sehr schnell zum Ziel http://www.fourwalledcubicle.com/LUFA.php
asdf1024 schrieb: > oder ein PIC32 mit Mach32-Kern ... Ne, nicht unbedingt :) Was stört dich am MIPS32 Kern?
> hihi :) Ja sorry, ich musste einiges mit PIC16F84 und F873 basteln und > das in Assembler und naja, seitdem hab ich eine permanente Abneigung > gegen PICs :D > PIC18 und PIC32 sind damit nicht vergleichbar, aber trotzdem :D Da hast Du Dir ein völlig unnötiges Vorurteil aufgebaut, Du vergleichst ja auch keinen VW-Käfer aus 1968 mit einem Golf von 2014. Bei den PIC32 gibt es sehr viele mit USB und/oder Ethernet und lieferbar und preiswert sind sie auch. Bei Microchip gibt es auch eine SEHR gute Unterstützung mit Frameworks und fertigen Programmierbeispielen auf der Homepage.
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.