Maple mit Arduino 1.6.0 - jemand Erfahrung ?

Hallo,

ich habe mich mal in die 32Bit Welt gewagt und einen Maple-Clone ähnlich dem hier erstanden. Mit der Maple IDE bekomm ich Programme drauf, diese IDE ist allerding total buggy und stürzt dauernd ab. Hier gibt es ein Projekt, das in der Arduino IDE zu programmieren (dazu gibt es auch einen Foren Eintrag mit bereits 100!! Seiten). Beim Upload des blink.ino bekomme ich allerdings Fehler:

No valid DFU suffix signature (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. Warning: File has no DFU suffix (C) 2010-2011 Tormod Volden (DfuSe support) Error: Could not read name, sscanf returned0 This program is Free Software and has ABSOLUTELY NO WARRANTY Error: Failed to parse memory layout

dfu-util does currently only support DFU version 1.0

Filter on vendor = 0x1eaf product = 0x0003 Opening DFU USB device... ID 1eaf:0003 Run-time device DFU version 011a Found DFU: [1eaf:0003] devnum=0, cfg=1, intf=0, alt=1, name="DFU Program FLASH 0x08005000" Claiming USB DFU Interface... Setting Alternate Setting #1 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 011a Device returned transfer size 1024

Upload ins RAM (LeafLabs Maple Rev 3+ to RAM) kompiliert erst gar nicht. Das ganze läuft bei mir unter Ubuntu 14.04.1 LTS

Gruß Reinhard

Hallo,

bin jetzt einen Schritt weiter. Der Upload funktionierte nicht, weil die in Ubuntu enthaltene dfu-util version 0.5 (hier) nicht funktioniert. Nach manuellem Upgrade auf Version 0.8 funktioniert jetzt auch der Upload. (wie schön kann doch das Blinken einer LED sein !!)

Gruß Reinhard

Hallo, bin ziemlich in das Projekt involviert, falls du Probleme hast oder Hilfe benötigst, kann ich dir gerne auch auf Deutsch antworten :) LG Matthias (STM32-arduino -> nucleo F103RB conversation)

ps: ja, das Blinken bedeutet, dass ab nun alles möglich ist :)

madias: ps: ja, das Blinken bedeutet, dass ab nun alles möglich ist :)

Ich habe mal einen einfachen Performancevergleich zwischen STM32 Maple und Arduino UNO gemacht. Ich hätte nicht gedacht, dass sich 32Bit so extrem auswirken ....

Happy coding Reinhard

P.S.: vielleicht kann mal jemand diesen Test mit dem Due machen

Die höhere Register-Breite allein spart schon viel. Nicht nur der Takt. Auch auf dem 8-Bit AVR gibt es 32-Bit Datentypen, aber wenn du die mal den Assembler-Code dazu ansiehst ist das schon recht aufwendig. Alleine ein Vergleich mit 0 braucht 4 Befehle, da jedes Byte einzeln überprüft werden muss. Rechen-Operationen sind ähnlich aufwendig - Addition z.B. aus 4 Einzel-Additionen mit Übertrag.

Solche Test halte ich als wenig aussagekräftig. Wenn die Programmierung auf dem Maple murks ist, kann der auch von einem Uno geschlagen werden :D

Abgesehen davon ist der Preis auch nicht ohne, und den finde ich im Verhältnis zum Arduino schon teuer. Die µC von STM kosten ja fast nichts. Wenn ich bedenke wie günstige mein STM32 Disco Board ist inkl. Debugger/Programmer on Board.

Man kann nie sagen, ein ARM ist besser als ein AVR (8Bit) oder anders herum. Es entscheidet immer der Anwendungszweck ;) Ich sehe zum Teil wenig Sinn bei einem Attiny841 einen externen Quarz anzuschließen, da habe ich lieber die 1 oder 2 Pins mehr als IO Schnittstelle, zumal der Oscillator so genau bei den neuen Baureihen ist, das hier ein Problemloser Betrieb mit UART möglich ist.

Ansonsten find ichs gut, dass du dir die Mühe gemacht hast, selber zu prüfen, was mit der IDE möglich ist. Kann ggf. mal einen Test vom kleinen Due machen.

Schon bemerkenswert, dass selbst beim Vergleich der ersten 255 Zahlen mit Datentyp uint8_t
der Unterschied wesentlich größer ist als 16 zu 84 (MHz Taktrate).

Liegt wohl daran, dass byte*byte ein int ergibt, bzw. Multiplikation nicht zu den Stärken eines avr 8bit Controllers gehören.

Für übliche µC Aufgaben (Primzahlberechnung ist sicher absolut unsinnig) dürfte der wichtigere Engpass aber eher die RAM - Größe als die Geschwindigkeit sein.

Das spielt auf wieder die Registerbreite eine Rolle. Der AVR kann in zwei Zyklen zwei 8 Bit Zahlen multiplizieren, mit einem 16 Bit Ergebnis. Der ARM kann direkt 32 Bit Zahlen multiplizieren, optional auch mit 64 Bit Ergebnissen.