French Version

MIDIbox Hardware Platform, module USB PIC

Ce module a été pensé comme une alternative simple et économique au module MBHP_USB . Il repose sur un PIC18F4550 (ou PIC18F2550), disponible pour moins de 6 US$.
Dans le même temps, une meilleure solution a été trouvée: MBHP_USB_GM5

Historique - firmware MBHP_USB_PIC firmware, première approche

Initialement la réalistion de ce projet ne devait prendre qu'une petite journée, c'était sans compter les complications qui se sont présentées lors du portage du MBHP_USB (basé sur une puce Cypress) vers l'architecture the PIC que je connais trés bien. Les descripteurs USB pour le MIDI USB, le parser MIDI, le gestionnaire d'intéruptions pour les émissions/réceptions MIDI étaient près à être réutilisés...

Donc, par un pluvieux week-end de 2005, j'ai téléchargé l'environnement USB sur le site de Microchip, intallé le bootloader USB (pour une mise à jour rapide des codes), et j'ai intégré à l'exemple CDC le code pour la gestion basique du MIDI. Pendant les premiers tests, déjà j'ai remarqué que le code donné en exemple tournait de façon moins stable que ce à quoi je m'attendais. En condition "stress", des données MIDI se perdent côté reception, et les données transmises sont sporadiquement corrompues.

Aprés quelques heures de tests et d'analyses de mon propre code, je suis arrivé à la conclusion que le problème ne venait pas de là. J'ai donc entrepris de résoudre le problème à la transmission d'abord en écrivant un court programme, qui renvoyait simplement les données MIDI reçues vers le port de sortie. Même ce code minimal n'évitait pas les erreurs: avec d'importants dumps SysEx, parfois le nombre de données renvoyées dépassait le nombre de données reçues. On sait que des données peuvent être perdues lorsqu'un "renvoie en série" ne renvoie pas le flux entrant au moins aussi vite qu'il est reçu (goulot), mais comment des bytes peuvent êtres ajoutées lorsque le software est suffisament primitif pour ne pas être source d'erreurs?

J'ai testé quand même ce bout de code sur une puce connue pour bien fonctionner - le PIC18F452.Et là ça marchait trés bien! J'ai donc supposé un problème d'origine matériel (Composant overclocké? Tension instable? puce défectueuse? ligne Rx/Tx parasitées?), mais trois PIC18F4550 et trois PIC18F4520 ont montré les mêmes symptômes sur différents circuits. J'ai parcouru la doc sur le périphérique EUSART, soupçonnant une incompatibilité logicielle, mais selon les datasheets il est sensé se comporter de la même manière qu'avec les anciennes versions. J'ai cherché dans les rapports d'erreurs, mais même le bug documenté des interruptions n'expliquait rien, car je n'utilisai plus d'interruptions à ce moment là. J'ai donc continué à analyser ces symptômes en suivant le même scénario test, avec deux puces: un PIC18F452 recevant et envoyant des données depuis/vers un PIC18F4550, et activant une sortie en cas de différence, afin que les données mal transmises puissent être capturées à l'oscilloscope. J'ai ensuite ajouté un "delai dynamique" dans la routine de renvoi du PIC18F4550, afin d'émuler le jitter causé par la gestion des interruptions dans les applications réelles. Cette configuration m'a permis de reproduire facilement le problème, et de visualiser sur l'oscillo les données émises en trop.

Pour faire court - les bytes en trop sont causées par un bug sillicone du périphérique EUSART. Voir aussi cet articlesur le forum Microchip, où j'ai rapporté mes observations. J'ai dû contacter Microchip de multiples fois sur ce point, ce bug sillicone existant dans plusieurs puces produites par le passé. Ils ont finalement décidé d'ajouter des explications sur ce bug dans les rapports d'erreurs de certains microcontrôleurs affectés (mais pas pour tous) . Le bug y est décris, avec quelques explications pour contourner le problème de façon logicielle.

