plr a écrit 67 commentaires

Qu'entends-tu par "autonome"?

Merci pour ces infos.
Juste pour précision, je trouve que l'affirmation "La carte qui se rapproche le plus d'un Arduino est la NodeMCU" est erronée, sachant que tu compares un module WIFI comme il en existe déjà un certain nombre (plutôt des cartes d'évaluation d'ailleurs) chez Microchip ou autre fabricant. Sans doute pas avec la même communauté, je te le concède.
Des chips WIFI avec des caractéristiques équivalentes se retrouvent chez d'autres fabricants.
Pour ma part, je trouve que l'arduino/genuino, c'est déjà basé sur de la vieille techno d'atmel (ATmega) alors que les versions ATxmega sont largement plus intéressantes et moins chères.

Ensuite, pour des questions de certifications (CEM touça), je m'abstiendrais actuellement d'utiliser les chips ESP (ou tout autre chip "designed in China") surtout chez moi. le CE est de l'auto-certification et pour le FCC, j'ai l'impression qu'il l'ont fait aussi en auto-certification et uniquement sur une des dernières versions du chip. Connaissant les "magouilles" et autres "arrangements" pour faire passer ce genre de certifications (et même en Europe), je me permets d'avoir quelques doutes sur le rayonnement et autres perturbations de ce genre de chip: le nombre de "hobbistes" ne fait pas la "validité technique et environnementale", plutôt bouffer des ogm tous les jours, dans l'état actuel de l'art, celà me "semble" moins risqué. ^{^}
Sauf à avoir des certifications par un labo européens et indépendant bien entendu.

ps: c'est marrant un site de communauté "nodemcu.com" qui a une licence ICP (no.14038071) (surveillance du gouvernement Chinois)

Quand on connait le fonctionnement de ce genre de boite et leur façon de gérer les hommes/femmes ressources humaines, ce qui est étonnant, c'est surtout quand ça tombe en marche!
Mais ce qui est important, c'est que la "populace" croit que tout est bien géré parce que ça suit des méthodologies, des normes avec des supers équipes "qualitay" derrière. Bien entendu, ceux qui disent qu'il y a probablement un problème, ils divaguent: vague, vague, vague… ->[]

