Hallo Ich fand bisher, das es kostenlose Libraries bzw. Programme gibt, u.a. von Herstellern von Controllern, z.B. um die USB Schnittstelle korrekt anzusteuern. Ideal wäre zum Beispiel ein Programm im Flash, welches einen von beiden Seiten beschreibbaren und lesbaren Speicher aus dem Ram bereitstellt. Etwas ähnlich interessantes sind ja auch mp3 Kompression für Tonaufnahme, Dateisystemtreiber für SD Cards, und z.B. Fourieranalyse oder wie das heißt. Ich fand auch etwas, aber nur in C oder C für den Gnu Compiler. Leider kann ich mit C nicht, es graust mir davor. Assembler geht, oder Basic könnte auch gehen. Könnt Ihr etwas schlaues dazu sagen? Kann ich als C Laie den Gnu Compiler laden, C Libraries damit kompilieren und dann das ganze im Ergebnis mit Assembler ansprechen? Notfalls kann ich Daten mit einer SD Card übertragen. Die SD Card gibt ein einfaches Laufwerk. Mit einem speziellen Programm geht es ohne Dateisystem. Übrigens gibt es bei Reichelt "große" Arm Controller, die nur 99Cent kosten, anscheinend abgekündigte. Kosten sonst bei etwa 10€. MfG
Matthias Kattelmann schrieb: > Könnt Ihr etwas schlaues dazu sagen? C++ lernen. Damit kannst du all die C Libraries, die von den Herstellern produziert werden, ansprechen und dabei eine richtige Sprache verwenden. Gerade so komplexe Libraries wie für USB schreibt keiner mehr in Assembler, das ist einfach viel zu viel Arbeit, und die ist dann auch noch für die Katz wenn man den Prozessor-Kern umstellt, die Peripherie aber beibehält (Cortex-M0 zu Cortex-M3 oder so), Matthias Kattelmann schrieb: > Kann ich als C Laie den Gnu Compiler laden, C Libraries damit > kompilieren und dann das ganze im Ergebnis mit Assembler ansprechen? Wenn du auf Schmerzen stehst, ja.
Viele ARMs haben USB-ROM-Treiber, da muss man nur wenig machen, z.B. LPC1343: ROM **rom = (ROM **)0x1fff1ff8; void USBIRQ_IRQHandler() { (*rom)->pUSBD->isr(); } (*rom)->pUSBD->init_clk_pins(); (*rom)->pUSBD->init(&DeviceInfo); (*rom)->pUSBD->connect(TRUE);
Lothar schrieb: > Viele ARMs haben USB-ROM-Treiber, da muss man nur wenig machen, z.B. > LPC1343: Ach, und was hast du davon? Schon ein einfacher virtueller COM Port läßt sich SO nicht wirklich aufsetzen, da fehlt einfach noch alles, was wirklich gebraucht wird. Ich hab's hinter mir, hab mir mittlerweile nen VCP für alles, was bei mir so rumfliegt geschrieben. Sinnigerweise gibt's bei NXP bei fast jedem µC nen anderen USB-Core. W.S.
Matthias Kattelmann schrieb: > Leider kann ich mit C nicht, es graust mir davor. Dann sind Mikrocontroller und PC-Systeme nicht das richtige für dich. Matthias Kattelmann schrieb: > Übrigens gibt es bei Reichelt "große" Arm Controller, die nur 99Cent > kosten, anscheinend abgekündigte. Kosten sonst bei etwa 10€. Vielen Dank für die Werbung.
W.S. schrieb: > Schon ein einfacher virtueller COM Port läßt > sich SO nicht wirklich aufsetzen, da fehlt einfach noch alles, was > wirklich gebraucht wird. 1) Ich kenne keine Anwendung bei der HID nicht besser ist als VCOM. Bei VCOM muss auf PC-Seite erst mal der Treiber stabil laufen, bei HID haben die Betriebssysteme bereits generische Treiber (Windows, Linux, MacOS), die eben laufen. 2) Es gibt NXP-Chips mit CDC-Class im ROM, hier ist für VCOM nichts selbst zu programmieren, man muss nur die definierten In/Out-Puffer schreiben bzw. lesen. Das ist ja grade der Punkt von ROM Treibern. 3) Leider ist es bei NXP so, das unverständlicherweise bestimmte Chips diese ROM-Treiber haben (LPC11U00, LPC1345 aufwärts), aber andere nicht. Dementsprechend benötigt man z.B. für den populären LPC1768 einen Software-Stack, und der ist riesig. Ich habe den von IAR als Beispiel, und kann damit z.B. HID mit mehreren Streams problemlos machen. Seltsamerweise funktioniert dies mit den meisten PCs, mit einigen wenigen aber nicht. Mit dem NXP ROM-Treiber funktioniert es immer. Fehler finde ich nicht, auch nicht mit Sniffer. Der ROM-Treiber wird aber einfach nicht auf den LPC1768 portiert.
Lothar schrieb: > Ich habe den von IAR als Beispiel, > und kann damit z.B. HID mit mehreren Streams problemlos machen. > Seltsamerweise funktioniert dies mit den meisten PCs, mit einigen > wenigen aber nicht. Dann wendest Du die Funktionen vermutlich falsch an (Initialisierung, Reihenfolge, Timing, sonstige Konventionen). Oder IAR liefert fehlerhafte Software aus. Lothar schrieb: > Mit dem NXP ROM-Treiber funktioniert es immer. Hier wendest Du den Treiber richtig an. Ich vermute, dass einem die ROM-Implementierung vieles an Stolperfallen vorenthält.
Matthias Kattelmann schrieb: > > Ich fand auch etwas, aber nur in C oder C für den Gnu Compiler. > Leider kann ich mit C nicht, es graust mir davor. > Assembler geht, oder Basic könnte auch gehen. > Was graust dir denn so vor C? Du wirst nicht drumrum kommen. C ist eine der populärsten Programmiersprachen überhaupt und auf Microcontrollern sowieso. Es ist auch weder kryptisch noch schwer.
Hallo Ich hab mich schon mal mit C beschäftigt. An der Stelle, wo ich einen String in eine Zahl umwandeln wollte oder umgekehrt, ist mir der Kragen geplatzt. Wo es in VB eine einfache Funktion dafür gibt, fand ich dasselbe in VC++ oder so, nicht einmal beschrieben. MfG Matthias
Du hast in C die Freiheit, eigene Funktionen und Prozeduren zu erstellen. Wenn Du deine String-Umwandlung in Assembler hinbekommst, dann auch in C. Der Algorithmus ist nämlich exakt der gleiche, ganz egal, welche Programmiersprache nun zur Umsetzung eingesetzt wird. Wenn Dir C zu schwierig ist, dass USB kommunikation erst Recht. USB ist weitaus komplexer, als eine serielle Schnittstelle.
Matthias Kattelmann schrieb: > brigens gibt es bei Reichelt "große" Arm Controller, die nur 99Cent > kosten, anscheinend abgekündigte. Kosten sonst bei etwa 10€. Du wirst http://www.reichelt.de?ARTICLE=68402 meinen. So etwas möchte man sich heutzutage eigentlich nicht mehr antun; der Interruptcontroller des ARM7TDMI ist "beliebt". KannIchauch schrieb: > Wo es in VB eine einfache Funktion dafür gibt, fand ich dasselbe in VC++ > oder so, nicht einmal beschrieben. Dann musst Du besser suchen lernen. atoi und Co. sind dokumentiert.
Erst mal Danke für die Motivation.
Ja genau, den meinte ich unter anderem. Bei Reichelt sind 3
verschiedene, superkleine Teile mit mindestens 64 Anschlüssen für
99Cent.
Ich muss aufpassen, das ich nicht anfange, Teile zu horten, und den
Schritt, alles einmal auszuprobieren und zu programmieren, vergesse.
Interruptcontroller, wo ist das Problem? Stimmt da was nicht?
Wahrscheinlich muss viel eingestellt werden, Interruptadressen,
Pinconnectoren("PINSEL") usw..
Wegen dem C, vielen Dank, ich werde noch einmal verschiedene Hilfen
durchschauen, vielleicht komm ich doch mit klar.
Überhaupt scheinen die meisten Probleme auf mangelnde, bzw.
Dokumentenmängel zurückzuführen zu sein.
Allerdings bin ich der Meinung, das C wird allgemein hoffnungslos
überbewertet.
Ich hab schon mal was mit Forth, VB, Assembler, Javascript gemacht.
War jetzt mit Python zugange, für ein CAD-Programm. Hebt sich aber nicht
extrem fremdartig hervor.
habe folgendes gefunden:
http://www.cplusplus.com/
Matthias Kattelmann schrieb: > Allerdings bin ich der Meinung, das C wird allgemein hoffnungslos > überbewertet. Aus Erfahrung sprichst Du nicht.
Stefan schrieb: > Wenn Dir C zu schwierig ist, dass USB kommunikation erst Recht. USB ist > weitaus komplexer, als eine serielle Schnittstelle. Zunächst mal ist auf PC-Seite USB mit VB deutlich einfacher als mit C, siehe Beispiele: http://www.lvr.com/hidpage.htm Dann ist bei ARM UART/USART ein Kapitel für sich, daher hat z.B. NXP in neueren Chips auch serielle Treiber im ROM. Damit ist von der Handhabung kein Unterschied mehr zwischen seriell und USB. Zudem ist die USB PID mit dem ROM-Treiber inbegriffen.
Matthias Kattelmann schrieb: > Überhaupt scheinen die meisten Probleme auf mangelnde, bzw. > Dokumentenmängel zurückzuführen zu sein. C ist wegen der intensiven Nutzung wohl die am besten dokumentierte Sprache... An jeder Uni/FH mit naturwissenschaftlihen Fächern wirst du mindestens ein C-Vorlesungsskript finden... Es gibt den Standard, wo solche Funktionen erklärt sind, Bücher, die einem das komplett beibringen, und natürlich Google. Matthias Kattelmann schrieb: > habe folgendes gefunden: > http://www.cplusplus.com/ http://cppreference.com ist besser.
Rufus Τ. Firefly schrieb: > Aus Erfahrung sprichst Du nicht. Ach Rufus, Eigentlich weißt du es doch ganz genau: C ist wahrlich keine schöne Sprache, es ist auch keine, die man duch bloßes Lesen erlernen kann, sondern eine mit vielen Fallen und Fußangeln und Unzulänglichkeiten, mit denen auszukommen man erstmal lernen muß. Ich kann schon verstehen, daß sich die Welt aufteilt in Leute, denen C zu eklig ist und Leute, denen alles andere zu geschwätzig erscheint. Ansonsten finde ich die LPC2131 bei Reichelt für 99 Ct soweit ganz in Ordnung und deinen Widerwillen gegen dessen Interrupt-Controller nicht wirklich stichhaltig. Im Gegenteil: Mit dem FIQ kann man Sachen machen, die mit einem neueren Cortex SO nicht mehr machbar sind. Allerdings die Bemerkung des TO über 10 Euro war und ist doch heftig übertrieben. Ist ja doch ein eher kleinerer µC. Und nochwas zu HID versus VCOM: "Ich kenne keine Anwendung bei der HID nicht besser ist als VCOM" schrieb da jemand. Was soll so ein Spruch??? Für solche "void" HID-Geräte (die es in Wirklichkeit garnicht sind) gibt es auf keinem PC irgendwelche üblichen Anwendungen. Ich bin deshalb der festen Ansicht, daß man anständigerweise HID genau solchen Dingen wie echten HID-Geräten vorbehalten sollte. Für VCOM hingegen gibt es massenweise Anwendungen und es ist auch gut in eigentlich alle PC-Betriebssysteme integriert. Man braucht eigentlich nur usbser.sys und ein .inf und das war's. Ganz generell gilt, daß es beim USB eine ganze Breitseite von verschiedenen vordefinierten Klassen gibt und daß es eigentlich ein einziger Bastelpfusch ist, ein Device in eine Klasse hineinzumogeln, was dort eigentlich garnicht hinein gehört. Ach ja, und dem TO rate ich - mal wieder.. - die Lernbetty in der Codesammlung an. Da finden sich genug Konvertierungen, so daß einem nicht der Kragen platzen muß. Ich weiß, tibetanische Gebetsmühle... immer wieder, aber die Leute hier stolpern ja auch immer wieder über die gleichen Sachen. W.S.
W.S. schrieb: > Ach ja, und dem TO rate ich - mal wieder.. - die Lernbetty in der > Codesammlung an. Da finden sich genug Konvertierungen, so daß einem > nicht der Kragen platzen muß. Ich weiß, tibetanische Gebetsmühle... > immer wieder, aber die Leute hier stolpern ja auch immer wieder über die > gleichen Sachen. Jup, wie z.B. #defines für Typen und Konstanten zu verwenden, gefährliche Makronamen, inkonsistente Bezeichner-Namen, ... - doch halt, nicht dass das in der "Lernbetty" auch völlig kaputt ist und die vielleicht gar nicht so gut als "beispielhafter" Code geeignet ist?!?!?!
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.