Forum TI-Planet.org

Un petit rebase sur le dernier code d'upstream, ce qui permet de supprimer quelques hacks que j'ai dû faire. Pas d'autres changements. Mon repo https://github.com/debrouxl/circuitpython est à jour

* branche master: DPFP + cmath + fonctions spéciales maths + LONGLONG longint + storage + os:

Code: Select all

LINK build-trinket_m0/firmware.elf

864 bytes free in flash out of 188416 bytes ( 184.0 kb ).
26652 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 375296, start address: 0x2000
Wrote 375296 bytes to build-trinket_m0/firmware.uf2.

* branche master2: DPFP + cmath + fonctions spéciales maths + MPZ longint:

Code: Select all

LINK build-trinket_m0/firmware.elf

272 bytes free in flash out of 188416 bytes ( 184.0 kb ).
26760 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 376320, start address: 0x2000
Wrote 376320 bytes to build-trinket_m0/firmware.uf2.

Encore un petit rebase sur le dernier code d'upstream, légèrement postérieur à 4.0.0-beta.5 ( b4b8ffa0e23a276f20aa8f9d689da420a71a4ab2 ). Comme d'habitude, mon repo https://github.com/debrouxl/circuitpython est à jour. Pour une fois, je n'ai pas eu à résoudre de conflits... c'est appréciable

Un petit changement depuis la dernière fois: comme des bugfixes dans le code upstream ont augmenté la taille de plusieurs centaines d'octets, j'ai dû désactiver MICROPY_PY_BUILTINS_STR_SPLITLINES, mais la taille du build MPZ longint est encore plus proche de la limite que la fois précédente...

* branche master: DPFP + cmath + fonctions spéciales maths + LONGLONG longint + storage + os:

Code: Select all

LINK build-trinket_m0/firmware.elf

772 bytes free in flash out of 188416 bytes ( 184.0 kb ).
26652 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 375296, start address: 0x2000
Wrote 375296 bytes to build-trinket_m0/firmware.uf2.

* branche master2: DPFP + cmath + fonctions spéciales maths + MPZ longint:

Code: Select all

LINK build-trinket_m0/firmware.elf

180 bytes free in flash out of 188416 bytes ( 184.0 kb ).
26760 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 376832, start address: 0x2000
Wrote 376832 bytes to build-trinket_m0/firmware.uf2.

Et un nouveau rebase sur upstream, commit 5478610e591f404baeb60d01d0997754ba4734cb . Comme d'habitude, mon repo https://github.com/debrouxl/circuitpython est à jour.

La taille de CircuitPython ayant encore augmenté, j'ai dû passer de MICROPY_ERROR_REPORTING_DETAILED à MICROPY_ERROR_REPORTING_NORMAL pour gagner plus de 500 octets et rester dans la limite de 184 KB... C'est dommage, c'était un des points sur lesquels mes firmwares étaient plus avancés que le firmware de TI, qui semble utiliser MICROPY_ERROR_REPORTING_NORMAL, d'après un message d'erreur qu'on trouve dans l'image binaire - c'est la version NORMAL et non la version DETAILED.

* branche master: DPFP + cmath + fonctions spéciales maths + LONGLONG longint + storage + os:

Code: Select all

LINK build-trinket_m0/firmware.elf

736 bytes free in flash out of 188160 bytes ( 183.75 kb ).
26648 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 375296, start address: 0x2000
Wrote 375296 bytes to build-trinket_m0/firmware.uf2.

* branche master2: DPFP + cmath + fonctions spéciales maths + MPZ longint:

Code: Select all

LINK build-trinket_m0/firmware.elf

160 bytes free in flash out of 188160 bytes ( 183.75 kb ).
26744 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 376320, start address: 0x2000
Wrote 376320 bytes to build-trinket_m0/firmware.uf2.

Un nouveau rebase sur upstream, commit 03f9048778ecad2bbd7d07d01f3b64153a36c177 , et l'habituelle mise à jour de mon repo https://github.com/debrouxl/circuitpython .

J'ai eu pas mal de soucis pour réaliser cette version, parce que les changements dans upstream, en particulier une mise à jour du submodule tinyusb et la nécessité d'activer le module board, avaient à la fois cassé la communication USB avec l'ordinateur et fait dépasser la taille disponible. Le pauvre critor a testé plus de versions qui ne fonctionnaient pas que de versions qui fonctionnaient, avant que je puisse comprendre en partie et poster dans un bug report. Il s'est avéré que ce n'était pas le même problème que l'autre utilisateur, je n'enlevais simplement pas les capacités USB HID, USB MIDI et les strings correspondantes des descripteurs USB. Auparavant, cela ne posait pas de problème, mais maintenant, si. Quand on vire toutes ces données inutiles des descripteurs, on gagne de l'ordre de 400 octets (2 pour mille), en plus...
Quant à la limite de taille, j'ai fini par voir que le module board référençait I2C, SPI et UART, dont on se contre-fiche sur le TI-Python Adapter, faute de ports. Si on désactive les références à chacun de ces trois objets, on gagne immédiatement environ 10 KB (!), parce que plein d'éléments de code et données non référencés peuvent alors être éliminés par le linker. En fin de compte, pour rester dans la limite des 183.75 KB tout en ne réduisant pas trop la fonctionnalité pour les autres boards à base d'ATSAMD21 qui proposent les I/O habituelles, j'ai choisi d'activer l'implémentation MPZ des entiers longs - comme le fait TI - ainsi qu'os et storage, et de désactiver seulement l'I2C. Avec ça, il reste de la marge - qui sera partiellement rognée avec l'inclusion de l'émulation de la protection de TI - et il n'y a donc, pour l'instant, plus besoin que d'une seule version des binaires