D'accord sur les gpio et le 3.3 au démarrage qui grille le processeur, c'est "lourd-dingue", j'en ai fait l'expérience.
Je trouve que pour de l'adc et autres io, autant utiliser un xmega/mega/tiny. Pour moi, la bbb n'est vraiment que le coeur, et que pour les autres fonctions bas-niveau (adc, comptage, encodeur, pilotage de moteur, etc.), il manque un "co-processeur" digne de ce nom. En plus, ils auraient pu mettre un msp430 par exemple s'il ne voulaient pas mettre de l'atmel…
La RPi, c'est pas pour moi, pas besoin d'écran en direct (que de l'afficheur basique) et sinon, via appli mobile ou appli dédiée sur pc. Et du dual ethernet de base.
C'est une autre cible mais hélas, la bbb n'est pas tout à fait à la hauteur, j'ai l'impression qu'ils ont voulu copier la RPi, dommage car de toute façon, ils ne pouvaient pas rivaliser.

D'accord sur les gpio et le 3.3 au démarrage qui grille le processeur, c'est "lourd-dingue", j'en ai fait l'expérience.
Je trouve que pour de l'adc et autres io, autant utiliser un xmega/mega/tiny. Pour moi, la bbb n'est vraiment que le coeur, et que pour les autres fonctions bas-niveau (adc, comptage, encodeur, pilotage de moteur, etc.), il manque un "co-processeur" digne de ce nom. En plus, ils auraient pu mettre un msp430 par exemple s'il ne voulaient pas mettre de l'atmel…
La RPi, c'est pas pour moi, pas besoin d'écran en direct (que de l'afficheur basique) et sinon, via appli mobile ou appli dédiée sur pc. Et du dual ethernet de base.
C'est une autre cible mais hélas, la bbb n'est pas tout à fait à la hauteur, j'ai l'impression qu'ils ont voulu copier la RPi, dommage car de toute façon, ils ne pouvaient pas rivaliser.

De toutes façons, à la question "A la fin, l’algorithme doit afficher le nombre de lignes et la matrice obtenue.", la réponse, c'est 42.
Ne me remerciez pas, je suis déjà parti…

De plus, c'est trop simple pour les vieux c*ns que nous sommes!
Et ce n'est même pas amusant comme exercice, encore (peut-être) un jeunot de prof qui ne s'est (sait) pas (se) creusé(er) la tête pour créer quelque chose de rigolo… À croire qu'il a envie de transmettre sa dépression à ses élèves!

Ah oui, les "float" du python sont des double" du C, au temps pour moi! C'est pour tromper l'ennemi ça!
M'enfin, voilà comment est "stocké" la valeur 275.15 dans un format "double précision":

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> Decimal(275.15)
Decimal('275.1499999999999772626324556767940521240234375')
>>>

cqfd

C'est génial, je n'avais jamais remarqué que c'est des float en simple précision qui est implémenté par python. En même temps, je n'utilise pas énormément ce langage, presqu'uniquement pour de l'interface utilisateur. Un peu de lecture que je te recommande:
https://docs.python.org/2/library/decimal.html
https://en.wikipedia.org/wiki/IEEE_floating_point
(sur mon environnement, sys.maxint=0x7FFFFFFF ce qui correspond bien à 32 bits pour coder signe, mantisse et exposant)
Moi qui suis un fan des virgules fixes, voilà le bon moment pour jouer au troll! ^{^}
J'ai entre-aperçu que certains préconisent NumPy pour obtenir des précisions plus élevées qu'avec les packages de base de Python qui n'implémentent que IEEE754, mais je n'ai pas creusé le sujet, n'en ayant pas l'utilité pour l'instant. Si d'autres peuvent expliquer brièvement leur façon d'utiliser des doubles et quadruples précisions avec python, je serais intéressé.
Le tout, c'est de le savoir.

ps: en fait, j'aime aussi beaucoup les float mais surtout utiliser les bons outils pour le bon usage.

Tu dis que tu es novice "Linux", mais tu ne précises pas si tu es novice en gestion de réseau et de système informatique et si ton besoin est personnel ou professionnel et si tu as déjà déployé un serveur de fichier… Pourrais-tu préciser, stp?
merci.

J'ai vérifié, oui, SREG est sauvegardé.
J'ai jeté un coup d'oeil là où je l'ai utilisé: c'est parce que SREG est modifié par du code entre l'entrée et la sortie de la région critique et qu'en sortant de cette région, je voulais récupérer l'ancien SREG (cas particulier)

[HS]
Après avoir eu des problèmes d'optimisation sur du code pour de l'AVR qui allait partir en production il y a bien longtemps, je ne mets dorénavent que des "volatile" pour le code AVR à moins que je ne sache exactement comme le code est optimisé: je préfère utliser d'autres astuces d'optimisation et perdre quelques instructions et coups de clock plutôt que de partir faire le tour du monde pour mettre à jour les produits déployés.
Par contre, ayant commencé ma carrière avec de l'assembleur dsp, j'ai gardé l'habitude de maîtriser entièrement toutes les variables, leur utilisation, leur optimisation, le mapping, les garder en "privé", les définir en variables locales ou en registre si je considère qu'elle peut être optimisée.

-> celà ne me choque donc pas, l'utilisation des "volatile" quand le code est bien architecturé, bien "modularisé" et bien écrit.
[/HS]
a2g

En effet, il faut sauvegarder le SREG avant de désactiver les IT pour ne pas perdre le SREG
C'est un exemple à la RACHE. (j'ai même introduit un bug: c'est align(512) pour l'alignement du buffer)
sur les softs que j'ai en production actuellement, je n'ai que des buffers de 256bytes pour les AVR, donc moins de données en format 16bits: ce code est extrait d'un prototype qui fonctionne très bien.

sur les uC qui gèrent plus que l'interruption UART, j'utilise plutôt des macros du genre:

#define AVR_ENTER_CRITICAL_REGION()    volatile u8 saved_sreg = SREG;IT_ALL_DISABLE;
#define AVR_LEAVE_CRITICAL_REGION()    SREG = saved_sreg;

Je conseille de ne surtout pas réactiver les interruptions dans les routines d'interruption en utilisant ces macros si on ne sait pas gérer les interruptions imbriqués ("nested") et attention à l'explosion de la pile avec la réentrance… etc.

a2g

Le problème n'est pas lié au "calcul" mais à l'architecture 8bits pour des calculs 16 bits et au delà.
Toute donnée significative de 16bits utilisée (que celà soit écriture ou lecture) dans une interruption doit être protégée ailleurs dans une section "protégée" par désactivation/activation de l'interruption. C'est une règle à laquelle tu n'échapperas pas.
voici un extrait d'un code (atxmega) de gestion d'un buffer circulaire de 512 octets aligné sur une adresse en 2^10, juste la partie réception (exemple pas bien optimisé mais osef) qui utilise des index. (l'utilisation des index est, dans certains cas, mieux optimisable par le compilateur que par pointeur. C'est l'expérience et l'étude du code généré qui le dit, mais ça tu devrais y arriver avec ta connaissance de l'asm)

#define DISABLE_ALL_IT        __asm__ __volatile__ ("cli" ::)
#define ENABLE_ALL_IT         __asm__ __volatile__ ("sei" ::)

#define RX_BUFFER_SIZE        512
#define RX_BUFFER_MASK        (RX_BUFFER_SIZE - 1)

volatile u16   rxReadIndex;
volatile u16   rxWriteIndex;
volatile u16   rxAvailableLength;
volatile u8    rxBuffer[RX_BUFFER_SIZE] __attribute__ ((aligned (10)));

ISR(USARTC0_RXC_vect)
{
   ... Verification of errors(etc.) before storing data!
   // Store received data
   while((USARTC0.STATUS & USART_RXCIF_bm) != 0)
   {
      rxBuffer[rxWriteIndex++] = USARTC0.DATA;
      rxWriteIndex &= RX_BUFFER_MASK;
      rxAvailableLength++;
   }
}

u8 getReceivedData (u8* pDst)
{
   u16 i;
   u16 availableLength;

   DISABLE_ALL_IT;
   rxAvailableLength = availableLength;
   ENABLE_ALL_IT;

   for (i=0; i<availableLength; i++)
   {
      *pDst++ = rxBuffer[rxReadIndex++];
      rxReadIndex &= RX_BUFFER_MASK;
   }
   DISABLE_ALL_IT;
   rxAvailableLength = 0;
   ENABLE_ALL_IT;

   return (u8)i;
}

etc...

C'est clair que de passer de l'assembleur au C n'est pas simple car il y a pleins de subtilités. Ensuite ça va tout seul lorsqu'on connait le fonctionnement du compilateur en C. Ca met du temps…
a2g

Tu te méprends, cf. mon post plus bas.
Je fais référénce au code ci-dessus et les déclarations de ton premier post.
C'est au moment où tu vas calculer ton "sz" que ça va partir en live: si tu es en train de le calculer, et que l'écriture en mémoire n'est pas finie (par exemple), que ton IT claque, tu vas calculer un "freesz" qui peut être complètement faux!
si tu considère que l'opération "sz = tail + (bufsz - head);" se fait en un coup d'horloge, uniquement par des registres, qu'il n'y a qu'un accès mémoire à sz, alors pourquoi pas!
Mais celà n'a pas l'air d'être le cas pour la "plus" simple raison que toutes ces variables sont des 16bits sur un AVR alors que ta cpu est en 8bits.
Donc avec le code proposé, tu auras des bugs aléatoirement et un résultat inattendu voir plantage du micro, mais si tu penses que ce n'est pas grave…
Je ne peux que t'encourager vivement à lire le fichier .lss généré pour comprendre comment une instruction 'C' est compilée et optimisée

a2g

ps: par curiosité, quel est le micro que tu utilises et ça fait combien de temps que tu codes sur de l'AVR ou un micro 8bits?

Il y a-t-il un risque que l'interruption utilise une mauvaise valeur pour head ? C'est-à-dire entre le momen où tu calcules freesz et le moment où tu modifie tail.
-> Non je ne crois pas, au pire tu as un overrun du à un freesz sous-estimé.

Et bien si!

Il y a-t-il un risque que main utilise une mauvaise valeur de tail ? Idem, non je ne crois pas.

Et bien si!

a2g

L'utilisation du mot clé "volatile" est indispensable à maîtriser lorsqu'on écrit du code embarqué: elle permet à l'utilisateur d'éviter que le compilateur, lorsqu'utilisé avec les optimisations qui vont bien n'en fasse trop. L'exemple le plus courant est le polling sur une pin d'entrée:
si pin_b0 est le nom de la "variable" qui permet d'accéder à la pin 0 du port B du uC, alors, sans le mot clé "volatile", le code suivant qui permet de détecter le passage à 1 de cette entrée a pour conséquence de faire "disparaitre" la boucle while et de se faire rick-roller et c'est surtout pas ça ce qu'on veut:

// Code "RACHE certified" before while loop
isRisingEdgeDetected = false
while(!pin_b0)
{
   isRisingEdgeDetected = true
}
// Code "RACHE certified" after while loop
if(!isRisingEdgeDetected)
{
   // Listen to Rick Roll/Never Gonna Give You Up!
}

Jeter un coup d'oeil à sfr_defs.h, io.h (etc.) pour la définition des accès mémoires des pins du uC de type AVR. Pour définir une variable volatile de type "la structure que tu veux définir":

typedef struct S_MASTRUCTURE t_mastructure;
#ifndef _S_MASTRUCTURE
struct S_MASTRUCTURE
{
  u8*  pBuffer;
  u16  aWord;
  u8   aByte;
};
#endif
volatile t_mastructure maVariableDeTypeMastructure;

Pour l'embarqué tel que pour un AVR, lorsqu'on veut modifier une variable par le code principal et par une interruption, il faut désactiver les interruptions dans le code principal lorsqu'on y accède.
exemple, pour modifier aWord par le code principal ET par l'interruption pour un uC de type AVR:

ISR(USARTC0_RXC_vect)
{
   // Modify a "shared value"
   maVariableDeTypeMastructure.aWord++;
}

int main (void)
{
   // Code "RACHE certified"
   ...

   for(;;)
   {
      // Deactivate interruptions
      __asm__ __volatile__ ("cli" ::)
      // Modify a shared variable
      maVariableDeTypeMastructure.aWord+=2;
      // Reactivate interruptions
      __asm__ __volatile__ ("sei" ::)
      // Fantastic code
      ...
   }
   return 0;
}

Sans désactiver les interruptions, sur un micro 8bit, on risque l'interruption en plein cours de modification de aWord dans le programme principal et là, c'est le drame!
Et même si la variable est de type 8bit, parce qu'entre le moment où la variable va être chargée dans un registre et le moment où le registre va être modifié et le moment où il va être réécrit dans la mémoire, il y a des malchances qu'une interruption claque et qu'à la fin, la variable se retrouve avec une valeur totalement indéterminée. Je te laisse imaginer le cas où cette variable est de type pointeur, à côté des dégats que celà peut engendrer, tu préfèrerais être rickrollé!

Mutex, semaphore et autres mécanismes du même type sont des implémentations pour langage "haut-niveau" (os, multithread, etc.) pour éviter ces problèmes, mais la base est ci-dessus!

a2g