Quelques mots à propos des solutions décrites (voir errata sheet, bug #19): aucune des deux n'est utilisable dans mon cas, à cause d'un risque potentiel de saturation du buffer côté récepteur lors des transfert de données. Plus particulièrement pour le MIOS , de telle solutions ne sont pas applicables car ells affectent trop les performances, et il n'y a pas assez de ressources disponibles.

Donc, au final: j'ai arrêter le developpement du pilote, surtout parce qu'il m'était impossible d'être certain que ce bug serait résolu pour les prochaines séries, et qu'il est difficile de savoir en commandant les composants sur le net par ex. chez Mouser ou Reichelt s'il s'agit de puces buggées ou non.

Malgré cette mauvaise expérience, j'ai suivi les nouveaux développement chez Microchip dans les mois suivant, et j'ai testé quelques nouvelles révisions de PIC18F4550, PIC18F4520 et PIC18F4620. Entre 2005 et 2007, toutes les puces sont affectées du bug, même lorsque le bug n'est pas rapporté dans les erratas. Microchip semble ne pas trop s'inquiéter de ce problème, ni de fournir une doc cohérente à ce sujet.

FYI: Decembre 2007: j'ai testé un PIC18F4550 revision 5 où le bug EUSART a été finalement corrigé.

Historique - firmware MBHP_USB_PIC firmware, deuxième approche:

Un an plus tard, au printemps 2006, j'ai repris le développement du firmware; pour contourner le bug, je suis parti sur l'idée d'un emmeteur/recepteur MIDI connecté via IIC - le module MBHP_IIC_MIDI . J'ai entièrement réécrit le firmware en assembleur, car ma version d'évaluation de 3 mois du compilateur MPLAB-C18 avait expirée, et aussi car je voulais être sûr que n'importe qui puisse compiler le firmware sous Windows/Linux/MacOS sans avoir besoin de passer par des logiciels coûteux. Pour des questions de performances également - il y avait un risque que le code généré par le compilateur gratuit SDCC soit trop lent pour gérer 5 ports MIDI In et 4 ports MIDI Out.

Oui, vous avez bien lu: il s'agit ici de piloter 4 modules MBHP_IIC_MIDI + le port MIDI In "interne" via le port EUSART à partir d'un unique périphérique USB:

D'une façon générale, le firmware tournait sans problème sous PC Windows et Linux, mais je n'était pas satisfait par l'implémentation d'origine du protocole MIDI pour l'USB, car il n'offrait pas la possibilité d'une utilisation "multi-clients". Je travaillais surtout sous Windows à ce moment là, par ex. pour développer de nouveaux firmwares et les uploader avec MIOS Studio, tout en utilisant MIDI-Ox et Reaktor ou Logic Audio en parallèle - donc un mode multi-clients était essentiel pour moi.

L'autre problème que j'ai pu remarquer concerne la perte de données durant certains transferts d'importants dumps SysEx, perte qui se produit lorsque les données sur le port MIDI Out sont renvoyées sur le port MIDI In. J'ai appellé ce symptôme "blocked pipes" dans cet article en allemand, car ça illustre bien le problème: en cas de réception importante, le canal d'entrée est sporadiquement bloqué pendant quelques millisecondes si le canal de sortie n'est pas appelé immédiatement aprés que l'hôte ait envoyé de nouvelles données. La capture d'oscilloscope illustre cet effet:

Le canal inferieur bascule à chaque fois que le gestionnaire "endpoint" des IN/OUT (USBCLS_EP2_Handler) est appellé, et le canal supérieur reflète l'état du flag BD2_STAT.UOWN, qui est actif tant que le SIE contrôle le buffer IN.

Ce phénomène peut entraîner des vidage du buffer côté recepteur MIDI. J'ai re-vérifier tout ça en remplaçant chaque troisième byte d'un flux SysEx par le nombre de bytes libres dans le buffer de réception:

Ce traçage démontre: a) que moins de bytes sont recues que transmises, et b) qu'il y a des écarts importants dans le nombre de bytes libres. par ex. 0x7f -> 0x5a signifie que nous avons à bufferiser 37 bytes. A un baudrate de 32150, cela veut dire que le endpoint IN a été bloqué pendant environ 11 mS - et cette durée correspond avec ce que l'on observe à l'oscillo!
Comme ça se produit de multiples fois pendant le transfert d'un flux SysEx, le buffer de réception se vide trés rapidement et cause des pertes de données. Note: quand le MIDI Out est directement renvoyé sur le MIDI In!

Le phénomène ne se produit pas lorsque les ports MIDI In/Out sont connectés à un appareil MIDI externe qui ne reçoit/envoie des données SysEx de façon quasi uni-directionnelle. Par exemple lorsque des dumps SysEx sont envoyés depuis l'interface MIDI vers le MBHP_USB_PIC, ou l'inverse, aucune perte de données ne survient.

