Krautkanal.com

Veröffentlicht am 2015-12-01 00:20:57 in /t/

/t/ 29203: Microcontrollerfaden

alta1r Avatar
alta1r:#29203

Dieser Bernd hat ein ungeheueres Interesse an Microcontrollern, muss sich selbst aber leider als Neubiene verorten.

Ist Bernd gewillt mir ein paar Fragen zu beantworten?

Was sind SoC und SoPC?
Habe keine adequate Erklärung gefunden.

Hat Bernd Erfahrung mit dem ESP8266?

Bernd versucht momentan einen Gyro mittels I2C mit einem AVR-Controller zu verbinden, die Daten dann mittels UART an den PC zu senden, UART war kein Problem, I2C stellt sich schon ein bisschen haariger dar (kote in Assembler). Hat Bernd Tipps für mich?

An was für Projekten arbeitet Bernd gerade?

Auch: Allgemeiner Microcontrollerfaden :3

donjain Avatar
donjain:#29204

>>29203
Selbstsäge wegen Rechtschreibfersagen

karalek Avatar
karalek:#29205

>>29203
> Neubiene
> Assembler

Ich weiß nicht ob das der richtige Weg für dich ist

herrhaase Avatar
herrhaase:#29206

>>29203
> Neubiene
> Was sind SoC und SoPC?
> Habe keine adequate Erklärung gefunden.

> Assembler

Lerne erst mal Gurgel....

https://www.google.com/?q=define:SoC

https://www.google.com/?q=define:SoPC

polarity Avatar
polarity:#29207

>>29203
Endlich mal wieder ein fast* Qualitätsfaden. Finde es sehr löblich, dass du mit Assembler anfängst. Spasten halten Assembler immer irgendwie für besonders schwer, dabei ist es einfach nur das Kettenglied zwischen löten und C. Ich würde sogar behaupten, kein normaler Mensch kann vernünftig programmieren lernen wenn er nicht mit Assembler anfängt. War jedenfalls bei mir so, also gib nicht auf!

IIC ist eigentlich auch nicht viel schlimmer als USART. Möglicherweise sprichst du den Gyro einfach falsch an, falsche Adresse oder so. Hast du das mit den Open-Collector-ausgängen kapiert? Nutzt du vielleicht direkt eine IIC-Schnittstelle? Hast du die richtig konfiguriert?
Zur Not einfach mal eine IIC-Sequenz in Assembler coden (Pin setzen, ein paar Nops, Pin rücksetzen usw...). Auch ohne Oszi kannst du so mit einem Multimeter und Stepbetrieb prüfen, ob der Controller die richtigen Bitmuster erzeugt. Sind die Bitmuster richtig und du bekommst immernoch keine Antwort, guck dir nochmal das Datenblatt vom Gyro an.
Jahr fert
Nazibernd hat derzeit mindestens drei Projekte im Ofen, die ihm spontan einfallen:
> ein Kaguyagerät
> Belichtungsgerät weiter perfektionieren (wird schwer, da die Grundfunktionalität bereits gegeben ist)
> Einfacher Audioverstärker den ich an meinem Schlafzimmer-PC direkt an die 12V-Schiene hängen kann plus ein paar Boxen (wird vielleicht sogar noch dieses Jahr fertig)

Zu AVR-Assembler kann ich dir leider keine konkreten Ratschöäge geben. Das einzige was mir dazu einfällt ist, dass ich mir mal die Architektur vom AVR angesehen habe und die für Scheiße befand. Würde nicht assemblieren wollen, aber wenn du schonmal dabei bist -- mach einfach weiter. Ist halt nicht so eine schön aufgeräumte Architektur wie beim PIC, sondern erinnert eher an den Versuch eines besoffenen Chinesen einen 8085 nachzubauen.

Daten an den PC senden hab ich bis Heute im Alleingang nicht gebacken bekommen, wenn das bei dir läuft, hast du mir schonmal was voraus.

t. 15 Jahre Elektronikbasteln

*Für einen vollwertigen Qualitätsfaden mit KC-Gütesiegel musst du noch ein paar selbstgemachte Bilder liefern

jonkspr Avatar
jonkspr:#29209

>>29205
Ich war der Auffassung, dass Assembler der beste Weg ist, um das Programmieren embeddeder Systeme zu lernen, was >>29207 ja mehr oder weniger sekundiert hat.
Ausserdem besucht Bernd momentan eine Technikerschule (E-technik) und dort wird es ihm auch in Assembler beigebracht.
Natürlich kommt im Unterricht bei 3h/Woche über ein Jahr nicht die ganz große Erleuchtung, aber wenn man mir so schon den Einstieg anbietet, dann nehme ich das gerne an.

>>29206
Natürlich habe ich schon die ein oder andere Erläuterung ergurgelt. Bloß war da nichts dabei, was einen nicht prompt mit anderen, mir unbekannten Begriffen überhäuft.
Selbstverständlich könnte bzw. werde ich mir das einmal genauer zu Gemüte führen. Hätte ja sein können, dass das Ganze von Expertenbernd in ein paar Sätzen auch erkärt werden könnte.

>>29207
Danke fürs Lob, Bernd :3

Es ist nicht so, dass ich IIC probiert und nicht zum Laufen gebracht hätte, sondern ich habe mich eingelesen und versuche zu verstehen, wie die Kommunikation zu Stande kommt. Dabei bin ich etwas ins Stocken geraten, weil im Gegensatz zum UART hier ein ganzer Arsch mehr an Registern rumgejubelt wird.
Ich habe mir zu diesem Zweck eine fertige IIC Libary in Assembler heruntergeladen und bin momentan dabei, die Funktion der Libary nach zu vollziehen mit Hilfe des Datenblattes und Artikeln auf mikrocontroller.net.
Kommunikation mit dem PC über UART ist äusserst einfach, Bernd. Solltest du mal probieren.

Bernd versucht die IIC Verbindung mit seinem MK2-Brett (MyAVR) zum Laufen zu kriegen, hab auch alles da um nur die nötigsten Teile um den MC auf einem Steckbrett auf zu bauen, wird auch gemacht, nachdem ich weiss wies funktioniert.

Abei Fotos vom noch unspektakulären Aufbau sowie von dem selbst geschusterten UART Modul in der Hoffnung, einen Qualitätsfaden zu begründen.

xarax Avatar
xarax:#29212

> Hat Bernd Erfahrung mit dem ESP8266?
Ja, ein wenig.

