Programmierung in Arduino vs. RepberryPi

[Ceos]

Lass es mich so formulieren, einen Atmel für Arduino einzusetzen entspricht ungefähr dem Vergleich mit einem Porsche Einkaufen zu fahren.

Kann man machen, ist aber Verschwendung, viel besser wäre es den Porsche auf einer Rennstrecke bis zum Heckschleudern aus zu reizen.

Und um hier einen Gegenkommentar vorweg zu nehmen:
ja, Arduino kann z.B. Hardware PWM in ziemlich dem gleichen Umfang nutzen wie Bare Metal, aber mit Bare Metal kann ich auch ungewöhnliche Konfigurationen machen, welche nützliche Seiteneffekte haben, die man mit Arduino nicht relasieren kann.

Ein kleines Beispiel aus der Praxis: Mit einem XMega, 2 DMA Kanälen und 1 PWM kann ich z.B. einen Pulsgenerator bauen der mir aufeinanderfolgend 100 Pulse mit individuell unterschiedlicher Periode und Dauer (im 1Mhz Bereich) erzeugen kann, ohne dass die CPU auch nur einmal irgendwas rechnen muss (außer vielleicht die nächste Folge berechnen und im Speicher ablegen) und somit Zeit für wichtigere Dinge hat. Mit Arduino direkt geht das nicht (hier wird man eher Taktbasiert mit vollem CPU Einsatz Bitbanging betreiben, siehe WS2812 Lib, ein Frame Update blockiert die CPU vollständig, mit DMA und geschicktem SPI Einsatz brauche ich nur eine größere Menge RAM im vergleich und die CPU langweilt sich)

[Holomino]

Falls ein Fehler vorliegt, wo finde ich ihn schneller?

Der Fehler ist doch schon gemacht.
Wo stelle ich beim Arduino die SampleRate ein? Und was bleibt ohne ISR von der Rechenzeit übrig, wenn ich auf allen 8 Kanälen fullspeed nacheinander messen will? Wie werde ich den Jitter los, der zweifellos bei dieser synchronen Pollgeschichte auftritt, wenn ich auch nur ein einziges "if" bei der Datenauswertung verwende?

Ich will das jetzt nicht gänzlich verreißen, aber die ADC-Geschichte nach Arduino Referenz (siehe AnalogRead) ist für mich ein typisches Beispiel. Bei der Verwendung aller 8 Kanäle bekommt man mit der ISR und 16MHz eine Taskscheibe von etwa 1000 Befehlzyklen zum Bearbeiten der Werte und Umsetzen des ADMux.
Mit Arduino bekommt man statt knapp 2kHz noch 1,25kHz SampleRate und damit ist auch gleich die komplette Rechenzeit weg.

Schon das Beispiel aus der Referenz

void loop() {
  val = analogRead(analogPin);  // read the input pin
  Serial.println(val);          // debug value
}

kann doch nicht jitterfrei laufen.

[HaWe]

Das hast du falsch verstanden: millis()

Natürlich hat eine allgemeine Bibliothek / Framework seine Grenzen. Aber das heißt nicht, dass es nicht geht [Beispiel], sondern vielmehr, dass man für spezielle Anwendungen wieder LowLevel gehen kann / muss, falls das nicht jemand anderes z.B. in Form einer Bibliothek entwickelt hat.


Das würde ich eher der Qualitätssicherung eines Unternehmens zuschreiben als einer sehr gut getesteten HighLevel-Bibliothek, mit der man viele Fehler gar nicht erst machen kann. Auch hier das [obige Beispiel]. Im ersten Fall sieht das Setup der Analogsignalmessung so aus:

  pinMode(A0, INPUT);

im zeitoptimierten so:

 ADCSRA = 0;             // clear ADCSRA register
  ADCSRB = 0;             // clear ADCSRB register
  ADMUX |= (0 & 0x07);    // set A0 analog input pin
  ADMUX |= (1 << REFS0);  // set reference voltage
  ADMUX |= (1 << ADLAR);  // left align ADC value to 8 bits from ADCH register

  // sampling rate is [ADC clock] / [prescaler] / [conversion clock cycles]
  // for Arduino Uno ADC clock is 16 MHz and a conversion takes 13 clock cycles
  //ADCSRA |= (1 << ADPS2) | (1 << ADPS0);    // 32 prescaler for 38.5 KHz
  ADCSRA |= (1 << ADPS2);                     // 16 prescaler for 76.9 KHz
  //ADCSRA |= (1 << ADPS1) | (1 << ADPS0);    // 8 prescaler for 153.8 KHz

  ADCSRA |= (1 << ADATE); // enable auto trigger
  ADCSRA |= (1 << ADIE);  // enable interrupts when measurement complete
  ADCSRA |= (1 << ADEN);  // enable ADC
  ADCSRA |= (1 << ADSC);  // start ADC measurements

Falls ein Fehler vorliegt, wo finde ich ihn schneller?

Danke für eure reichhaltigen Einblicke !-)

In der Tat brauche ich keinen Ersatz für delay(), sonder um Timer-Interrupt gesteuertes Zeitmanagement in [ms].
Wenn millis() Interruptbasiert arbeitet, kann ich damit auch eine saubere Statemaschine aufbauen.
Bei Respberry Pi könnte ich mir ein "Anzapfen" der internen Linux-Uhr vorstellen - ist aber ein anderes Thema.

An den beiden Bsp von @Sisor ist der Unterschied zum herkömmlichen C im AVR-uC gut zu erkennen.
Mit dem 2ten Code kann der ADC natürlich viel genauer und sauberer eingestellt werden.
Wichtig ist mM nach nur die Kenntnis um die Grenzen des Arduino-C und um die eigene Anforderung - "brauche ich (im akt.Projekt) diese Präzision überhaupt?" - ich nicht!

noch was anderes hierzu:
bei AVR-Studio gelten diese Registerdinger natürlich nur für AVRs.
Willst du einen ARM Cortex M0, M3, M4 oder ESPs damit programmieren, funktionieren sie natürlich nicht mehr, weil die Register dort ganz andere sind - da musst du dann einzeln wieder ganz neue Registerbefehle lernen, mit anderern Entwicklungsumgebungen.
Auch bei Arduino kannst du die AVR-Registerbefehle genau so verwenden, musst es aber nicht - stattdessen gehen AUCH die highLevel Befehle pinMode, digitalRead, digitalWrite, analogRead, AnalogWrite.
Weieterer Vorteil:
sie sind Interrupt-safe programmiert (dadurch sind sie zwar etwas länger und zeitintensiver, aber runtime-sicherer).
Weiterer Vorteil:
pinMode, digitalRead, digitalWrite, analogRead, AnalogWrite funktionieren auch genau so bei ARM Cortex M0, M3, M4 oder ESP, in der selben Arduino IDE.

Und das wäre für mich der wichtigste Grund, jetzt von AVR-Studio zu Arduino zu wechseln, und sofort mit leistungsfähigen ARM Cortex oder ESP Boards zu arbeiten.