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 ;-)
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 ...
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
> 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.