Hier einige hilfreiche Informationen in Kürze:
- die Teile benötigen 3.3 V; Bastelei mit Spannungsreglern und Transistoren ist fast immer nötig, um andere Komponenten anzusteuern
- was USB-to-Serial-Adapter betrifft, scheinen die ESP8266 wählerisch zu sein; also viele verschiedene Adapter kaufen und ausprobieren
- super rubust sind die Teile nicht; lieber ein paar Module als Reserve für eventuelle Fuck-ups einplanen
- mit HTerm lässt sich mit ESP8266 über die Serial-Schnittstelle sprechen
- ein NodeMCU Custom-builds lässt sich auf http://nodemcu-build.com/ erstellen
- mit dem esptool lässt sich die Firmware flashen
- mit dem luatool lassen sich Lua-Skripte laden
- Lua ist recht gut (und kurz!) auf http://learnxinyminutes.com/docs/lua/ erklärt
- Beispiele für Webserver, Ansteuern von bunten Lichtern, etc. gibt es auch in ausreichender Menge

Beginner-Einkaufsliste (die Dinge, die man ohne viel Vorwissen bei eBay oder Aliexpress ḱaufen kann):
- mehr als ein ESP8266-Board (für die meisten Sachen ist das einfache ESP-01 ausreichend)
- einige DC-DC-Converter (um 5 V oder 12 V auf 3.3 V zu bringen)
- mehrere USB-to-Serial-Adapter mit verschiedenen Chips

die Ich-weiß-ungefähr-was-ich-tue-Einkaufsliste (der projektspezifische Kleinkram, der lokal gekauft werden kann):
- Netzteile (wenn noch nicht vorhanden)
- Transistoren/Logic-Level-MOSFETs
- ...

kuldarkalvik Avatar
kuldarkalvik:#29213

> Hat Bernd Erfahrung mit dem ESP8266?

Ja, kauf dir gleich 2-3 Stück mehr, die geben manchmal gerne den Geist auf und fallen dann in einen undefinierten Zustand aus dem es wohl kein zurück gibt, gerade in Verbindung mit NodeMCU.
Ich weiß nicht ob die aktuelle NodeMCU immer noch solche Zustände fabriziert, mein letzten ESP habe ich mir vor einem halben Jahr zerschossen damit und seit dem kein Bock mehr auf die Dinger und warte jetzt lieber auf den Nachfolger ESP32

http://www.cnx-software.com/2015/11/05/espressif-esp32-dual-core-soc-features-faster-wifi-bluetooth-4-0-le-and-more-peripherals/

kennyadr Avatar
kennyadr:#29216

>>29212
> NodeMCU Custom-builds
Was genau ist das?
Das ESP8266 an und für sich ist ein SoC oder? Das heisst, wenn ich die Firmeware entsprechend flashe, könnte ich es programmieren wie einen MC?

ich hatte mir vorgestellt, die aus dem Gyro per IIC vom MC ausgelesenen Werte über UART an das ESP8266 zu schicken und von dort aus über W-Lan an den PC.
Ginge das ohne größeren Aufriss?

>>29213
Wie ich sehe hat das Nachfolgemodell Blauzahn und IIC, das macht es natürlich schon interessant, fraglich ist bloß wann das zu haben ist.

hammedk Avatar
hammedk:#29217

>>29216
>> NodeMCU Custom-builds
> Was genau ist das?
Da kannst du Module (z. B. eines für I²C) von NodeMCU an-/ausschalten um den begrenzten Speicher auf dem ESP8266 gut zu nutzen.

> ... ohne größeren Aufriss?
Sollte sogar mit noch weniger Aufriss gehen: Du benutzt den ESP8266 einfach für alles.
Mit dem Gyro spricht der Chip dann über die IO-Ports, wandelt die Daten in ein brauchbares Format um und stellt sie dann z. B. per HTTP-Server im WLAN zur Verfügung.

marciotoledo Avatar
marciotoledo:#29218

Ja, würde es ebenso machen, den MC kannste dir sparen und gleich direkt den Gyro über I2C ansprechen.
Du kannst dann NodeMCU oder direkt C für den ESP benutzen.
NodeMCU hat halt den Vorteil es man alles einfach in Lua programmiert, ist also gleiche Schwerigkeitsstufe wie z.B. Arduino
I2C-Bib ist sogar schon eingebaut:
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#i2c-module

haydn_woods Avatar
haydn_woods:#29222

>>29217
> spricht der Chip dann über die IO-Ports
Soll das heissen ich schreibe mir eine IIC Routine für normale IO-Ports? Weil IIC hat das ESP8266 ja nicht. Oder hat Dummbernd das bloß übersehen?

kuldarkalvik Avatar
kuldarkalvik:#29223

>>29218
Das ist natürlich eine Überlegung wert. Um mehr zu lernen, würde ich trotzdem erst einmal die IIC Verbindung mit dem Controller in Assembler machen.

herrhaase Avatar
herrhaase:#29225

>>29222
> Soll das heissen ich schreibe mir eine IIC Routine für normale IO-Ports?

Genau, sowas nennt sich Bit-Banging

michaelkoper Avatar
michaelkoper:#29226

>>29222
> Weil IIC hat das ESP8266 ja nicht. Oder hat Dummbernd das bloß übersehen?

Dafür gibt's ein NodeMCU-Modul. (Ausprobiert habe ich das allerdings nicht.)

christauziet Avatar
christauziet:#29231

Bernd liefert!

Habe die letzten Tage mehrere Stunden damit zu gebracht mir eine IIC Libary zu coden damit der Controller mit dem Gyro sprechen kann.
Ergebnis im Anhang oder hier:
http://pastebin.com/46DqTVKr

newbrushes Avatar
newbrushes:#29242

>>29231
Habs jetzt mal überflogen, sieht so aus ob es funktionieren könnte. Gut gemacht Bernd.
Statt allgemeiner Arbeitsregister "tempx" empfehle ich dir, mit Treiberspezifischen Speicherzellen zu arbeiten die du einfach irgendwo global deklarierst. Push und Pop brauchst du eigentlich nur bei Interruptbearbeitung, weil Interrupts sich nicht vorher anmelden.
Durch die Verwendung global bekannter Speicherzellen sparst du das C-Typische Datengeschubse auf den Stack bei Unterprogrammaufrufen. Auch reduzierst du damit die Wahrscheinlichkeit, dich zu verzeigern oder dir Stackinkonsistenzen einzufangen. Im Endeffekt bau ich meine Unterprogramme immer wie Peripheriebausteine auf: ein paar "Steuerregister," "Statusregister," und "Datenregister;" fertig ist der Lack. Und dass diese Speicherzellen dann auch belegt sind, wenn sie gar nicht gebraucht werden stört nicht: gibt ja genug.

