Wie bzw. womit programmiert ihr eure AVR µC, speziell C++

Hat die MX20 denn keinen USB Port?

Nimm einen aktuellen gcc (9.3 oder 10.0), sowie make und QtCreator.
Weiterhin einen AVR der tiny1 oder mega0 Serie (etwa attiny1614 oder 
atmega4808). Zum Programmieren per UPDI dann einen simplen 
USB/seriell-Wandler und pyupdi. Alles vollkommen unspektakulär.

Ich denke mal er will die PPM Signale der 6 benötigten Kanäle als USB 
ausgeben, in welchem Format (oder Protokoll?) auch immer. Es geht nicht 
um USB zu seriell.

Philipp G. schrieb:
> Ich denke mal er will die PPM Signale der 6 benötigten Kanäle als USB
> ausgeben, in welchem Format (oder Protokoll?) auch immer. Es geht nicht
> um USB zu seriell.

Keine Ahnung, wie und was er will.

Was Du nicht verstanden hast: ich bezog mich nur auf das flashen der 
aktuellen AVRs, denn er wollte etwas zur Toolchain für sein Vorhaben 
wissen.

Und da es noch keiner erwähnt hat, das Einfachste dürfte sein Atmel 
Studio 7 zu benutzen.
Neben der AVR8 Toolchain bekommt man dann auch direkt die ganzen 
Includes.

Der damit direkt verfügbare GCC ist zwar "nur" der 5.4.0, der is aber 
auch erst von 06/2016 und geht bis C11/C++14.

Wilhelm M. schrieb:
> Keine Ahnung, wie und was er will.
>
> Was Du nicht verstanden hast: ich bezog mich nur auf das flashen der
> aktuellen AVRs, denn er wollte etwas zur Toolchain für sein Vorhaben
> wissen.

Schon klar. Letzten Endes bleibt er sowieso bei C(++) hängen.

Er will die 6 PPM Signale abgreifen. Wohl kaum über den HF Teil. Bleibt 
als nur der Empfänger. Von dort in einem ATMEGA 328 und daraus ein 
digitales Signal machen ist der kleinste Teil. Der schwierige Teil ist 
die Software, sofern diese nicht grad open source ist.

Rudolph R. schrieb:
> Der damit direkt verfügbare GCC ist zwar "nur" der 5.4.0, der is aber
> auch erst von 06/2016 und geht bis C11/C++14.

Würde ich nicht machen. Viele schöne Sachen fehlen:

https://en.cppreference.com/w/cpp/compiler_support

Ist doch nur Hobby, da sollte das Ganze doch Spaß machen, und deshalb 
würde ich auch C++20 Features nutzen.

Philipp G. schrieb:
> Schon klar. Letzten Endes bleibt er sowieso bei C(++) hängen.

Das (C++) will er doch, s.o.

Philipp G. schrieb:
> Er will die 6 PPM Signale abgreifen.

An seiner Stelle würde ich das SUMD-Signal nehmen.

Philipp G. schrieb:
> Der schwierige Teil ist
> die Software, sofern diese nicht grad open source ist.

Was Du nicht sagst ...

Atmel-ICE + Atmel Studio mit GCC. Da kann man sich dann aussuchen, ob 
man das Programm in C oder C++ schreibt

jens m. schrieb:
>
> Nach einer langen Nacht musste ich feststellen, dass die neueren Eclipse
> Versionen ab 2018 scheinbar Probleme mit dem AVR-Plugin haben. Erst mit
> Eclipse Mars lief ein C++ Testprogramm inkl. brennen problemlos.

Ich benutze das AVR-Plugin aktuell mit der Eclipse-Version "2019 12" und 
habe damit keine Probleme, außer:
- ich benutze eine eigene Eclipse (CDT) Installation für AVR, weil sich 
manche Plattformspezifische Plugins nicht wirklich vertragen
- neu angelegte Projekte bekommen nicht mehr "AVR-Nature" zugewiesen, 
das muß ich dann (einmalig und trotz Warnungen) von Hand machen. 
Eventuell ist das bei dir auch das Problem. Leicht erkennbar an dem 
fehlenden AVR-Knoten in den Properties des Projekts.

