SAMD51 mit GCC

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hallo,
hat jemand von euch Erfahrung damit, für einen SAMD51 oder ähnliches 
ohne die IDE von Atmel / Microchip zu entwickeln? Ich würde gerne beim 
GCC bleiben und CMake für den Build verwenden.

Ich habe auf start.atmel.com mal ein neues Projekt angelegt, den 
samd51j19 ausgewählt und dann alle Peripherals angeklickt, die der Chip 
so hat. Nach gefühlt einer Stunde habe das Projekt jetzt exportiert.

Die vorgefundene HAL/HLP erschließt sich mir noch nicht ganz. Im Moment 
möchte ich ganz einfach eine asynchrone I2C Schnittstelle nutzen. Es 
gibt eine Dokumentation (rst-file) für eine synchrone Nutzung, die hat 
aber auch schon nur 80 Zeilen. Alles was ich so finde, ist ähnlich gut 
Dokumentiert, wie dieses Beispiel:

/**
 * \brief Initialize I2C in interrupt mode
 *
 * This function does low level I2C configuration.
 *
 * \param[in] i2c_dev The pointer to i2c interrupt device structure
 * \param[in] hw The pointer to hardware instance
 *
 * \return Return 0 for success and negative value for error
 */
int32_t _i2c_m_async_init(struct _i2c_m_async_device *const i2c_dev, void *const hw);

Bleibt letztendlich nichts anderes, als im Quellcode nachzugucken, ob 
ich das z.B. Teile von i2c_dev vor dem Aufruf initialisieren muss, oder 
nicht. Der Unterstrich im Funktionsnamen legt auch ein wenig nahe, dass 
die Funktion nicht dazu gedacht ist, direkt aufgerufen zu werden.

Was sind eure Erfahrungen damit? Kann man das benutzen? Gibt es 
alternativen?

Schöne Grüße,

Torsten

[Jemand (Gast)]

1. Der XC32 ist ein GCC, du kannst den also direkt in CMake benutzen
2. Ich bin (sogar jetzt gerade) dabei, mit einem SAME5x zu arbeiten und 
mich in das Harmony/MHC-Framework einzuarbeiten.

Ich musste mich da schon etwas einarbeiten, insbesondere, was wie mit 
und ohne RTOS funktioniert, hat mir ein paar Kopfschmerzen bereitet.

Ich möchte mein in meinem Projekt so wenig wie möglich blockierend auf 
die externe Chips zugreifen, daher war ich erst komplett asynchron 
zugange (man kann auch blockieren, bis ein asynchroner Aufruf durch ist, 
wollte ich aber nicht). Das wurde mir dann zu abenteuerlich und jetzt 
bin ich mit FreeRTOS zugange. Im Wesentlichen kann ich mich aber 
eigentlich nicht beklangen.

Nur, dass man die synchronen Driver nur mit und die asynchronen nur ohne 
RTOS benutzen kann, wird einem irgendwie nicht so super deutlich 
mitgeteilt.

Aber ich stecke da auch noch nicht so super tief drin.

[Jemand (Gast)]

PS: Ich experimentiere auch damit, das MPlab-Projekt in CLion zu öffnen, 
weil ich ein wenig auf JetBrains eingeschossen bin. Da MPlab Makefiles 
generiert, kann man die Projekte mit dem Editor seiner Wahl bearbeiten 
und kompilieren. Nur neue Dateien hinzufügen und so würde ich dann durch 
MPlab machen. Mehrere IDEs parallel bekommt ein heutiger Rechner aber 
wohl noch ganz gut hin. (ist aber zugegebenermaßen nicht die perfekteste 
Lösung).

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Jemand schrieb:
> 1. Der XC32 ist ein GCC, du kannst den also direkt in CMake benutzen

Na, wenn das ein GCC ist, dann kann ich ja auch einfach den GCC 
verwenden ;-)

> 2. Ich bin (sogar jetzt gerade) dabei, mit einem SAME5x zu arbeiten und
> mich in das Harmony/MHC-Framework einzuarbeiten.

Geht wahrscheinlich wieder nur mit einer bestimmten IDE. Ich habe das 
Gefühl, die Chip-Hersteller versuchen Probleme zu lösen, die eigentlich 
in der Software-Entwicklung schon seit 20 Jahren gelöst sind.

> Ich möchte mein in meinem Projekt so wenig wie möglich blockierend auf
> die externe Chips zugreifen, daher war ich erst komplett asynchron
> zugange (man kann auch blockieren, bis ein asynchroner Aufruf durch ist,
> wollte ich aber nicht).

Genau, ich habe mindestens 5 langsame I2C Busse. Wenn ich die synchron 
benutze, macht die CPU kaum etwas anderes, als zu warten.

> Nur, dass man die synchronen Driver nur mit und die asynchronen nur ohne
> RTOS benutzen kann, wird einem irgendwie nicht so super deutlich
> mitgeteilt.

Jedes moderne IO-Framework ist komplett asynchron, weil man in den 
letzten 30 Jahren die Erfahrung gemacht hat, dass das so am 
effizientesten ist. Wir haben Hardware, die Synchronität wunderbar 
unterstützt. Und dann setzen wir darauf ein Multitasking Paradigma aus 
den Zeiten der Mainframes, bei dem ich für jede blinkende LED 20kByte 
stack reservieren soll :-/