zl;ng: Statische Speichervergewaltigung für den Endsieg!

krdesigndotit Avatar
krdesigndotit:#29243

>>29242
Funktioniert auch, hab's getestet.

> Treiberspezifischen Speicherzellen
Ich kann dir nicht ganz folgen, was soll das sein?
> Push und Pop brauchst du eigentlich nur bei Interruptbearbeitung
Es macht auf mich den Eindruck, als wäre das sichern der im Unterprogramm genutzten Arbeitsregister obligatorisch, gehört sich sozusagen so.

iamsteffen Avatar
iamsteffen:#29244

Guck mal, die Skizze läuft direkt auf dem ESP: http://pastebin.com/6Pbdvk9Z

Übrigens nicht den Fehler machen und einen gefälschten FTDI USB->Seriell Wandler verwenden. Die mag der ESP nicht. Da hilft dann nur noch Chip runterföhnen, wegschmeißen und Original drauflöten.

romanbulah Avatar
romanbulah:#29246

>>29243
Stimmt, hatte da einen architektonischen Denkfehler. Ich hab nicht gerafft, dass temp1 und temp2 Prozessorregister sind. Dachte das ist einfach irgendwelcher general purpose RAM (GP-RAM). Prozessorregister benennt man eigentlich(?) nicht um. Bist jedenfalls der Erste, bei dem ich das sehe. Hab aber auch noch nicht von so unglaublich vielen Leuten die Quellen studiert.

Mit der Aussage, das Sichern der Prozessorregister bei einfachen calls wäre "guter Stil," wäre ich vorsichtig:
Du sicherst deine Daten auf jeden Fall irgendwann im GP-RAM, also warum auf dem Stack statt dort, wo du die Endlösung deiner Berechnung brauchst? Da der Speicher für die Endlösung ohnehin schon reserviert ist, ist die Verwendung des Stacks Speicherverschwendung. Und das Pushen und Poppen kostet wertvolle Takte (Einmal die Endlösung speichern musst du sowieso).
Jetzt kommt sicher gleich wieder ein Hochsprachenaffe angekrochen und will uns was von Sicherheit erzählen und dass es ja auf die paar Takte und das bisschen Speicher nicht ankommt. -> Jeder Programmierer der kein Interesse daran hat, seine Programme so klein und schnell wie möglich zu machen ist ein Kandidat fürs Brausebad.
Ich würde es jedenfalls genau anders herum machen: der aufrufende Prozess hat grundsätzlich keinen Anspruch auf unveränderte Prozessorregister und nur dann wenn er Wert darauf legt, sichert der aufrufende Prozess das was er noch braucht. In den allermeisten Fällen wird der aufrufende Prozess aber gar nichts brauchen, beziehungsweise kannst du die Register klug zur Argumentenübergabe benutzten.
Als typische größere Aufgabe würde mir spontan zum Beispiel eine schnelle Fouriertransformation einfallen: Da liegt im GP-RAM dein Datenarray und im Prozessaufruf sagst du deinem Unterprogramm vielleicht wo das Array liegt, wie groß es ist, aus wie vielen Bits ein Datum besteht und vielleicht noch ein, zwei Korrekturfaktoren. Wenn du vor so einem Call noch irgendwas in den Prozessorregistern hast was du danach unbedingt noch brauchst, machst du meiner Meinung nach irgendwas falsch (Spaghetticode oder so).


> Treiberspezifischen Speicherzellen
> Ich kann dir nicht ganz folgen, was soll das sein?
Dein IIC-Unterprogramm ist ein "Treiber," wenn man so will. Denn mit diesem Treiber kann man relativ komfortabel Daten über IIC schicken und empfangen. Wenn du viel rumprogrammierst wirst du dir häufig solche "Treiber" basteln, für ADCs, DACs, DMA, TIMER etcpp. Im Endeffekt bildet ein "Treiber" irgendwas kompliziertes auf was einfaches ab. Ich mach mir zum Beispiel gerne Displaytreiber bei denen die zwei Displayzeilen a 16 Zeichen auf zwei 16-Byte-Arrays im RAM abgebildet werden. Wenn man irgendwas ans Display ausgeben will, schreibt man es einfach in diese Arrays. Der "Treiber" geht diese Arrays periodisch durch und bringt den Inhalt so zur Anzeige. Damit ein solcher "Treiber" funktioniert und du dich im Hauptprogramm wirklich um nichts mehr kümmern brauchst, als diesen Treiber ab und zu mal aufzurufen, braucht er ein bisschen Speicher um sich seinen Status zu merken. Die Initialisierungssequenz solcher Flüssigkristalldisplays ist meist ziemlicher Krebs und besteht aus einem Dutzend Schritten. Durch den dem Treiber spendierten RAM kannst du dann so tolle Sachen machen, wie dass der Treiber bei jedem Aufruf einen Schritt macht und beim nächsten Aufruf noch weiss, wo er war. Die Alternative dazu ist, immer alles in einem Rutsch zu machen -- das ist dann weniger Multitaskingfreundlich und Anfällig für Fehler:
Beim LCD-Treiber pollt man typischerweise ein Busyflag. Gestaltet man den Treiber nun so, dass er das Flag so lange pollt bis das Flag nicht mehr gesetzt ist, dann ein Datum sendet und erst dann zurückkehrt, kann man deine Bombe sehr leicht entschärfen indem man das Display abreisst. Guckt der Treiber jedoch nur kurz nach dem Flag, sendet gegebenenfalls ein Byte und kehrt auf jeden Fall nach spätestens N Takten zum Hauptprogramm zurück, bist du bundesligaechtzeitfähig. Du kannst dann sicher vorhersagen, wie lange es dauert bis dein Gerät explodiert.


Ist aber vielleicht auch einfach alles eine Stilfrage und nicht endgültig zu beantworten. Wenn dich mein Ratschluss irgendwie inspiriert und du denkst: "hmm, könnte hinhauen, was der sich da ausdenkt," dann freu ich mich. Und wenn du denkst: "Was blubbert Nazibernd da wieder für einen Schwachsinn zusammen," dann ist es mir auch egal.

Bernd Avatar
Bernd:#29247