NB: cet effet se produit même si le firmware suspends USBCLKS_EP2_Hander_Out tant que le buffer ne s'est pas vidé. Donc, empêcher ces paquets d'être renvoyés vers le MIDI Out tant que des données sont reçues n'e résoud pas le problème.

Il n'est toujours pas clair pour moi si il s'agit d'un problème relatif au PIC ou à Windows. Il ne m'a pas était possible encore de reproduire la même chose sous Linux, mais la raison pourrait être que les pilotes USB fonctionnent sur des timings différents (par ex. plus lentement ou plus vite que le pilote Windows...).

Fait intéressant: j'ai pu lire dans différents forum que les appareils MIDI de Korg, Behringer et ESI, qui utilisent aussi le pilote intégré de windows, avaient le même problème avec les gros transferts SysEx. Ces marques proposent des pilotes alternatifs, mais qui sont malheureusement protégés et ne peuvent êtres réutilisés pour des projets amateurs juste en adaptant les descripteurs USB. Et autre point intéressant, qui n'a fait qu'ajouter à ma confusion : je n'ai pas pu reproduire ce phénomène avec l'interface MBHP_USB à base de AN2131SC.

Du coup je me suis un peu détourné de l'USB (encore), pour créer le projet MIDI Router, qui s'avère plus flexible pour ma manière de travailler, car il permet de renvoyer/gérer les données MIDI de plusieurs appareils même sans ordinateur et avec de meilleures performances en termes de timing.

: Dans les mois qui suivirent j'ai eu beaucoup de mails et de requête sur le forum à propos du projet MBHP_USB_PIC. Certains voulait recourir à cette solution DIY par économie, d'autres avec l'intention de se servir du firmware comme base pour leur propre projet. J'ai n'ai jamais trouvé la motivation pour documenter ce projet proprement pour les raisons citées plus haut, et du coup je n'ai distribué le firmware qu'à quelques personnes, en les informant de ces limitations.

Installation

Pour ceux que ces explications n'ont pas découragé, voici la procédure d'installation:.

Je recommande fortement l'installation du bootloader USB de Microchip, que vous trouverez à la section download en bas de page. L'archive contient un fichier .hex qui doit être programmé dans un PIC avec un programmateur type MBHP_BURNER. Une fois ceci fait, vous serez en mesure d'uploader les mises à jours du firmware MBHP_USB_PIC trés simplement via une application Windows.

Les utilisateurs d'autres OS ne tireront aucun bénéfice de l'utilisation de ce bootloader USB, et peuvent charger le firmware MBHP_USB_PIC directement (par exemple sous Linux avec "pkp").

Une fois que votre module CORE est terminé et fonctionnel, Windows va vous demander le pilote -vous le trouverez dans le dossier "pc_usb_driver" de l'archive du bootloader.

Vous pouvez maintenant lancer l'application "Pdfsusb" et charger le firmware "project.hex", qui se trouve dans l'archive MBHP_USB_PIC :

Cliquez ensuite sur le bouton "Program Device", ensuite sur "Execute" dans l'application, ou faîtes un reset du PIC avec le bouton Reset d votre circuit. Windows doit reconnecter le périphérique USB et trouver un "Péripherique Audio" (en allemand: "Audiogerät", anglais :"Audio device"). MIDI-Ox devrait alors vous le proposer dans la liste des interfaces (sinon, redémarrez MIDI-Ox s'il était en train de tourner!)

Désormais le PIC démarrera toujours avec le firmware MBHP_USB_PIC firmware aprés un reset ou une mise sous tension. A chaque fois que vous voulez mettre à jour le firmware, appuyez simultanément sur les touches Bootloader et Reset, relâchez ensuite uniquement le bouton Reset jusqu'à ce que Windows vous informe de la détection d'un changement de périphérique USB (cela survient immédiatement aprés le reset). Relâcher maintenant le bouton Bootloader et sélectionnez de nouveau le périphérique "PICDEM FS USB 0 (Boot)" dans l'application Pdfusb (la sélection restera vide jusqu'à là), chargez le nouveau fichier .hex file et cliquez sur le bouton "Program Device".

Si vous prévoyez de connecter des modules MBHP_IIC_MIDIcomme extension d'entrées/sorties,vous aurez besoin de recompiler le firmware avec des réglages différents. MAKEFILE.SPEC: réglez IIC_MIDI_MAX_NUMBER sur 4 et NUMBER_MIDI_INTERFACES sur 5. Utilisateurs Windows: lancez simplement le script make.bat (doubleclick dans l'Explorer, ou tapez "make" dans l'invite de commande). Les utilisateurs Linux/MacOS doivent taper "tools/mkmk.pl MAKEFILE.SPEC; make". SDCC et GPASM sont requis pour la compilation, C'est à la base la même suite d'outils que celle utilisée pour les applications MIOS en C.