Der Vorteil neuerer CDT-Versionen: sie verstehen auch C++17, z.B. auch 
"user defined literals", was ich gerne für Zeiten/Frequenzen nutze.

1

static constexpr auto TIMER0_INTERVAL = 1_mSec;

2

static constexpr auto TIMER0_FREQUENCE = 125_kHz;

Da erkennt man gleich, worum es geht.

jens m. schrieb:
> ja korrekt! Der AVR Knoten fehlt, unter anderem ...
> Es wurden auch mal beim Erstellen des Projektes µC und Frequenz
> abgefragt, aber einfach nicht übernommen
Das liegt am fehlenden AVR-Nature. Das kann man bei den 
Projekt-Properties nachpflegen und muß dann unter den nun vorhandenen 
AVR-Knoten Chip/Frequenz nachpflegen.

> Alles unbefriedigend, da für mich nicht erkennbar ist, was noch alles
> nicht mehr korrekt zusammen arbeitet.

Als ich das das erste mal hatte, war ich auch leicht gefrustet, zumal 
alten Projekte weiter funktionierten. Inzwischen hab ich mich dran 
gewöhnt und wie gesagt, der Fehler ist einzig die Projekt-Neuanlage.

> Bei Fehlern schiebt man die Ursachen dann schnell auf die vermurkste
> Installation, obwohl ggf. woanders hingeschaut werden müsste. Sowas muss
> ich nicht haben.

Das Schöne ist, daß man mehrere Eclipse parallel installieren kann. 
Schnelles Internet vorausgesetzt kann man so schnell verifizieren.
In Summe arbeite ich aber zu 99,n% mit und nicht an Eclipse ;-)

Also wenn du das jetzt neu anfängst und dir die Plattform egal ist: nimm 
einen STM32 und zwar aus folgenden Gründen:

1.) Du sparst dir das gefummel mit dem V-USB, das macht nur immer wieder 
Probleme, STM32 boards machen das nativ.

2.) Du kannst direkt dass PPM als HID an den PC weiterreichen -> kein 
zusätzlicher Treiber oder anderer Müll. Beim VUSB musst du noch einen 
Treiber für den PC schreiben, der das dann umsetzt und letztendlich das 
dann in geigneter Form als Input device zur Verfügung stellt. Nicht 
unbedingt jedermanns Sache und das würde ich nicht machen, wenn es auch 
einfacher geht. Der STM mit entsprechendem USB HID meldet sich am System 
gleich als Joystick an.

Ein paar Beispiele, wie andere das gemacht haben bzw. wo man spicken 
kann:
https://www.artekit.eu/stm32-usb-gamepad-interface/
Da ist eine russische Seite, wo jemand genau das gemacht hat, was du vor 
hast: 
http://translate.google.com/translate?u=https://habr.com/ru/post/384813/

Carl D. schrieb:

> Das Schöne ist, daß man mehrere Eclipse parallel installieren kann.
> Schnelles Internet vorausgesetzt kann man so schnell verifizieren.
> In Summe arbeite ich aber zu 99,n% mit und nicht an Eclipse ;-)

ok, da ist was dran. Danke für deinen Hinweis! Es ist bestimmt nicht 
mein Ziel gewesen an Eclipse zu arbeiten.

Ich werde es nochmal mit deinen Ratschlägen und einer aktuellen 
Eclipse-CDT 2019-12 nur für AVR probieren. Zuvor war diese Version bei 
mir auch mit einem ESP32 Plugin (Arduino) belegt. Mal sehen, ob ich 
zurecht komme ...

Sven S. schrieb:
> Also wenn du das jetzt neu anfängst und dir die Plattform egal ist: nimm
> einen STM32 und zwar ...

Hallo Sven,
das macht auf jeden Fall neugierig und USB implementiert macht bestimmt 
wenig Probleme. Allerdings habe ich schon ein fertig aufgebautes VUSB 
für einen HID Joystick. Soll problemlos von Windows als solcher erkannt 
werden (wird sich zeigen)

Vor Gefrickel und sonstigen Problemchen habe ich keine Bedenken, des 
wegen mache ich es ja, um meinen Kopf fit zu halten :-)

Was ich vorhabe umzusetzen, bekommt man vermutlich an irgendeinem 
chinesischen Ladentisch schon fertig, aber ich möchte es gerne selbst 
umsetzen.