>>29244
Danke Bernd. Ich habs mal überflogen, mein Problem ist nur, dass ich das Coden in Assembler lerne und abgesehen davon lediglich in C++ schwache Kentnisse besitze. Grob verstanden hab ich den Code allerdings schon.
Werde - um einen Lerneffekt zu erzielen - vorerst alles über einen Controller lösen, später allerdings versuchen das ESP und den Gyro "autark" zu betreiben, dann werde ich mich entweder in LUA einarbeiten oder versuchen so Etwas in Assembler ab zu bilden.
Kannst du mir den konkret einen FTDI USB->Seriell Wandler empfehlen?

>>29246
> Prozessorregister benennt man eigentlich(?) nicht um
Da mir mit der .def Direktive die Möglichkeit gegeben wird, nehm ich das auch wahr. Der Kot gewinnt meiner Meinung nach an Übersicht, liegt aber wohl mit Sicherheit im Auge des Betrachters.

> Du sicherst deine Daten auf jeden Fall irgendwann im GP-RAM
Auf die Gefahr hin zu nerven, muss ich erneut nachbohren:
Dass die Daten im Laufe des Programmablaufes mal auf den RAM geschrieben werden, ist ja klar, aber um mit ihnen zu arbeiten, muss ich sie doch in einem Arbeits-/Prozessorregister stehen haben. Oder etwa nicht?

> der aufrufende Prozess hat grundsätzlich keinen Anspruch auf unveränderte Prozessorregister
Ich wäre genau vom Gegenteil ausgegangen, aber die Idee, benötigte Daten gegebenenfalls im aufrufenden Prozess zu speichern, statt im Unterprogramm um Takte zu sparen, leuchtet ein.

> dem Treiber spendierten RAM
Wie geht das von statten?
Ich kann dem "Treiber" eigene Arbeitsregister zu weisen oder wie?
Nach was muss ich suchen um Informationen darüber zu finden?

> Die Initialisierungssequenz solcher Flüssigkristalldisplays ist meist ziemlicher Krebs
Ich kenne das Fühl

Das mit der Multitaskingfähigkeit hab ich auch verstanden, macht Sinn, findet jedoch bei meinem Vorhaben wohl keine Anwendung.

> Wenn dich mein Ratschluss irgendwie inspiriert
Ich bin für jede Hilfestellung/Inspiration/Information dankbar :3

creartinc Avatar
creartinc:#29248

>>29247
Nachtrag

Ich sehe gerade, dass der Code aus
>>29244
ja gar kein LUA sondern C++ ist.

bruno_mart Avatar
bruno_mart:#29249

>>29247
> Dass die Daten im Laufe des Programmablaufes mal auf den RAM geschrieben werden, ist ja klar, aber um mit ihnen zu arbeiten, muss ich sie doch in einem Arbeits-/Prozessorregister stehen haben. Oder etwa nicht?

Prinzipiell ja. Es gibt aber Ausnahmen wie indirekte Adressierung mit Zeigern, wo du ziemlich direkt im RAM arbeitest. Oder an die Peripherie, da kommst du auch in einem Takt ran beim AVR (glaube ich). Es gibt also durchaus Situationen, da ist es egal ob die Daten schon in den CPU-Registern stehen oder weiter weg. Du kannst solche Situationen natürlich auch ganz frei konstruieren.

> Ich wäre genau vom Gegenteil ausgegangen, aber die Idee, benötigte Daten gegebenenfalls im aufrufenden Prozess zu speichern, statt im Unterprogramm um Takte zu sparen, leuchtet ein.

Dann hast du im Grunde verstanden worauf ich hinaus wollte. Mach halt im Aufrufenden Prozess erst alles fertig, speichere gegebenenfalls deine Ergebnisse im GP-RAM und rufe dann dein Unterprogramm. Oft ist das nur eine Frage der Ordnung. Ein guter Compiler würde übrigens genau das tun: deine Anweisungen nach Abhängigkeiten durchsuchen und den Hochsprachecode so umordnen und in Maschinencode umsetzen, dass am Ende was möglichst flottes und kleines dabei herauskommt.
Das geht nicht immer denn es gibt immer irgendwelche Ausnahmen. Aber als Ansatz ist es aber nicht verkehrt, glaube ich.

> dem Treiber spendierten RAM
> Wie geht das von statten?

Na du kannst dir doch RAM-Zellen schnappen und da irgendwas reinspeichern. So wie du mit einer DEFINE-Anweisung die Prozessorregister umbenennest, kannst du auch RAM-Zellen umbenennen. Ich schätze mal beim AVR ist es wegen der Neumann-architektur etwas nerviger als beim PIC, weil du möglicherweise immer erst die Adresse als Konstante laden musst, eh du an den RAM kommst. Mal ein bisschen Pseudocode:

PIC:
#define LCD_CTRL 0x042 // RAM mit der Adresse 42
movlw 0x88 // Arbeitsregister mit 0x88 laden
movwf LCD_CTRL // den Inhalt des Arbeitsregisters im RAM an Adresse 42 speichern (unser Steuerregister)
movf LCD_CTRL // den Inhalt aus dem RAM ins Arbeitsregister laden

ATMEL: // ich nehme einfach mal an, r6 und r7 wären Pointerregister für indirekte RAM-Adressierung und mit den Befehlen nehm ich es auch nicht so genau, keine Ahnung, kenne das Instructionset nicht, musst du gegebenenfalls von Kauderwelsch in Sprache übersetzen
#define LCD_CTRL 0x042
ldi r6, LOW LCD_CTRL // r6 mit dem unteren Teil der RAM-Adresse laden
ldi r7, HIGH LCD_CTRL // r7 mit dem oberen Teil der RAM-Adresse laden
mov r1, r6r7 // r1 mit dem Inhalt der durch r6 und r7 adressierten RAM-Zelle laden

mov r6r7, r1 // und rückspeichern

Irgendwie so... Wie das genau geht müsste ich auch erst gucken. Dürfte aber ziemlich weit vorne im Manual der IDE erklärt sein, die du nutzt. r6r7 haben meist einen besonderen Namen, Pointerregister oder so. Beim 8085 waren es die Register H und L die in den Mnemoniks dann als HL zusammengefasst wurden.

