Senden und empfangen auf dem UART mit ISR kompatibel zur bisherigen RP6lib

[oberallgeier]

... Mit dem Atmel Studio kannst du auch ARMs proggen, da gibts eine ARM Toolchain ...

Sorry wenn ich jetzt als Flachhirn komme: Vor Deinem Hinweis von eben auf Atmel Studio mit ARM-Funktionalität wußte ich nix davon. Nun lese ich in der RELEASE NOTES Atmel Studio 6.1 ( 42130A-MCU-06/2013 ) schon auf der ersten Seite den gleichen Hinweis. Danke, dass Du das hier erwähnt hattest (mich interessiert an diesem Thread hier die UART-Thematik, die ich als Nicht-PR6er mit PDanneggers - modifizierter - Bibliothek gelöst habe).

Studio 6 wollte ich bisher nicht nehmen, weil das m.E. viel Overhead für eine doch eher aufwändige Projektbearbeitung mitbringt, die für meine Hobbyprojekte nicht nur ~head vielleicht sogar ~kill ist. Dachte ich. Aber nun wirds doch überlegenswert. Bisher hatte ich nur Ratschläge gelesen zu einer separaten IDE für den ARM (hier und hier). Deshalb wird diese Thematik auch zumindest noch die Kollegen Gerhard/oderlachs und White_Fox interessieren.

Frage/Bitte: könntest Du mir bitte etwas mehr zu Deinen Erfahrungen mit dem Studio6, besonders im Hinblick auf ARM schreiben, vielleicht hier hin (wegen OT hier)? Danke im Voraus!

[RolfD]

Hallo,
ja die Lib vom Dannegger als Basis tuts auch... es gibt viele Libs zur AVR Serial, welche alle nur mit Wasser kochen bzw. Grundfunktionen bieten. Ich selbst hab mir das auch angeeignet indem ich mir verschiedene Libs und die Manuals dazu angesehen habe. Ich versuche aber immer nachzuvollziehen was warum wie gecodet wurde, und dann sieht man halt irgendwann, das einer eine Fehlerprüfung drin hat.. und wie sie funktioniert.. und der andere eben nicht... so als ein Beispiel. Deswegen ist aber mein Code nicht automatisch besser als der von jemand anderem. Benutze also gern die Lib vom Dannegger weiter.
Meine Vorschläge/Änderungen betreffen aber weniger die eigentliche ISR mit dem Buffer - was technisch sogar ähnlich gelöst ist wie ich grade sehe, wobei der algo zur Berechnung der Bufferposition komplizierter ist - sondern eher so Erweiterungen wie xon/xoff in der ISR.
Zum Studio, im Prinzip ist das Atmel Studio ein modifiziertes Visualstudio von MS, eine durchaus erprobte, stabile und vielseitige IDE mit einer Toolchain alla winavr oder winarm, was beides wiederum den GCC als Crosscompiler nutzt. Da gibts kaum Unterschiede zwischen ARM und AVR. Ich denke da gibt es nicht viel zu schreiben, es funktioniert halt und wenn man dran gewöhnt ist, auch gut.
Es gibt viele weitere IDEs die so arbeiten und es gibt viele Leute die eine oder andere IDE präferieren und sicherlich ihre guten Gründe dafür haben.
Ich bin der Meinung, man sollte die Tools nutzen mit denen man am besten zurecht kommt und da ich nun mal aus der Windows und Linux Programmierung komme, sind mir große IDEs wie eclipse oder eben VS nicht fremd. Ich persönlich finde z.B. in makefiles händisch rum zu fingern viel lästiger aber letzlich arbeitet auch die GCC toolchain nur mit makefiles.
Daher will ich da keine Empfehlung zum Umstieg geben. Es kommt drauf an das ein Auto fährt, nicht wie dick die Reifen sind - und Gas geben tut eh der Fahrer.... Um das mal bildlich darzustellen.
Auf dein outing als Flachhirn weis ich nichts zu sagen... du wirst wissen warum du es schreibst.
Gruß

[oberallgeier]

... Da gibts kaum Unterschiede zwischen ARM und AVR. Ich denke da gibt es nicht viel zu schreiben, es funktioniert halt ...

Danke für die Beschreibung. Das mit dem "Flachhirn" sollte meine völlige Unerfahrenheit mit den ARMs hervorheben. Leider lese ich nicht wirklich aus Deinem Post ob und welche ARMs Du mit dem AVRStudio schon programmierst hattest.

Eigentlich wollte ich nämlich wissen ob Du schon konkrete Erfahrungen mit dem Programmieren der ARMs (welche ?) unter AVRStudio gemacht hattest ("... Deinen Erfahrungen mit dem Studio6, besonders im Hinblick auf ARM ..."). Hast Du?

Nochmal danke für Deine Mühe.

[RolfD]

http://www.atmel.com/products/microc...m/default.aspx
Das sind die ARMs, die soweit vorbereitet sind aber wenn man sich damit auseinander setzt, stellt man fest das auch andere Devices möglich sind. Wie gesagt.. WinARM ist eine GCC Toolchain.
Ich selbst hab LPC2138 Boards wie dieses: http://www.etteam.com/product/arm7_lpc2138.html

Gruß