Un diagramme de connection pour les modules est disponible ici. Notez que les pins d'entrées RA0/1/2/3 non utilisées (qui ne sont pas connectées au bus RI# d'un module MBHP_IIC_MIDI ) doivent êtres connectées sur Vdd (+5V), dans le cas contraire, le firmware peut se comporter de façon aléatoire (ralentissements ou crash), car il n'est plus à même de savoir si un module a reçu des données ou non. Cette modif ne doit être pris en compte que lorsque le paramètre IIC_MIDI_MAX_NUMBER doit être différent de 0 (dans le fichier MAKEFILE.SPEC - ce qui explique pourquoi cette option est désactivée par défaut).

Structure du Firmware

Ces informations n'ont d'utilité que pour ceux qui souhaite débugguer le firmware, ou l'améliorer. Le code est séparé en différent modules, pour une distinction claire des fonctions. Il a été implémenté totalement en Assembleur, afin que n'importe qui puisse compiler le firmware sous Windows/Linux/MacOS sans outils spéciaux ni chers. SDCC est requis pour créer les tables de descripteurs USB (c'était la solution la plus simple, car GPASM ne permet pas de définir des arrays dynamique). Pour étendre le firmware, il est possible d'ajouter des modules en C dans le futur, mais tenez compte du fait que SDCC n'est pas capable de générer du code performant pour gérer les paquets de données et les buffers aussi efficacement que ce que j'ai pu faire dans le pilote de classe USB.

Description des plus importants fichiers:

main.asm: vecteurs de démarrage, gestionnaire d'intéruption, routine d'initialisation et boucle principale.
Note que les vecteurs de démarrage et d'intéruptions sont situés aux adresses 0x000/0x008 (pour une utilisation sans bootloader) et 0x800/0x808 (pour une utilisation avec bootloader). Il n'est pas requis de basculer entre ces deux adresses, car le bootloader ignorera de toute façon l'adresse inférieure.
usbdrv.asm: pilote USB basé sur Microchip Framework, réécrit en assembleur
usbdsc.c: descripteurs USB pour le MIDI USB
usbcls.asm: pilote de classe USB MIDI pouvant gérer jusqu'à 5 ports IO
midi.asm: gestionnaire des buffers IO pour l'interface MIDI interne
int_midi.asm: parser MIDI et interface vers usbcls.asm (USB MIDI Package Handlers)
iic.asm: routines de transferts IIC
iic_midi.asm: Interface vers usbcls.asm (USB MIDI Package Handlers)

Download

PCB data, can be viewed, modified and converted with Eagle Light
Module	Schéma	Layout	Aperçu
MBHP_USB_PIC18F4550_V1	mbhp_usb_pic18f4550.pdf	-	-
MBHP_USB_PIC18F2550_V1	mbhp_usb_pic18f2550.pdf	-	-
MBHP_USB_PIC_WITH_IIC	mbhp_usb_pic_with_iic.pdf	-	-

Firmware et Bootloader
Fichier	Taille	Description
mbhp_usb_pic_v1_1.zip	42k	firmware MBHP_USB_PIC + code source
microchip_usb_bootloader.zip	988k	Le Bootloader USB que j'ai téléchargé sur le site Microchip en 2005. Je n'ai pu le retrouver sur ce site depuis, mais je suppose qu'il y est toujours disponible, quelque part... en tout cas cette version fonctionne parfaitement!

Est-il possible de mixer une appli MIOS avec le firmware?

Non, c'est impossible à cause de conflits dans les ressources (fréquence d'horloge, pins IO alloués, zone de la RAM interne dédiées aux buffers endpoint USB). Utilisez simplement MBHP_USB_PIC comme interface MIDI indépendante, et inter-connectez les ports MIDI I/O à un module MBHP_CORE (MBHP_USB_PIC MIDI In->MBHP_CORE MIDI Out, MBHP_USB_PIC MIDI Out->MBHP_CORE MIDI In). L'utilisation d'optocoupleur est recommandée pour éviter les boucles de masses entre votre PC et votre matériel audio!

Last update: 2015-09-24