Besonders der Code beim Atmel sieht erstmal verdammt krebsig aus (noch schlimmer wird es bei ARMs), aber wenn du mit Macros arbeitest geht es. Einfach mal Macros ansehen und dann für die Aufgaben, die du häufig machst, Macros schreiben. Dabei aber immer die Rechenzeit im Auge behalten -- damit du am Ende nicht für jeden Blödsinn ein Macro nimmst welches in 5 Instruktionen aufgelöst wird, auch wenn du insgesamt mit 3 Instruktionen hingekommen wärst.

Druck dir das Instructionset aus und:
Versuche mit dem Instructionset zu spielen!

wiljanslofstra Avatar
wiljanslofstra:#29251

>>29249
Auszug aus dem Datenblatt:
"Six of the 32 registers can be used as three 16-bit indirect address register pointers for Data
Space addressing – enabling efficient address calculations. One of the these address pointers
can also be used as an address pointer for look up tables in Flash Program memory. These
added function registers are the 16-bit X-register, Y-register, and Z-register, described later in
this section."
Ich schätze mal das hast du gemeint.
Das ist in der Tat interessant aber davon lasse ich vorerst die Finger. Mir scheint die Gefahr zu groß dabei versehentlich bereits genutzten RAM zu überschreiben.

iqbalperkasa Avatar
iqbalperkasa:#29254

>>29251
> Mir scheint die Gefahr zu groß dabei versehentlich bereits genutzten RAM zu überschreiben.

Musst du dir den Mikrocontroller etwa mit irgendwem teilen? Hast du nicht sowieso den gesamten Code selbst geschrieben? Dann solltest du nämlich alles unter Kontrolle haben. Man könnte fast meinen, dein gesamter Code läuft in den CPU-Registern und im Stack. Gibe mal deine kompletten Quellen.

jonkspr Avatar
jonkspr:#29256

>>29254
Ja noch ist das Programm sehr klein und daher besteht die Gefahr wohl nicht.
Aber ich habe leider keinen Einblick, wie der Controller den RAM verwendet, deswegen die Aussage.
Der Controller wird ja wohl nicht nur dann etwas in den RAM schreiben, wenn ich das explizit befehle, oder?
> Quellen
Hab ich nix, ausser:
mikrocontroller.net
Atmel Datenblätter
Das was mir der Dozent um die Ohren wirft und
Youtube
z.B. Patrick Hood-Daniel:
www.youtube.com/channel/UCC7ifdmN7ebFo-eXBUZkeiw

Meiner Meinung nach übrigens ein sehr guter Kanal, kann ich empfehlen.

jamesmbickerton Avatar
jamesmbickerton:#29257

>Der Controller wird ja wohl nicht nur dann etwas in den RAM schreiben, wenn ich das explizit befehle, oder?

Doch. Weil dein Controller kein Betriebssystem oder irgendeinen anderen Code als deinen ausführt, wird kein einziges Bit ohne dein Wissen geschubst. Das ist einer der Vorteile, wenn man sich mit Assembler plagt :3
Du kannst den gesamten Arbeitsspeicher nutzen, darfst nur keine Adressen beschreiben, die für IO-Register vorgesehen oder anderweitig reserviert sind. Diese Adressbereiche findest du aber im Register Summary im Datenblatt.

lanceguyatt Avatar
lanceguyatt:#29278

>>29256
Der Controller schreibt nur in den RAM wenn du ihm das befiehlst, zumindest in Assembler. Wenn du aber C verwendest und ausversehen Optimierung in den Compiler kommt, dann kann das schon mal anders aussehen.

id835559 Avatar
id835559:#29292

>>29257
>>29278
Danke, Bernds.
Ich habe weiter getüftelt und stehe gerade vor einem Problem.
Zum einen läuft meine TWI-Library jetzt zwar, aber irgendwas ist immer noch im Argen.
Es funktioniert jetzt, wenn ich in der Initialisierug den START schicke und im loop dann immer wieder den REPEAT START. Es funktioniet aber nicht, wenn ich am Ende des Loops STOP schicke und zu Beginn wieder START.
Woran könnte das liegen?

Und: Ich habe mich jetzt an mal diesem Arduino Sketch orientiert:
playground.arduino.cc/Main/MPU-6050?action=sourceblock&num=1
Diesen Sketch habe ich auf einen Arduino geladen, den ich hier rumliegen habe und es hat einwandfrei funktioniert.
Also habe ich nun die Initialisierung in meinem Programm genauso vorgenommen (den wake-up) und danach frage ich testweise das Register 0x40 ab. Das ist die Erdbeschleunigung, sollte mir also immer was anzeigen. Allerdings kriege ich da konsequent 0 geliefert.
Zu Hülf, Bernd, mir raucht bald der Schädel ab vor dem Teil.

Code im Anhang

mj_berthelsen Avatar
mj_berthelsen:#29293

>>29292
Läuft jetzt.
Selbstsäge da den Wald vor lauter Bäumen nicht sehend gewesen.

leelkennedy Avatar
leelkennedy:#29300

Taugt das Ding als Programmierer etwas?
http://www.reichelt.de/DIAMEX-ALL-AVR/3/index.html?&ACTION=3&LA=446&ARTICLE=110345&artnr=DIAMEX+ALL+AVR&SEARCH=isp+programmer
Möchte mit AVRDude programmieren.

saulihirvi Avatar
saulihirvi:#29302

>>29300
Also ich würde es mir zwei mal überlegen, jetzt noch etwas mit Atmel-Prozessören anzufangen:
http://www.handelsblatt.com/unternehmen/it-medien/kampf-um-atmel-dialog-bekommt-bei-uebernahme-konkurrenz/12715104.html
Atmel wird nämlich gerade serviert, freue mich schon auf das Mett bei den ganzen Arduinolüftern ^_^
Tut mir Leid, OP.

surajitkayal Avatar
surajitkayal:#29303

>>29302
OP hier.
Sieht das für dich so aus, als ob sie den Laden dicht machen?
Kann ich mir irgendwie nicht so ganz vorstellen. Schade wäre es aber schon. Atmel hat meiner Meinung nach eine gute Dokumentation und allerhand Quellen zum Selbstlernen im Internet, aber sobald man es mal kann, sollte der Umstieg auf sagen wir mal PIC ja nicht all zu schwer fallen oder?
Könntest du bzw. gerne auch ein anderer Bernd mal die Vorteile von PIC schildern?
Konkret würde mich da interessieren, wie sich das für Bernd bemerkbar gemacht hat.
Dass immer gegen die von-Neumann-Architektur gepöbelt wird habe ich schon mitbekommen, aber was genau ist denn an der Architektur von PIC überlegen?
Ich würde gerne später mal mit Microcontrollern arbeiten und habe das Gefühl, dass die Atmel-Controller nur im Hobbybereich so weit verbreitet sind. In der Industrie sind es wohl eher Motorolla und TI, die den Markt beherrschen.
Um eine Umstellung werde ich daher wohl eh nicht herumkommen.
Und ganz abgesehen davon, würde ich ungern als so ein versteifter Atmellüfterjunge enden.

