wDSPiy - commander le DSPiy par Wifi (et par Alexa et en MQTT)
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
J'ai pas tout compris, surtout les mono et multithread mais en effet les interrupt c'est souvent source de problèmes étranges.
Là tu découvres les joies de l'électronique programmable, un problème peut venir du hardware ou du software.
Et lorsque l'on commande des systèmes motorisés l'on rajoute encore une source de problème.
Là tu découvres les joies de l'électronique programmable, un problème peut venir du hardware ou du software.
Et lorsque l'on commande des systèmes motorisés l'on rajoute encore une source de problème.
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
oui le chemin du padawan est long et semé d'embuches, dont certaines que je sème moi même
Avec Arduino (je sais pas si c'est pareil ailleurs) on peut demander au compilateur de mettre les instructions d'une fonction en cache pour accélérer l'accès. On peut mettre le "icache" en RAM ou en Flash. C'est normalement réservé aux fonctions dont on a besoin vite, comme pour les interruptions.
Sur des arduino de base, il y a très peu de RAM et le icache va naturellement en Flash.
Par ailleurs, j'ai compris que la flash ne peut pas etre sollicitée en accès concurrent, même en lecture.
Un ESP8266 est muti-taches. Typiquement du code système se déroule en arrière plan et peut accéder à la Flash.
Si une interruption "icachée" en flash arrive en même temps, le µC ne sait pas ordonner les accès et ça clash.
Le même genre de risque existe si une fonction d'interruption est "icachée" en flash et que les traitements de ladite fonction accèdent à la flash : collision assurée suivie d'un crash.
Sur ESP8266, s'il y a peu d'interruptions, le risque de collision reste faible ça peut marcher quand même. Ca marchait très bien chez moi d'ailleurs parce qu'une télécommande c'est plutot lent! Mais avec les versions récentes d’Arduino sur esp8266, ils ont décidé d'interdire ce genre de prise de risque. Ca se comprend : il y a beaucoup plus de RAM donc il n'y a pas vraiment d'intérêt a mettre le icache en flash.
Sur l'ESP32, multi tache et dual core, il existe une IRAM optimisée utilisée par le système qui est aussi accessible a l'utilisateur pour le ICACHE.
Sinon, aujourd'hui je me suis pris le choux sur la migration SPIFFS vers LittleFS
ça devait etre simple, sauf que non. Et encore une fois c'était de ma faute. Mon code en partie ré-écrit en ressort meilleur ![Dan.San :)](./images/smilies/1.gif)
LittleFS est supporté par ARM et m'a l'air disponible un peu partout.
![Dan.San :merci:](./images/smilies/73.gif)
Avec Arduino (je sais pas si c'est pareil ailleurs) on peut demander au compilateur de mettre les instructions d'une fonction en cache pour accélérer l'accès. On peut mettre le "icache" en RAM ou en Flash. C'est normalement réservé aux fonctions dont on a besoin vite, comme pour les interruptions.
Sur des arduino de base, il y a très peu de RAM et le icache va naturellement en Flash.
Par ailleurs, j'ai compris que la flash ne peut pas etre sollicitée en accès concurrent, même en lecture.
Un ESP8266 est muti-taches. Typiquement du code système se déroule en arrière plan et peut accéder à la Flash.
Si une interruption "icachée" en flash arrive en même temps, le µC ne sait pas ordonner les accès et ça clash.
Le même genre de risque existe si une fonction d'interruption est "icachée" en flash et que les traitements de ladite fonction accèdent à la flash : collision assurée suivie d'un crash.
Sur ESP8266, s'il y a peu d'interruptions, le risque de collision reste faible ça peut marcher quand même. Ca marchait très bien chez moi d'ailleurs parce qu'une télécommande c'est plutot lent! Mais avec les versions récentes d’Arduino sur esp8266, ils ont décidé d'interdire ce genre de prise de risque. Ca se comprend : il y a beaucoup plus de RAM donc il n'y a pas vraiment d'intérêt a mettre le icache en flash.
Sur l'ESP32, multi tache et dual core, il existe une IRAM optimisée utilisée par le système qui est aussi accessible a l'utilisateur pour le ICACHE.
Sinon, aujourd'hui je me suis pris le choux sur la migration SPIFFS vers LittleFS
![Dan.San :gene:](./images/smilies/12.gif)
![Dan.San :)](./images/smilies/1.gif)
LittleFS est supporté par ARM et m'a l'air disponible un peu partout.
acheter un DSPiy ? c'est ici
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
Sur les "petits" µC tel que celui du DSPiy il n'y a pas de cache.
Juste de la RAM principalement pour les variables et de la flash principalement pour le code et constantes.
Il y a aussi parfois une ROM qui contient quelques fonctions de base pour les I/O et programmation de la Flash interne.
Ensuite l'on peut rajouter de la Flash série, mais ce ne sera que pour des données. Les Preset du DSPiy par exemple.
Il est toujours possible d'exécuter une partie du programme en RAM, mais c'est pour une utilisation très spéciale et il faut tout faire à la main.
Les DSP ADAU utilisés, eux n'ont que de la RAM et sans doute une ROM.
Ils nécessitent une Flash externe dont le contenu sera chargé en RAM au Reset; ou comme dans le cas du DSPiy, un µC qui va se substituer à cette Flash externe.
Arduino, que je ne connais pas trop, se décline en plusieurs µC du petit au gros.
Ce qui n'est pas clair dans ton explication c'est le mot Flash.
De ce que comprend il y en au minimum 2 : une flash interne "programme" classique et une Flash cache plus rapide.
N’aurai t’il pas été plus simple de ne pas utiliser le cache pour ton interrupt ?
Juste de la RAM principalement pour les variables et de la flash principalement pour le code et constantes.
Il y a aussi parfois une ROM qui contient quelques fonctions de base pour les I/O et programmation de la Flash interne.
Ensuite l'on peut rajouter de la Flash série, mais ce ne sera que pour des données. Les Preset du DSPiy par exemple.
Il est toujours possible d'exécuter une partie du programme en RAM, mais c'est pour une utilisation très spéciale et il faut tout faire à la main.
Les DSP ADAU utilisés, eux n'ont que de la RAM et sans doute une ROM.
Ils nécessitent une Flash externe dont le contenu sera chargé en RAM au Reset; ou comme dans le cas du DSPiy, un µC qui va se substituer à cette Flash externe.
Arduino, que je ne connais pas trop, se décline en plusieurs µC du petit au gros.
Ce qui n'est pas clair dans ton explication c'est le mot Flash.
De ce que comprend il y en au minimum 2 : une flash interne "programme" classique et une Flash cache plus rapide.
N’aurai t’il pas été plus simple de ne pas utiliser le cache pour ton interrupt ?
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
thierryvalk a écrit :Ce qui n'est pas clair dans ton explication c'est le mot Flash.
De ce que comprend il y en au minimum 2 : une flash interne "programme" classique et une Flash cache plus rapide.
N’aurait’il pas été plus simple de ne pas utiliser le cache pour ton interrupt ?
là tu atteins mes limites. L'ESP8266 inclut sur son soc le µC, de la SRAM et 64K de ROM pour le boot.
- 32 KB instruction RAM
- 32 KB instruction cache RAM
- 80 KB user-data RAM
- 16 KB ETS system-data RAM
La Flash est externe : un chip de 4MB de QSPI Flash dans mon cas. Il n'y a pas d'EEPROM : elle est émulée dans une zone réservée en Flash pour les programmes arduino qui l'utilise.
Dans mon cas, oui ça aurait été sans rien mettre en icache. Surtout que mes interruptions c'est pour de l'IR qui est loin d'être du "temps réel" comparé à la vitesse du µC. Mais d'un autre coté j'ai la place en RAM (32K réservés) donc autant y mettre en priorité les fonctions que je choisis.
Au fait, les ESP8266 ont un port I2S. D'autre part, un gars a publié le code pour les biquads et les filtres habituels. On doit pouvoir en faire un µDSPiy. Ce serait inutile mais rigolo
![Dan.San :)](./images/smilies/1.gif)
acheter un DSPiy ? c'est ici
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
Si l'ESP8266 n'a pas qu'une flash série, je présume que c'est le même principe que pour nos DSP.
En fait ta flash est une sorte de disque dur et donc je doute fort que du code y soit directement exécuté.
Attention qu'une EEPROM est très différente d'une flash.
L'EEPROM permet l'écriture de n'importe quelle adresse alors que la flash nécessite un effacement d'un secteur avant écriture.
Le nombre de séquence effacement/écriture est aussi plus réduit, j'espère que cette émulation est bien gérée pour limiter ce nombre de séquences.
En fait ta flash est une sorte de disque dur et donc je doute fort que du code y soit directement exécuté.
Attention qu'une EEPROM est très différente d'une flash.
L'EEPROM permet l'écriture de n'importe quelle adresse alors que la flash nécessite un effacement d'un secteur avant écriture.
Le nombre de séquence effacement/écriture est aussi plus réduit, j'espère que cette émulation est bien gérée pour limiter ce nombre de séquences.
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
Un Cache d'instructions c'est une sorte de tiroir ou le compilateur range du code "pré-maché" toujours disponible.thierryvalk a écrit :Si l'ESP8266 n'a pas qu'une flash série, je présume que c'est le même principe que pour nos DSP.
En fait ta flash est une sorte de disque dur et donc je doute fort que du code y soit directement exécuté.
Ca va normalement en RAM dédiée et rapide. Les gros processeurs modernes ARM ou intel stockent ça a l'intérieur du proc et avec plusieurs niveaux. Il n'y a que sur les "petits" arduino qui n'ont que 2K ou 8K de RAM qu'ils ont prévu de pouvoir faire du icache en flash. Mettre le icache en flash aurait du être interdit par arduino sur les ESP8266 dès le début. J'ai fait mon code un peu trop tot en 2016
![Dan.San ;)](./images/smilies/6.gif)
je pense que c'est le cas parce qu'ils connaissent bien le souci. Normalement, on utilise très peu l'eeprom sur un esp8266. Dans mon cas quelques dizaines d'octets, et encore je pourrais m'en passer.Attention qu'une EEPROM est très différente d'une flash.
L'EEPROM permet l'écriture de n'importe quelle adresse alors que la flash nécessite un effacement d'un secteur avant écriture.
Le nombre de séquence effacement/écriture est aussi plus réduit, j'espère que cette émulation est bien gérée pour limiter ce nombre de séquences.
Structure de la Flash d'un ESP8266 avec Arduino
![Image](https://i.imgur.com/5m9M2ZL.png)
sketch c'est le programme en arduinolangue. OTA c'est la zone réservée quand on fait une mise a jour du sketch par le wifi.
acheter un DSPiy ? c'est ici
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
Je ne suis pas d'accord avec ta définition du cache.
Le code n'est pas pré-maché, c'est des instructions comme les autres issues du compilateur qui reste dans ton PC (ou sur un cloud).
Pas trouvé de datasheet pour ce Soc, mais tout de même le Memory Map bien que non officiel.
https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map
On y voit bien les 2 caches RAM tout simplement dans l'espace adressable du processeur.
Cela dit, c'est de la cuisine interne au compilateur mais c'est tout de même intéressant d'en connaitre +- le fonctionnement.
Le code n'est pas pré-maché, c'est des instructions comme les autres issues du compilateur qui reste dans ton PC (ou sur un cloud).
Pas trouvé de datasheet pour ce Soc, mais tout de même le Memory Map bien que non officiel.
https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map
On y voit bien les 2 caches RAM tout simplement dans l'espace adressable du processeur.
Cela dit, c'est de la cuisine interne au compilateur mais c'est tout de même intéressant d'en connaitre +- le fonctionnement.
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
C'est de la cuisine interne, et comme en cuisine, on aime bien avoir a portée de main les instruments qu'on utilise souvent.
L'expression "ou est caché mon couteau" prend un nouveau sens
Sur un esp ou il y a de la ram dédiée je vois bien comment ca marche et pourquoi c'est utile. Moins sur un "petit" systeme ou quasiment tout est en flash, comme les arduino classiques. Comme je resterai sur des ESP8266 ou ESP32, je ne creuse pas trop la question des arduino basiques.
L'expression "ou est caché mon couteau" prend un nouveau sens
![Dan.San :mrgreen:](./images/smilies/14.gif)
Sur un esp ou il y a de la ram dédiée je vois bien comment ca marche et pourquoi c'est utile. Moins sur un "petit" systeme ou quasiment tout est en flash, comme les arduino classiques. Comme je resterai sur des ESP8266 ou ESP32, je ne creuse pas trop la question des arduino basiques.
acheter un DSPiy ? c'est ici
Re: wDSPiy - commander le DSPiy par Wifi
Hello,
Sur un arduino je suppose qu'il s'agit simplement de registre au niveau du core qui sont dédiés à certaines instructions qui reviennent souvent dans le code, non ? Et puis ça doit pas mal dépendre de quel uC chez arduino aussi !
Je n'ai jamais eu de cours approfondis sur les archi uC et les architectures numériques en général, il faudrait que je trouve un bouquin sur ça !
alka a écrit :Sur un esp ou il y a de la ram dédiée je vois bien comment ca marche et pourquoi c'est utile. Moins sur un "petit" systeme ou quasiment tout est en flash, comme les arduino classiques. Comme je resterai sur des ESP8266 ou ESP32, je ne creuse pas trop la question des arduino basiques.
Sur un arduino je suppose qu'il s'agit simplement de registre au niveau du core qui sont dédiés à certaines instructions qui reviennent souvent dans le code, non ? Et puis ça doit pas mal dépendre de quel uC chez arduino aussi !
Je n'ai jamais eu de cours approfondis sur les archi uC et les architectures numériques en général, il faudrait que je trouve un bouquin sur ça !
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
Arduino est un mot surchargé. Il recouvre
- le gros morceau dont j'ignore le nom officiel s'il en a un et que je l'appelle "arduino core". C'est l'environnement d’exécution du programme (sketch) de l'utilisateur. C'est pas vraiment un Système d'exploitation, plutot un gros framework qui fait firmware.
- Arduino c'est aussi le nom de l'IDE avec le compilateur qui sert a développer le code utilisateur.
- C'est aussi le nom de la société qui s'est créée autour du projet et qui a fait les cartes UNO, MEGA, Nano etc.
A ses débuts, le "core" arduino était dédié aux AVR d'ATMEL. Il a depuis été porté sur architecture ARM (cartes DUE) et sur architecture Xtensa pour les ESP8266 et ESP32 (*). Une équipe compétente et motivée pourrait porter arduino sur d'autres plateformes.
Ce que je sais sur ces histoires de cache, de façon synthétique, et manquant de précision si on entre dans les détails.
1) Au début était le trio processeur + Ram + Support magnétique. On peut ajouter Rom et eeprom mais ça ne change pas le principe.
Dans cette situation, le proc doit charger en Ram les instructions du code pour les exécuter. La Ram contient aussi les données du programme. Evidemment avec peu de Ram, on coince vite, alors on a inventé des parades. La première est que l'OS gère le chargement et libération des instructions en Ram selon les besoins. On a aussi inventé la mémoire virtuelle pour étendre la RAM sur les disques magnétiques. Comme tout ça est lent, on a aussi inventé le cache mémoire pour forcer le proc a conserver certaines data ou certaines instructions en Ram pour avoir un accès rapide a ces informations en toutes circonstances.
2) Sont arrivées les Flash rapides qui permettent l'exécution du code "in place". Je dis rapide c'est par rapport à un µC qui tourne a quelques MHz. Plus besoin de charger le code en Ram pour l'exécuter. On peut faire des choses performantes même avec peu de RAM. C'est le cas des arduino AVR Atmel. Le cache instruction (icache) en Ram reste disponible pour y metrre le code a exécuter au plus vite. On doit être ultra sélectif car la place en RAM est limitée : Pour les premier arduino seulement 2K de Ram a partager entre data et icache!
3)Avec de la Flash quad spi qui fonce et beaucoup plus de Ram, un ESP8266 change la donne. Pour optimiser les accès, la Ram est segmentée : instructions, icache et data. Des parties de code exécutées fréquemment sont conservées en Ram. On dit que c'est pas la peine de mettre en cache des fonctions souvent appelées car elles sont naturellement présentes en Ram. Le paramètre ICACHE est pour forcer que ce code reste a coup sur.
Pour le reste, je ne suis pas certain de comment est géré la partie instructions en Ram: tout est mis en Ram au départ ou chargé depuis la Flash à la demande ? Quelle parties de code sont executées "in place" ? c'est la cuisine interne sans doute décrite quelque part.... ou pas. Espressif reste vague sur certains aspects.
Un autre intéret du cache c'est l'optimisation des accès. Quand la Ram mélange instructions et data, le proc doit faire le tri. En segmentant la RAM, il peut optimiser la lecture d'instructions et la lecture/écriture des data.
La plupart de ces mécanismes existent toujours dans les systèmes récents avec des niveaux d'optimisation pointus, dont les caches a plusieurs niveaux intégrés au processeur et des mémoires RAM de type différent type, spécialisée selon usage.
Là ou je coince c'est dans la situation 2) : quel intéret de mettre le cache instruction en flash (le fameux ICACHE FLASH ATTR d'arduino ) alors que le code est déjà exécute "in place" en flash, sauf bien sur celui qui est en icache ram. Surtout que sur les arduino la flash est unique: il n'y a pas une flash plus rapide pour l' "icache en flash". Il doit y avoir une subtilité qui m'échappe mais c'est pas bien grave.
(*) pour compléter, il existe sur ESP des alternatives à Arduino. Le fabricant a son propre framework-firmware avec son langage nommé LUA.
Il y a aussi micro-python qui permet d’exécuter des scripts python.
- le gros morceau dont j'ignore le nom officiel s'il en a un et que je l'appelle "arduino core". C'est l'environnement d’exécution du programme (sketch) de l'utilisateur. C'est pas vraiment un Système d'exploitation, plutot un gros framework qui fait firmware.
- Arduino c'est aussi le nom de l'IDE avec le compilateur qui sert a développer le code utilisateur.
- C'est aussi le nom de la société qui s'est créée autour du projet et qui a fait les cartes UNO, MEGA, Nano etc.
A ses débuts, le "core" arduino était dédié aux AVR d'ATMEL. Il a depuis été porté sur architecture ARM (cartes DUE) et sur architecture Xtensa pour les ESP8266 et ESP32 (*). Une équipe compétente et motivée pourrait porter arduino sur d'autres plateformes.
Ce que je sais sur ces histoires de cache, de façon synthétique, et manquant de précision si on entre dans les détails.
1) Au début était le trio processeur + Ram + Support magnétique. On peut ajouter Rom et eeprom mais ça ne change pas le principe.
Dans cette situation, le proc doit charger en Ram les instructions du code pour les exécuter. La Ram contient aussi les données du programme. Evidemment avec peu de Ram, on coince vite, alors on a inventé des parades. La première est que l'OS gère le chargement et libération des instructions en Ram selon les besoins. On a aussi inventé la mémoire virtuelle pour étendre la RAM sur les disques magnétiques. Comme tout ça est lent, on a aussi inventé le cache mémoire pour forcer le proc a conserver certaines data ou certaines instructions en Ram pour avoir un accès rapide a ces informations en toutes circonstances.
2) Sont arrivées les Flash rapides qui permettent l'exécution du code "in place". Je dis rapide c'est par rapport à un µC qui tourne a quelques MHz. Plus besoin de charger le code en Ram pour l'exécuter. On peut faire des choses performantes même avec peu de RAM. C'est le cas des arduino AVR Atmel. Le cache instruction (icache) en Ram reste disponible pour y metrre le code a exécuter au plus vite. On doit être ultra sélectif car la place en RAM est limitée : Pour les premier arduino seulement 2K de Ram a partager entre data et icache!
3)Avec de la Flash quad spi qui fonce et beaucoup plus de Ram, un ESP8266 change la donne. Pour optimiser les accès, la Ram est segmentée : instructions, icache et data. Des parties de code exécutées fréquemment sont conservées en Ram. On dit que c'est pas la peine de mettre en cache des fonctions souvent appelées car elles sont naturellement présentes en Ram. Le paramètre ICACHE est pour forcer que ce code reste a coup sur.
Pour le reste, je ne suis pas certain de comment est géré la partie instructions en Ram: tout est mis en Ram au départ ou chargé depuis la Flash à la demande ? Quelle parties de code sont executées "in place" ? c'est la cuisine interne sans doute décrite quelque part.... ou pas. Espressif reste vague sur certains aspects.
Un autre intéret du cache c'est l'optimisation des accès. Quand la Ram mélange instructions et data, le proc doit faire le tri. En segmentant la RAM, il peut optimiser la lecture d'instructions et la lecture/écriture des data.
La plupart de ces mécanismes existent toujours dans les systèmes récents avec des niveaux d'optimisation pointus, dont les caches a plusieurs niveaux intégrés au processeur et des mémoires RAM de type différent type, spécialisée selon usage.
Là ou je coince c'est dans la situation 2) : quel intéret de mettre le cache instruction en flash (le fameux ICACHE FLASH ATTR d'arduino ) alors que le code est déjà exécute "in place" en flash, sauf bien sur celui qui est en icache ram. Surtout que sur les arduino la flash est unique: il n'y a pas une flash plus rapide pour l' "icache en flash". Il doit y avoir une subtilité qui m'échappe mais c'est pas bien grave.
(*) pour compléter, il existe sur ESP des alternatives à Arduino. Le fabricant a son propre framework-firmware avec son langage nommé LUA.
Il y a aussi micro-python qui permet d’exécuter des scripts python.
acheter un DSPiy ? c'est ici
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
Oui, Arduino va du petit 8 bits au Cortex M3.
J'ai un peu regardé l'ES8266 et en effet les infos ne sont pas données ce qui est bien regrettable.
Pour le 1) +- ok.
Le cache, à la base, n'est pas vraiment là pour garder certaines datas ou instructions à accès rapide. Hormis peut-être les processeurs Intel et autres.
Le cache, c'est une sorte de buffer qui a toujours existé qui fait l'interface entre un disque, par exemple, et les bus du CPU. Avec le temps sa taille a simplement fortement grossi.
2) les flash remplacent tout simple les ROM et EPROM, attention aussi à RAM, il y a aussi la DRAM qui n'est pas forcément rapide.
Les µC que nous utilisons de nos jours sont majoritairement RISC, donc un cycle par instruction comparé à souvent 12 dans le passé.
Avec 12 cycles on a bien plus de temps et de facilités à lire une mémoire.
3) la quad spi reste une mémoire série très lente, rien à voir avec la flash interne du µC du DSPiy, la série c'est comme la flash rajoutée sur le DSPiy qui n'est pas quad.
Pour adresser cette flash, il faut tout d'abord lui écrire dans ces registres l'adresse mémoire que l'on veut atteindre et seulement là elle va donner la donnée correspondante.
L'astuce est qu'elle peut donner la donnée à l'adresse correspondante et ensuite la donnée de l'adresse suivante et ainsi de suite. Là la vitesse devient correcte ce qui fait que cette mémoire fonctionne à vitesse raisonnable pour du data.
Pour des instructions, c'est pas la même chose. Hormis du code comme sur l'ADAU1701, un code c'est souvent des sauts, surtout en RISC. Donc à chaque saut il faudrait redonner la nouvelle adresse à la flash.
C'est hyper lent.
Je verrais plus justement un cache ou serait stocké de manière anticipée puis exécuté le code. (ce fameux ICACHE_FLASH)
Ce cache peut se remplir sans interférer le fonctionnement de l'unité centrale. Sauf pour une interrupt qui arrive de manière impromptue.
J'ai un peu regardé l'ES8266 et en effet les infos ne sont pas données ce qui est bien regrettable.
Pour le 1) +- ok.
Le cache, à la base, n'est pas vraiment là pour garder certaines datas ou instructions à accès rapide. Hormis peut-être les processeurs Intel et autres.
Le cache, c'est une sorte de buffer qui a toujours existé qui fait l'interface entre un disque, par exemple, et les bus du CPU. Avec le temps sa taille a simplement fortement grossi.
2) les flash remplacent tout simple les ROM et EPROM, attention aussi à RAM, il y a aussi la DRAM qui n'est pas forcément rapide.
Les µC que nous utilisons de nos jours sont majoritairement RISC, donc un cycle par instruction comparé à souvent 12 dans le passé.
Avec 12 cycles on a bien plus de temps et de facilités à lire une mémoire.
3) la quad spi reste une mémoire série très lente, rien à voir avec la flash interne du µC du DSPiy, la série c'est comme la flash rajoutée sur le DSPiy qui n'est pas quad.
Pour adresser cette flash, il faut tout d'abord lui écrire dans ces registres l'adresse mémoire que l'on veut atteindre et seulement là elle va donner la donnée correspondante.
L'astuce est qu'elle peut donner la donnée à l'adresse correspondante et ensuite la donnée de l'adresse suivante et ainsi de suite. Là la vitesse devient correcte ce qui fait que cette mémoire fonctionne à vitesse raisonnable pour du data.
Pour des instructions, c'est pas la même chose. Hormis du code comme sur l'ADAU1701, un code c'est souvent des sauts, surtout en RISC. Donc à chaque saut il faudrait redonner la nouvelle adresse à la flash.
C'est hyper lent.
Je verrais plus justement un cache ou serait stocké de manière anticipée puis exécuté le code. (ce fameux ICACHE_FLASH)
Ce cache peut se remplir sans interférer le fonctionnement de l'unité centrale. Sauf pour une interrupt qui arrive de manière impromptue.
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
Ton idée pour cache en flash tient la route. Il y a forcément une raison a l'existence de ce paramètre.
il faut un livre si on veut être précis et décrire la variété et l'évolution des technologies.
Moi je félicite les gars d'arduino pour avoir eu cette idée au départ et avoir porté sur processeurs aussi puissants a des prix abordables, facile a utiliser et le tout open source. Quand je pense que je m'en sert pour envoyer des codes IR au DSPiy a 12bits/34ms. Le choc de deux époques![Dan.San :mrgreen:](./images/smilies/14.gif)
il faut un livre si on veut être précis et décrire la variété et l'évolution des technologies.
Moi je félicite les gars d'arduino pour avoir eu cette idée au départ et avoir porté sur processeurs aussi puissants a des prix abordables, facile a utiliser et le tout open source. Quand je pense que je m'en sert pour envoyer des codes IR au DSPiy a 12bits/34ms. Le choc de deux époques
![Dan.San :mrgreen:](./images/smilies/14.gif)
acheter un DSPiy ? c'est ici
- thierryvalk
- Administrateur du site
- Messages : 3523
- Enregistré le : jeu. 9 juil. 2015 20:08
- Localisation : Belgique
Re: wDSPiy - commander le DSPiy par Wifi
Je n'ai jamais trop regardé Arduino, a la base c'était surtout là pour du didactique.
C'était aussi une bonne méthode pour pousser les µC d'Atmel.
Ce qui est marrant c'est l'historique de ces µC.
Intel était le numéro 1 avec ses 8048 puis 8051 qui existent toujours dans de nouveaux produits mais bien cachés.
Intel s'est concentré sur les PC, sont apparus ces étranges PIC très déroutants.
Plus tard Atmel,que j'avais rencontré sur un salon, à la base c'était une sorte PIC se programmant en Basic; ensuite ils ont commencé tout comme Philips des 8051 avec mémoire interne et boitier à nombre de Pin réduits.
Atmel est passé Microchips, Philips NXP tout comme Freescale ex Motorala...
On avait le choix entre une poignée de µC pour faire un développement alors qu’aujourd’hui c'est des milliers.
Rien que le µC du DSPiy se décline si ma mémoire est bonne en une bonne centaine de versions et encore je ne parle pas des emballages qui sont critiques en production.
Oui et non, ça fonctionne bien ces Telco. Ce qui est regrettable c'est que les 8 bits on presque disparus, pour un truc tout simple tu te retrouves avec du 32 bits et un gros paquet de lib.
C'était la parenthèse nostalgie,![Dan.San :)](./images/smilies/1.gif)
C'était aussi une bonne méthode pour pousser les µC d'Atmel.
Ce qui est marrant c'est l'historique de ces µC.
Intel était le numéro 1 avec ses 8048 puis 8051 qui existent toujours dans de nouveaux produits mais bien cachés.
Intel s'est concentré sur les PC, sont apparus ces étranges PIC très déroutants.
Plus tard Atmel,que j'avais rencontré sur un salon, à la base c'était une sorte PIC se programmant en Basic; ensuite ils ont commencé tout comme Philips des 8051 avec mémoire interne et boitier à nombre de Pin réduits.
Atmel est passé Microchips, Philips NXP tout comme Freescale ex Motorala...
On avait le choix entre une poignée de µC pour faire un développement alors qu’aujourd’hui c'est des milliers.
Rien que le µC du DSPiy se décline si ma mémoire est bonne en une bonne centaine de versions et encore je ne parle pas des emballages qui sont critiques en production.
Quand je pense que je m'en sert pour envoyer des codes IR au DSPiy a 12bits/34ms. Le choc de deux époques
Oui et non, ça fonctionne bien ces Telco. Ce qui est regrettable c'est que les 8 bits on presque disparus, pour un truc tout simple tu te retrouves avec du 32 bits et un gros paquet de lib.
C'était la parenthèse nostalgie,
![Dan.San :)](./images/smilies/1.gif)
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
les ATTiny85 existent encore
avec 512octets de RAM ca permet aux anciens de rester jeunes ![Dan.San ;)](./images/smilies/6.gif)
![Dan.San ;)](./images/smilies/6.gif)
![Dan.San ;)](./images/smilies/6.gif)
acheter un DSPiy ? c'est ici
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
Aujourd'hui j'ai la réponse à une question qu'on se posait sur l'utilité du petit fil antenne soudé au pcb. La réponse est OUI il est indispensable!
Tout est parti d'une mise a jour software anodine par wifi il y a deux jours. La mise a jour Over The Air s'est bien passée mais, pour une bétise, le code uploadé a fait planter le µC! Planter tellement qu'il a fallu brancher le cable USB. Obligé de démonter la face ar de l'ampli et retirer le premier étage.
J'ai tout remonté et juste testé le soft. Tout semblait aller.
Aujourdh'ui, fete de la musique, c'etait le jour pour en écouter. Et patatras : plus de bluetooth.
Recherche de panne, démontage pour y voir de plus près et le petit cable antenne m'est resté dans les doigts. Il n'était plus soudé à la carte! Il n'a pas aimé les manipulations a chaque montage/démontage de la face ar.
Démontage, sortage de la carte du boitier, soudage avec la loupe, testage , collage du cable a la superglue, remontage et enfin fetage de la musique![Dan.San :)](./images/smilies/1.gif)
pfff, c'est pas cool la vie du diyer, surtout avec des gros doigts et la vue qui baisse !
Leçon pour le futur : laisser un accès usb et un accès au bouton reset dans tous mes projets.
Tout est parti d'une mise a jour software anodine par wifi il y a deux jours. La mise a jour Over The Air s'est bien passée mais, pour une bétise, le code uploadé a fait planter le µC! Planter tellement qu'il a fallu brancher le cable USB. Obligé de démonter la face ar de l'ampli et retirer le premier étage.
J'ai tout remonté et juste testé le soft. Tout semblait aller.
Aujourdh'ui, fete de la musique, c'etait le jour pour en écouter. Et patatras : plus de bluetooth.
Recherche de panne, démontage pour y voir de plus près et le petit cable antenne m'est resté dans les doigts. Il n'était plus soudé à la carte! Il n'a pas aimé les manipulations a chaque montage/démontage de la face ar.
Démontage, sortage de la carte du boitier, soudage avec la loupe, testage , collage du cable a la superglue, remontage et enfin fetage de la musique
![Dan.San :)](./images/smilies/1.gif)
pfff, c'est pas cool la vie du diyer, surtout avec des gros doigts et la vue qui baisse !
Leçon pour le futur : laisser un accès usb et un accès au bouton reset dans tous mes projets.
acheter un DSPiy ? c'est ici
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
je bricole a ma "télécommande" avec encodeur et Oled. C'est assez marrant à faire et me sera fort utile au quotidien
j'ai trouvé un bout de code fort intéressant pour gérer le rotary encoder, cad la molette en bon belge du sud![Dan.San ;)](./images/smilies/6.gif)
Ca permet de changer le volume avec l'encodeur en accéléré quand on tourne vite... tout en permettant toujours d'atteindre chaque valeur si on tourne lentement.
Très pratique pour changer le volume rapidement sans se fouler le poignet![Dan.San :)](./images/smilies/1.gif)
j'ai trouvé un bout de code fort intéressant pour gérer le rotary encoder, cad la molette en bon belge du sud
![Dan.San ;)](./images/smilies/6.gif)
Code : Tout sélectionner
// dans le code en amont, rotaryState = 0 si l'encodeur n'a pas bougé
// rotaryState = 1 si rotation clockwise et -1 dans l'autre sens
// sensitivity est une constante a régler selon sa préférence. Dans mon cas bon résultat avec 100ms
// lastChange est une variable globale. Les autres sont locales à la fonction
// en sortie, rotaryState vaut 0, 1, 2 ou 3 (ou -1,-2,-3) selon la vitesse et le sens de rotation
if (rotaryState != 0) {
timeStamp = millis();
changeDelay = timeStamp - lastChange;
lastChange = timeStamp;
// Check speed
if (changeDelay < (sensitivity / 2)) {
rotaryState *= 3;
} else if (changeDelay < sensitivity) {
rotaryState *= 2;
}
}
return rotaryState;
Ca permet de changer le volume avec l'encodeur en accéléré quand on tourne vite... tout en permettant toujours d'atteindre chaque valeur si on tourne lentement.
Très pratique pour changer le volume rapidement sans se fouler le poignet
![Dan.San :)](./images/smilies/1.gif)
acheter un DSPiy ? c'est ici
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
je réalise que n'ai pas publié de photo de ma télécommande_à_DSPiy_avec_oled+molette. (Le nom est un peu long.) alors que je l'utilise avec bonheur depuis cet été
![Image](https://i.imgur.com/soDwUrT.png)
C'était pas prévu comme ça au début, mais finalement j'ai bien aimé le coté transparent "tripes a l'air" et c'est resté![Dan.San ;)](./images/smilies/6.gif)
![Image](https://i.imgur.com/soDwUrT.png)
C'était pas prévu comme ça au début, mais finalement j'ai bien aimé le coté transparent "tripes a l'air" et c'est resté
![Dan.San ;)](./images/smilies/6.gif)
acheter un DSPiy ? c'est ici
- alka
- Administrateur du site
- Messages : 2908
- Enregistré le : mer. 15 juil. 2015 15:18
- Localisation : 92
- Contact :
Re: wDSPiy - commander le DSPiy par Wifi
C'est l'automne, c'est confinement : le moment de reprendre les projets en pause.
J'ai dans l'idée depuis quelques temps de rajouter la possibilité de prise de contrôle du wDSPiy par MQTT.
MQTT est un protocole léger, très prisé en IOT. J'avais envie de trouver un prétexte pour m'y mettre.
Ca me donnera des nouvelles possibilités de contrôle à distance et aussi d'alléger le code de ma télécommande_à_DSPiy_avec_oled+molette (c'est vraiment trop long ce nom).
En MQTT il faut un serveur, le Broker. Il peut etre n'importe où du moment qu'il est accessible par le réseau.
Les Clients se connectent au Broker et publient (publish) des messages sur des topics. Les Clients s'abonnent (subscribe) aussi aux topics qui les concernent et en reçoivent les messages. Il suffit de bien déterminer qui publie où et a quoi s'abonner et on peut faire un peu tout. Les messages envoyés sont en principe courts. C'est un protocole léger idéal pour l'IOT.
Après quelques lectures sur le sujet il y a plusieurs mois, je m'y suis mis cette semaine. J'ai ressorti mon environnement de test : ESP8266 de test connecté au prototype DSPiy v1. Ca me permet de bricoler sans casser le DSPiy en production.
- Sortir le Hardware et me rappeler comment brancher le tout (y compris le pc avec Arduino) : une demi journée
- Installation d'une librairie Broker MQTT sur ESP8266 (uMQTTBroker de Martin-Ger) : 10 minutes
Le broker est aussi client. Je l'ai abonné à tout (#).
- Premiers tests avec deux clients : un sur pc (MQTTlens. c'est une Chrome app) et un sur Android (myMQTT) : 15 minutes; Le plus long a été de trouver une app MQTT Android qui ne soit pas trop compliquée. Ca marche de suite !
- Coté wDSPiy (ESP8266) , codage pour traiter quelques commandes minimales. A réception, publier l'état du DSPiy en format JSON sur le topic wd/status : 1H*+15min (15 minutes pour que ça marche et une heure consacrée à trouver comment convertir un char en int !!!! solution pour les curieux plus bas)
Commandes implémentées en test : (pas de payload dans le message, tout est dans le nom du topic)
wd/volplus
wd/volmoins
wd/on
wd/sby
wd/sourcen avec n de 0 à 6
J'ai aussi passé beaucoup de temps à replonger dans mon ancien code pour comprendre, nettoyer, remettre en forme, simplifier. C'est fou comme ça prend du temps de se remettre dans son propre code.
Comme j'oublie la syntaxe des langages et qu'en plus je me perd en confusions entre C++, javascript et les autres, j'ai trouvé ce site qui m'aide bien : https://www.onlinegdb.com/online_c_compiler Il y a meme un debugger!
A ce stade MQTT fonctionne en test![Dan.San :)](./images/smilies/1.gif)
Reste à structurer correctement les topics MQTT pour que ça ressemble à quelquechose et à ré-écrire le code ma télécommande_à_DSPiy_avec_oled+molette (j'ai déjà dit que c'était trop long, non ) pour passer de HTTP-Request à MQTT. Ca va m'occuper le reste du confinement
Conversion char en int
J'ai dans l'idée depuis quelques temps de rajouter la possibilité de prise de contrôle du wDSPiy par MQTT.
MQTT est un protocole léger, très prisé en IOT. J'avais envie de trouver un prétexte pour m'y mettre.
Ca me donnera des nouvelles possibilités de contrôle à distance et aussi d'alléger le code de ma télécommande_à_DSPiy_avec_oled+molette (c'est vraiment trop long ce nom).
En MQTT il faut un serveur, le Broker. Il peut etre n'importe où du moment qu'il est accessible par le réseau.
Les Clients se connectent au Broker et publient (publish) des messages sur des topics. Les Clients s'abonnent (subscribe) aussi aux topics qui les concernent et en reçoivent les messages. Il suffit de bien déterminer qui publie où et a quoi s'abonner et on peut faire un peu tout. Les messages envoyés sont en principe courts. C'est un protocole léger idéal pour l'IOT.
Après quelques lectures sur le sujet il y a plusieurs mois, je m'y suis mis cette semaine. J'ai ressorti mon environnement de test : ESP8266 de test connecté au prototype DSPiy v1. Ca me permet de bricoler sans casser le DSPiy en production.
- Sortir le Hardware et me rappeler comment brancher le tout (y compris le pc avec Arduino) : une demi journée
- Installation d'une librairie Broker MQTT sur ESP8266 (uMQTTBroker de Martin-Ger) : 10 minutes
Le broker est aussi client. Je l'ai abonné à tout (#).
- Premiers tests avec deux clients : un sur pc (MQTTlens. c'est une Chrome app) et un sur Android (myMQTT) : 15 minutes; Le plus long a été de trouver une app MQTT Android qui ne soit pas trop compliquée. Ca marche de suite !
- Coté wDSPiy (ESP8266) , codage pour traiter quelques commandes minimales. A réception, publier l'état du DSPiy en format JSON sur le topic wd/status : 1H*+15min (15 minutes pour que ça marche et une heure consacrée à trouver comment convertir un char en int !!!! solution pour les curieux plus bas)
Commandes implémentées en test : (pas de payload dans le message, tout est dans le nom du topic)
wd/volplus
wd/volmoins
wd/on
wd/sby
wd/sourcen avec n de 0 à 6
J'ai aussi passé beaucoup de temps à replonger dans mon ancien code pour comprendre, nettoyer, remettre en forme, simplifier. C'est fou comme ça prend du temps de se remettre dans son propre code.
Comme j'oublie la syntaxe des langages et qu'en plus je me perd en confusions entre C++, javascript et les autres, j'ai trouvé ce site qui m'aide bien : https://www.onlinegdb.com/online_c_compiler Il y a meme un debugger!
A ce stade MQTT fonctionne en test
![Dan.San :)](./images/smilies/1.gif)
Reste à structurer correctement les topics MQTT pour que ça ressemble à quelquechose et à ré-écrire le code ma télécommande_à_DSPiy_avec_oled+molette (j'ai déjà dit que c'était trop long, non ) pour passer de HTTP-Request à MQTT. Ca va m'occuper le reste du confinement
![Dan.San :mrgreen:](./images/smilies/14.gif)
Conversion char en int
Code : Tout sélectionner
// je déteste le c
char c = '3';
int i = (int) c; // i contient 51
int cn = c - '0'; // cn contient 3
acheter un DSPiy ? c'est ici
Retourner vers « DSPiy général »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 8 invités