* branche master: DPFP + cmath + fonctions spéciales maths + MPZ longint + storage + os:

Code: Select all

LINK build-trinket_m0/firmware.elf

1036 bytes free in flash out of 188160 bytes ( 183.75 kb ).
26736 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 374272, start address: 0x2000
Wrote 374272 bytes to build-trinket_m0/firmware.uf2.

Rebase sur le commit upstream e072f0d893eb7854b01a7c4e1a8cfcae9af51026 , équivalent à 4.0.0-rc.1, puisque leur release officielle 4.0 s'approche à grands pas. Aucun changement.

* branche master: DPFP + cmath + fonctions spéciales maths + MPZ longint + storage + os:

Code: Select all

LINK build-trinket_m0/firmware.elf

1068 bytes free in flash out of 188160 bytes ( 183.75 kb ).
26736 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ).

Create build-trinket_m0/firmware.bin
Create build-trinket_m0/firmware.uf2
Converting to uf2, output size: 374272, start address: 0x2000
Wrote 374272 bytes to build-trinket_m0/firmware.uf2.

Je suis finalement parvenu à faire "accepter" un firmware tiers à la calculatrice, avec le module "officiel"

Le principe est d'utiliser un bootloader modifié qui "ne fait rien" quand la calculatrice veut mettre à jour le module. Le problème c'est qu'en dehors du lancement de l'application, elle veut aussi mettre à jour le module lorsque l'on sort de l'éditeur de script avec le menu "exec". C'est un peu pénible de devoir attendre mais bon... ça fonctionne :



Ci-joint la mise à jour du bootloader et la version modifiée du firmware de Lionel.

ATTENTION : ce bootloader n'accepte plus les UF2 "standards", mais uniquement ceux avec un le header UF2_MAGIC_START0 = 0x0A324755 (ce qui empêche effectivement la calculatrice de mettre à jour le module).

Les sources du bootloader modifié sont ici : https://github.com/zardam/uf2-samdx1/tree/tipython

Pour CircuitPython, c'est un peu pénible avec les sous modules git, mais les deux modifications sont :
- tools/uf2/utils/uf2conv.py : UF2_MAGIC_START0 = 0x0A324755
- lib/tinyusb/src/class/msc/msc_device.c : ajouter "p_csw->status = MSC_CSW_STATUS_PASSED;" ligne 322 (au début de la fonction "mscd_xfer_cb"). J'ai l'impression que c'est un bug de la tinyusb, qui ne reset pas le statut entre deux transferts à chaque fois.

PS : la mise à jour du bootloader pour revenir en arrière (accepter les UF2 standard).

Attention, ce n'est pas le bootloader "officiel", mais il fonctionne avec la calculatrice.

Super, très bien joué
Je vais adopter ça rapidement.

Pour CircuitPython, c'est un peu pénible avec les sous modules git, mais les deux modifications sont :
- tools/uf2/utils/uf2conv.py : UF2_MAGIC_START0 = 0x0A324755
- lib/tinyusb/src/class/msc/msc_device.c : ajouter "p_csw->status = MSC_CSW_STATUS_PASSED;" ligne 322 (au début de la fonction "mscd_xfer_cb"). J'ai l'impression que c'est un bug de la tinyusb, qui ne reset pas le statut entre deux transferts à chaque fois.

Comme tu as trafiqué le bootloader, c'est plus simple que les changements que tu avais fait précédemment.

Merci, super.

En dehors du TI-Python, peux-tu préciser la compatibilité de ce bootloader ?
Trinket je suppose ? D'autres pyboards ?

Autre question, combien de temps prend la reprogrammation du boot ?
La dernière fois sur Trinket, ce qui m'avait embêté c'était l'absence de feedback.
Donc par crainte de tout casser j'avais attendu je crois presque 2 minutes que Windows se décide à reporter du changement sur l'USB.

critor wrote:En dehors du TI-Python, peux-tu préciser la compatibilité de ce bootloader ?
Trinket je suppose ? D'autres pyboards ?

C'est un bootloader pour trinket m0, il fonctionne aussi sur mon clone d'arduino zero. Pour le reste, je ne peux pas trop m'avancer, mais je suppose que la plupart des cartes SAMD21 sont assez similaires, au moins au niveau de l'USB. Pour les aventureux, prévoir de pouvoir restaurer le bootloader au cas ou (une bluepill en blackmagic probe par exemple), ou de compiler une version dédiée à la carte.

critor wrote:Autre question, combien de temps prend la reprogrammation du boot ?

C'est quasi immédiat. À la fin, la carte reboote d'elle même dans le bootloader. Ça peut passer inaperçu si l'OS remonte automatiquement le lecteur.

J'ai une autre piste pour éviter la tentative de mise à jour, mais pour l'instant, ça ne fonctionne pas (la carte et/ou la calculatrice sont dans un état incohérent ensuite). Je vais essayer de creuser à l'occasion.

PS : Je me suis équipé d'un https://www.dreamsourcelab.com/product/dslogic-plus/ et j'en suis assez content. Il fonctionne parfaitement avec https://sigrok.org/wiki/PulseView et le firmware (y compris le FPGA) sont open source : https://github.com/DreamSourceLab/DSLogic-hdl et https://github.com/DreamSourceLab/DSLogic-fw