subburam Avatar
subburam:#29304

>>29303
Dicht werden sie den Laden wohl nicht machen, es sieht nur so aus als wäre die von einem bekifften norwegischen Studenten entwickelte RISC-Architektur doch nicht sooo konkurrenzfähig, wie die Atmellüfter gerne behaupten (behaupteten). Auf jeden Fall werden die Controller die bis jetzt im Umlauf sind noch mindestens 20 Jahre lang weiterproduziert. Gibt schon auch genug industrielle Abnehmer (ja, auch mein Schafstall gehört dazu). Mein Beitrag zur Zerschlagung des Atmelkartells ist es, eines unserer Produkte von einem kleinen Atmel auf einen kleinen LPC von NXP umzustricken. Das bekloppte an der Geschichte ist: der LPC kann deutlich mehr, kostet aber etwas weniger. Es war nicht leicht meine Vorgesetzten davon zu überzeugen: "Warum nehmen Sie einen Prozesser der für die Aufgabenstellung drölftausendfach überdimensioniert ist? Der ist doch viel zu teuer!! Nehmen Sie gefälligst was passendes, wir müssen sparen!" Es gibt aber nix billigeres, hab selber eine Woche gebraucht um das zu begreifen und dann noch mal zwei Monate bis die Vorgesetzten es auch gerafft hatten.
Das wäre dann auch meine Empfehlung an dich, wenn du dir industrierelevante Skillz aneignen willst:
http://www.watterott.com/de/LPC824-LPCXpresso-Board
Das ist zwar alles noch ein paar Nummern abgefuckter als PIC oder Atmel, aber wenn du damit klarkommst bist du zukunftssicher. Da steckt nämlich eine einfache 32-bit ARM-Architektur drin und an der ARM-Architektur hat eine Schwuchtel (Sophie Wilson) ganz maßgeblich dran mitentwickelt und du weisst ja, was das für die turingvollständigkeit bedeutet. Die 8-Bitter halte ich für ganz extrem vom Aussterben bedroht. Zum Einstieg mit Assembler empfehle ich immer den PIC weil die Architektur der 18er sehr aufgeräumt ist und die Dokumentation ist einfach mal exzellent. Assembler auf einem ARM ist immer ein ziemlicher Arschaufriss, allein weil du oft mal mit drei verschiedenen Datenblättern arbeiten musst und es einfach belastender ist sich mit 32 bit breiten Steuerwörtern auseinanderzusetzen als mit 8-bit breiten Steuerwörtern.
Also in deinem speziellen Fall würde ich dir raten: zum Assembler lernen bleib einfach beim Atmel (oder wenn du dich unbedingt bei Nazibernd beliebt machen willst wechsel zum PIC18xxxxx) und wenn du irgendwann mit C loslegst, besorg dir das oben genannte LPC-Expresso Board. Die 32 bit Verarbeitungsbreite brauchst du, wenn du anfängst zu rechnen. Schon bei einfachen Filtern und Reglern kommt man ganz schnell in Bereiche, in denen man mit 64 bit Auflösung rechnen muss (oder will). Da geht natürlich auch auf einem 8-Bitter, der ist ja schließlich auch turingvollständig (alles berechenbare ist berechenbar). Eine 32 bit ARM-CPU ist aber nunmal turingvollständiger, d.h. schneller und bequemer und wärmer :3
Der Hauptnachteil bei NXP ist, dass offenbar kein Fick auf Abwärtskompatibilität und kompatibilität der Mikrocontroller untereinander gelegt wird. Das führt zu beschissenen Dokumentationen (weil der Inder der die schreibt immer wieder bei Null anfangen muss) und dein Code ist weniger wiederverwendbar. Dafür arbeitest du aber mit aktueller Hochtechnologie und musst dich nicht mit Schrott aus den 90ern rumärgern.
Mit irgendwas muss man sich aber rumärgern, sonst könnte den Job ja jeder machen.

Abschließend nochmal eine Liste der überlegenen Merkmale vom LPC824:
> 32 bit ARM0+ Architektur bis 30 MHz
> 32 kB Flash, 8 kB RAM
> IO-Pin Multiplexingmatrix (d.h. bei viele IO-Funktionen kannst du nach belieben auf Pins ummappen, zB USART)
> 12 bit ADC bis 1.2 Ms und über 100 k Eingangsimpedanz (bei PIC und AVR eher so 10 k üblich)
> DMA-Controller (kranker Scheiß ist krank, interruptgetriebener Code war gestern)
> SC-Timer (Timer-Statemachine-Dingsi, ebenfalls kranker Scheiß und interruptgetriebener Code war gestern)
> KFZ-stylischer Temperaturbereich
> Entwicklungsumgebung ist fast komplett kostenlos (bist 256 kB Flash, mehr braucht aber auch kein normaler Mensch)
> NXP ist einer von den Konzernen, die andere Konzerne übernehmen (kürzlich Freescale geschluckt und nun der größte Europäische Halbleiterhersteller, Europa stronk!!!)

mhwelander Avatar
mhwelander:#29307

>>29304
Klingt alles ziemlich geil.
Gibts für den Rotz auch eine Community wie uC.net?

rahmeen Avatar
rahmeen:#29308

>>29307
Nö, das ist was für richtige Arschbürger und nicht solche, die nur mal so tun wollen als ob weil es gerade hüfte ist. Teilweise bürgert man dann eben eine Weile rum, bis der DMA halbwegs läuft. Steht aber im Prinzip alles in den Datenblättern, Librarys von NXP gibt es auch und das NXP-Forum. Bisweilen stolpert man aber auch über irgendwelche Scheiße, die die Leute bei NXP selbst nicht wussten. Da kann man sich dann vertrauensvoll an den Support wenden und die erklären es einem dann. Musst halt etwas Englisch können. Die Beispielbibliotheken sind teilweise ziemlich hohes Niveau, aber mit ein bisschen Arschbacken zusammenkneifen geht das und zur Not gibt es ja auch noch KC /t/.

cheezonbread Avatar
cheezonbread:#29309

