Erreur de compilation de ma lib

UniseV:
Le problème c'est que sous forme d'ISR, je n'arrive pas à déclarer mes interruptions en tant que "friends" de ma classe. :frowning:

Tu ne peut pas mettre une ISR en friend de quoi que ce soit.

Si tu veut avoir une interruption et une classe travaillant ensemble il te faut faire une classe singleton et des variables globales (static) dans le .cpp pour passer des valeurs entre la classe et l'interruption.
Prend exemple sur "HardwareSerial.cpp" et "HardwareSerial.h" du core arduino :wink:

Finalement, ma version V003 actuelle fonctionne de cette manière, la seule chose que je ne crois pas avoir c'est la classe singleton... mais j'ai bien des données échangées entre la fonction de ma classe et mes interruptions (même si c'est pas propre).

Je crois que je vais renoncer au développement publique de cette librairie, je pense qu'il n'y pas vraiment d'utilisateurs.
Elle est actuellement optimisée et légère, et l'utilisateur principal que je suis est satisfait de son fonctionnement.

Je n'aime pas renoncer, mais là, j'ai l'impression que le jeu n'en vaut pas la chandelle. :disappointed_relieved:

UniseV:
Je n'aime pas renoncer, mais là, j'ai l'impression que le jeu n'en vaut pas la chandelle. :disappointed_relieved:

Attend d'avoir pris tes repères en C++ avant de te lancer dans une librairie publique :wink:

Sinon tu va te retrouver comme moi avec une librairie PCF857x utilisait par plein de monde mais absolument pas optimisé et avec des fonctions inutile ...
(un jour je prendrai le temps de la reprendre complétement cette bip de librairie)

Il y a peu de chance que ma librairie ait du succès, peu de modelistes utilise/connaisse le signal PPM-SUM et peu de récepteur le fournisse.

En revanche, j'ai 2 "bonnes" nouvelles :

1 )

  • Finalement je ne renonce pas, car avec l'aide d'un ami programmeur de métier le singleton est quasi-finalisé... je mettrais les erreurs de compil qui échapperai à mon ami (car pas Arduiniste) dans un nouveau sujet tout propre.
    2 )
  • Voici les premières lignes de la Release 1.0.4 de l'IDE Arduino :
ARDUINO 1.0.4 - 2013.03.11
[core]
* Fixed malloc bug (Paul Stoffregen)

re-boujour tableaux dynamiques ;)!!

UniseV:
re-boujour tableaux dynamiques ;)!!

Ou pas !
Faire de l'allocation dynamique quand on a que 2Ko de RAM reste et restera toujours une mauvaise idée.
La fragmentation mémoire induite par l'allocation / dé-allocation est la pire source de bug qui soit.

Quelle différence entre un malloc est un tableau à ce niveau ?

UniseV:
Quelle différence entre un malloc est un tableau à ce niveau ?

Je comprend pas la question ...

Tu dis qu'un malloc() c'est une mauvaise idée, et je l'ai souvent entendu, mais je ne comprends pas pourquoi ?
Ne fait-on pas de la même choses quand on créé un tableau ? C'est une allocation... dynamique ça veut dire quoi d'ailleurs ?

UniseV:
Tu dis qu'un malloc() c'est une mauvaise idée, et je l'ai souvent entendu, mais je ne comprends pas pourquoi ?

Parce que cela nécessite de découper la mémoire en petit morceaux afin d'allouer des tableaux de la taille désiré.
Et à force tu finit immanquablement par fragmenter ta mémoire et ne plus avoir de zones suffisamment grande.

UniseV:
Ne fait-on pas de la même choses quand on créé un tableau ? C'est une allocation...

C'est pas du tout la même chose ! (Et heureusement)
La différence c'est l'allocation sur le tas où sur la pile :

Merci,

Je ne connaissais pas cette subtilité.
Si je comprends bien, le problème du "tas" c'est surtout quand on libère la mémoire ? Si je ne compte pas la libérer, pas de fragmentation ?

UniseV:
Si je ne compte pas la libérer, pas de fragmentation ?

Théoriquement oui, âpres il faut que malloc() soit correctement codé ce qui semble maintenant être le cas.