> Aber ich stecke da auch noch nicht so super tief drin.

Ich probiere es mal mit dem HPL. Ich habe die Hoffnung, dass man damit 
die evtl. nötigen Feinheiten im Umgang mit den Peripherals nicht 
übersehen kann.

[jemand (Gast)]

Zum Teil ist das wohl auch ein Problem der Programmiersprache. C ist 
dafür schon relativ unbequem. Eigentlich wären Async/Await für die 
Umgebung sonst ja auch ziemlich praktisch, aber was anderes als C auf 
dem Mikrocontroller ist halt ziemlich Nische.

Aber: ein FreeRTOS im Tickless-Modus und mit kooperativen Multitasking 
ist effektiv nichts anderes. Nur anders implementiert.

[jemand (Gast)]

Das mit den IDEs liegt wohl auch an den ganzen Chip-abhängigen Features, 
ja schon durchaus bequem sein können.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Arrrrrg, und dann nutzen Sie überall `void*`! Warum? Dafür wirre `const` 
qualifier an Zeigern (nein, nicht auf das gezeigte):

static inline int32_t _i2c_m_enable_implementation(void *const hw)
{
  int timeout         = 65535;
  int timeout_attempt = 4;

  ASSERT(hw);

  /* Enable interrupts */
  hri_sercomi2cm_set_CTRLA_ENABLE_bit(hw);

  while (hri_sercomi2cm_read_STATUS_BUSSTATE_bf(hw) != I2C_IDLE) {
    timeout--;

    if (timeout <= 0) {
      if (--timeout_attempt)
        timeout = 65535;
      else
        return I2C_ERR_BUSY;
      hri_sercomi2cm_clear_STATUS_reg(hw, SERCOM_I2CM_STATUS_BUSSTATE(I2C_IDLE));
    }
  }
  return ERR_NONE;
}

Ja, und die bauen sich da einen 32 bit integer zusammen :'(

[jemand (Gast)]

Ich habe bis gerade zugegebenermaßen überlesen, dass du das Atmel Start 
nutzt. Ich nutze MPLAB Harmony, was ja ursprünglich von Microchip und 
ihren Pics kommt, jetzt aber nach dem Zulauf auch die Sams unterstützt. 
Ich habe also etwas an dir vorbeigeredet.

Hier generiert der MHC mit aber auch Code, der eine Abstraktionsschicht 
über der HAL enthält. Muss man sich auch erst einmal hineinfinden. Und 
das FreeRTOS wird natürlich auch noch wegabstrahiert. It's abstractions 
all the way down.

Aber es funktioniert.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

jemand schrieb:
> Ich habe bis gerade zugegebenermaßen überlesen, dass du das Atmel Start
> nutzt. Ich nutze MPLAB Harmony, was ja ursprünglich von Microchip und
> ihren Pics kommt, jetzt aber nach dem Zulauf auch die Sams unterstützt.
> Ich habe also etwas an dir vorbeigeredet.

War mir bis gerade eben auch nicht bewusst, dass es zwei offizielle Wege 
gibt, Firmware für einen SAM zu entwickeln.

Ich würde aber mal annehmen, dass die HAL/HPL bei beiden IDE-Monstern 
die selbe ist.

[Rudolph (Gast)]

Torsten R. schrieb:
> Ich würde aber mal annehmen, dass die HAL/HPL bei beiden IDE-Monstern
> die selbe ist.

Das wäre hübsch, das Harmony ist allerdings was völlig anderes, bis 
runter zu komplett inkompatiblen Includes.

Aber START ist verbugt und tot, für ASF fehlt mir sowieso eine passende 
Beschreibung.

Das Harmony wird nicht nur gerade aktiv gepflegt,
wenn man da mal unten rein schaut kann man das wenigstens verstehen,
das ist nicht wie ASF darauf angelegt möglichst gut zu verbergen was im 
Controller eigentlich passiert.

https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_d5x_e5x
https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_d5x_e5x/tree/master/apps/sercom/i2c/master/i2c_eeprom/firmware/src/config/sam_e54_xpro/peripheral
https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_d5x_e5x/tree/master/apps/sercom/i2c/master/i2c_eeprom/firmware/src/config/sam_e54_xpro/peripheral/sercom/i2c_master

So sieht wohl aus was aus dem Code-Generator purzelt.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hier gibt es eine Quelle von ASF4, wenn man keine Lust hat, alle 
Peripherals in der Grotten langsamen Web-GUI anzuklicken: 
https://github.com/adafruit/asf4

Mir ist aber immer noch schleierhaft, ob und wie das ganze funktionieren 
soll. Mit `_i2c_m_async_register_callback` müsste ich callbacks setzen. 
Scheint aber so, als würde damit nur Write-Only-Memory mit den Callbacks 
beschrieben. Aufgerufen werden die gesetzten Callbacks nirgendwo.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Nach dem ich eine I2C Schnittstelle jetzt in Start konfiguriert habe, 
bekomme ich auch den Quellcode für die HAL für eine asynchrone Nutzung 
der I2C. Leider wimmelt es in der Implementierung nur so von polling:

  /* we polling busy flag wait for send finish here */
  while (i2c->device.service.msg.flags & I2C_M_BUSY) {
    ;
  }

Das ganze sieht irgendwie recht planlos aus.