>>29308
>>29307
Das bringt mich zu der Frage, warum es auf /t/ eigentlich keinen klebrig gibt.

Seit ich begonnen habe mich für das Thema MC zu interessieren, finde ich in unregelmäßigen Abständen immer wieder sehr interessante Informationsquellen.

Heute zum Beispiel erst:
http://www.i2cdevlib.com/

In Anbetracht dessen, dass auf /t/ die Funk- und MC-Fäden immer wieder auftauchen, könnten die Mods ja mal darüber nachdenken, einen klebrig zu eröffnen, in dem die Bernds hier neben Antworten auf immer wieder kehrende Fragen auch eine Linksammlung erstellen können.

Auch:
>>29308
Was ist denn nun dieses DMA, von dem du so schwärmst?

christianoliff Avatar
christianoliff:#29310

>>29309
Sticky wäre blödsinn, Krautchan ist in erster Linie zum Liefern gedacht. Was aber sehr schön wäre, wäre eine Erhöhung des Postlimits auf über 9000 und Abschaltung der Zeitsäge. Dann gäbe es auf /t/ irgendwann drei oder vier epische Monsterfreds und den üblichen Quatsch...

DMA steht für Direct Memory Access; Der DMA-Controller ist ein Peripheriedingsi welches sich halb- oder vollautomatisch um Datentransfers kümmert. Man kann damit simple Speichertransfers steuern (zum Beispiel aus dem Flash in den RAM) aber auch komplizierte Abläufe wie "Nach Abschluss der Wandlung ADC-Kanal 1 Ergebnis in Puffer 1 schreiben und Wandlung ADC-Kanal 2 anschubsen, Nach Abschluss der Wandlung ADC-Kanal 2 Ergebnis zur USART1, senden anschubsen und Wandlung ADC Kanal 2 starten..." Das läuft dann automatisch im Hintergrund, ohne Prozessorregister oder Prozessorzeit zu beanspruchen -- zwischen den Takten sozusagen. Spart dir im Effekt das ADC-Interrupt.
Einfacher Anwendungsfall ist: du samplest im Hintergrund die Daten eines Analogsignals in Puffer 2 und wertest gleichzeitig die Daten der letzten Wandlung in Puffer 1 aus. Interruptgetrieben schaffst du es nicht, die Daten so schnell auszuwerten wie sie reinkommen: 30 MHz Systemtakt und 1.2 Megasample bedeutet, du hast alle 25 Takte eine Wandlung fertig. Interrupt anspringen, ausführen und verlassen dauert auch ca 25 Takte (fünf mal push, fünf mal pop, im Interrupt steht auch noch etwas code...). Die "Kosten" für Interrupts werden gerne unterschätzt, weil das pushen und poppen oft automatisch läuft (Hardware oder der Compiler ergänzt die nötigen Befehle). Interrupts führen auch regelmäßig auf äußerst abartige Fehler, weil man doch irgendwann den Überblick über die Prioritäten verliert und wer wann was darf und von wem gestört werden kann.

zl;ng: DMA ist der erste Schritt zum Dualcore. Erfordert auch wieder eine extraportion Hirnschmalz, aber wenn es läuft, dann läufts.

mattsapii Avatar
mattsapii:#29311

> Was aber sehr schön wäre, wäre eine Erhöhung des Postlimits auf über 9000 und Abschaltung der Zeitsäge.
Sekundiert

> DMA ist der erste Schritt zum Dualcore
Verstehe. Das klingt in der Tat spannend, wundert mich eigentlich, dass "Dual-Cores" noch gar nicht Einzug gehalten haben in die Welt der Mikrocontoller.

Themenwechsel:
Habe vom Ebuchtjuden jetzt einige ESP8266 erstanden und möchte die nun in Betrieb nehmen.

Das ganze NodeMCU-Zeugs, das oben schon erwähnt wurde, werde ich mir wann anders auf jeden Fall mal zu Gemüte führen, momentan würde ich gerne an meinem Plan festhalten, die Werte vom MC über UART an das ESP zu senden.
Nun stehe ich schon vor dem ersten Problem:
Um die UART Schnittstelle des Controllers zu testen, habe ich ein USB-auf-Seriell-Kabel besorgt, hat auch wunderbar funktioniert.
Jetzt möchte ich eben damit auch das ESP flashen.
Da der Threshold von 5V TTL tief genug liegt, um durch ein 3V high-Pegel angesprochen zu werden, kann ich Tx vom ESP ja einfach an das Kabel anschließen, Rx aber werde ich erstmal runterwandeln müssen.
Ist es denn all zu asozial, wenn ich einfach einen Spannungsteiler aufbaue?
Falls ja, schalten Spannungsregler schnell genug für die Kommunikation oder muss ich nun wirklich mit Transistoren anrücken?

sgaurav_baghel Avatar
sgaurav_baghel:#29315

>>29311
> wundert mich eigentlich, dass "Dual-Cores" noch gar nicht Einzug gehalten haben in die Welt der Mikrocontoller.

Wie kommst du denn darauf? Checkiere mal das hier:
http://www.ti.com/lsds/ti/processors/sitara/arm_cortex-a15/am57x/overview.page
Sowas (und fettere Teile) sind in jedem Schlaufon drin.

damenleeturks Avatar
damenleeturks:#29317

>>29315
Gibts für die fetten Teile auch so ausführliche Dokus wie bei standard Mikrocontrollern?

abotap Avatar
abotap:#29318

>>29317
Selbstverständlich. Aber so autistisch ist kein Bernd. Damit macht man dann Sachen in der Himbeerpreisklasse. Fang lieber erstmal klein an, damit du weisst was du tust. Ansonsten kannst du dir auch eine Himbeere kaufen und damit spielen.

alagoon Avatar
alagoon:#29320

>>29315
>>29318
Das sind aber doch Microprozessoren und keine -controller.

Sicher ist das eine haarige Sache, aber ich meine irgendwer arbeitet ja auch damit. Und diejenigen kochen auch bloß mit Wasser.
Aber dass das wohl sehr komplex ist, kann ich mir natürlich vorstellen.

bighanddesign Avatar
bighanddesign:#29322

>>29320
> Das sind aber doch Microprozessoren und keine -controller.
War mir sowas von klar, dass das kommt. Reine Prozessoren haben keine DMA, Programmspeicher, USART, USB, Grafik, CAN, Timer, PWM und was weiß ich noch alles an Bord du Klugscheißer.

Die Sache ist: Prozessoren sterben gerade aus und werden durch Mikrocontroller ersetzt. Das liegt daran, dass es möglich ist und billiger ein ganzes System auf einem Chip zu integrieren statt das System aus drölf Chips zusammenzuklöppeln. Dass die Amis es mit der Nomenklatur nicht so genau nehmen ist dabei egal. Fakt ist die Entwicklung:
> Rechner aus über 9000 Einzelteilen
> Rechner aus Logikschaltkreisen (zB Adder, Latches, etc)
> Rechner aus CPU + Peripherieschaltkreisen (Speicher, Grafik, etc)
> Rechner aus einem einzigen Chip (Mikrocontroller)

Naja, das nur am Rande. Wollte nur mal wieder stenkern :3

sindresorhus Avatar
sindresorhus:#29323

>>29320
Ach so, ja man kann die Dinger durchaus auch alleine sinnvoll verwenden. Das geht. Aber dann brauchst du eine spezielle Anwendung, zum Beispiel Bitcoinmining oder Passwörter bruteforcen. Sowas wie ein ganzes Handy macht keiner im Alleingang. Obwohl auch das ginge, wenn man unbedingt will. Aber warum sollte sich jemand das antun?

ryandownie Avatar
ryandownie:#29325

Kann ich sagen wir einfach mal einen alten Pentium 4 den ich rumliegen habe auf einem Brotbrett wie einen AVR o.ä. betreiben?

bassamology Avatar
bassamology:#29326

Äääähhhh...

Nicht wirklich bei 100 MHz FSB. Stellt sich die Frage, ob man Pentidumm mit 100 kHz takten darf..

VCC kriegste aus Netzteil, mußte dann räm und rom ranpfriemeln und so, immerhin sind die Signale noch "diskret" und nicht wie bei PCIX in irgendwelche Lanes und Pakete verpackt. Äh ja gemultiplext sind sie allerdings wohl könnte sein. Am arsch.

das ergibt so viele schmerzen daß es schmerzt und dann darfst du auch noch deinen eigenen ROM schreiben. warum nicht gleich ein SOC nehmen oder nen Z80

jimmywebdev Avatar
jimmywebdev:#29327

>>29322
>Prozessoren sterben gerade aus und werden durch Mikrocontroller ersetzt
Das sehe ich nicht so. Mit der Integrierbarkeit wächst auch der Bedarf an Speicher, komplexeren Peripherieschnittstellen und spezialisierten Koprozessoren. Kann sein, dass immer mehr klassische Peripherie in den Chip gezogen werden kann. Aber gleichzeitig kommt neue Peripherie hinzu. Beispielsweise ist in heutigen Prozessoren der Cache größer als der Arbeitsspeicher in alten Systemen. Das hat aber nicht dazu geführt, dass heute keine diskreten Speicherbänke mehr vorhanden sind. Klar gibt es SoCs, die Prozessorsysteme ersetzen können, aber die hinken dem Stand der Technik dann immer ein paar Jahre hinterher.
Der klassische Prozessor wird vielleicht irgendwann sterben, wenn gänzlich neue Technologien auf dem Markt sind. So wie gerade DSPs durch FPGAs verdrängt werden.

degandhi024 Avatar
degandhi024:#29587

Stößchen!

OP hat genug prokrastiniert ist zurück aus der Winterpause!
Nachdem ich alles überflogen habe, bin ich auch wieder relativ vertraut mit dem Projekt.
Habe nun mehrere ESP8266[01] akquiriert und stehe nun vor den Problem, dass ich gar nicht weiss wo ich anfangen soll.
Habe glücklicherweise mit dem ersten USB-to-Serial-Adapter Glück gehabt und habe einwandfreien Zugriff auf das Modul.

Stand im Moment: Habe eine funktionsfähige IIC-Lib, die auf dem MK2 Board on MyAVR läuft (eigener Aufbau folgt, sobald im Test alles funktioniert, dann wird auch der Controller entsprechend ausgewählt) und mir im Test ein Register aus meinem Gyro ausliest und via UART auch am PC anzeigt.
Das ESP kann ich wie oben erwähnt ansprechen.

Der nächste Schritt wäre nun, die Daten vom MK2 an das ESP anstatt an den PC zu senden und das ESP soll sie dann an einen vom PC eröffneten HotSpot senden.

Nur bin ich gerade etwas verloren was das ESP angeht, finde sozusagen keinen "Einstieg".
Kann mir Bernd sagen ob ich nun erst eine neue Firmware flashen muss, oder wie ich diese Kommunikation jetzt eigentlich initiieren kann?

Zu Hülf

ayalacw Avatar
ayalacw:#29590

Willst du jetzt richtig was lernen und coden oder einfach nur eine schneller Lösung die auch funktioniert?

Für zweiters: Einfach Arduino-Kern auf den ESP flashen und den Gyro mit einer fertigen Lib ansprechen.

https://github.com/esp8266/Arduino
http://playground.arduino.cc/Main/MPU-6050

stephcoue Avatar
stephcoue:#29591

>>29590
>Willst du jetzt richtig was lernen und coden oder einfach nur eine schneller Lösung die auch funktioniert?

Ersteres.
Virtueller Com Port (via WLAN) wäre das Stichwort gewesen, worauf ich gestern nicht gekommen bin.
Sehe ich das richtig, die Werte die bisher vom MC über UART an den pc gesendet wurden, kann ich nun einfach über AT-Befehle ins WLAN senden?

smaczny Avatar
smaczny:#29594

Sorry OP, muss nochmal deinen Faden vollschwuchteln:
Atmel wurde von Microchip (der anonyme Bieter aus >>29302) übernommen. Mit Blick auf die unzähligen Flammenkriege die zwischen Atmellüftern und PIC-Anhängern ausgetragen wurden, war mir diese Pressemitteilung ein kleiner innerer Reichsparteitag. Ich hoffe nur, dass Microchip jetzt nicht anfängt die PICs zugunsten der AVRs einzustampfen -- das wär ziemlich peinlich für mich.

Na ja, vielleicht gibt es auch bald eine gemeinsame IDE für AVR und PIC. Bin auf jeden Fall gespannt, was sich da entwickelt...

ffbel Avatar
ffbel:#29595

>>29594
>Sorry OP, muss nochmal deinen Faden vollschwuchteln

Siehe OP
>Auch: Allgemeiner Microcontrollerfaden :3

Solange die AVRs bestehen bleiben bin ich fein damit.

Neuste Fäden in diesem Brett: