mais je te dis pas que tu dois pas le faire, l'intéret du libre est donc que tu peux le faire! Il y a des compilo pour certains DSP. Mais il te faut plus que de la bonne volont.
Par contre, j'adopte effectivement une position particulière, celle que j'avais à l'époque, je ne connais pas trop le "hack" d'un dsp qui marche bien sur une plateforme ouverte, désolé. Ma position est celle du "bring up". J'ai une brique, avec plein de connecteur autour. Et je dois coder tout ce qu'il faut pour commencer à faire en sorte qu'il me parle, puis me dise ce qui ne va pas, puis faire le traitement, ... Et pour ça il faut plein de truc:
- le compilo : bah, les compilo libres sont vraiment limité au niveau perf et support des DSP, tout simplement parce que les constructeurs cachent beaucoup d'info, les registres sont pas tous documenté,... les compilo interne sont rarement ouvert et sont très cher. TI en a libéré qque un je pense. Aussi parce que les cibles sont limités et changes trop souvent
- la connectique. Si, si, je t'assure, un DSP n'est pas un CPU généraliste où tu es assez "proche". J'ai une vision formatée parce que j'ai bosser avec et sans la board de développement. Et ton connecteur JTAG, mon ami, tu l'aimes. Car quand tu code en assembleur sans OS qui gère tes jolis exceptions et t'affiche des printf quand ça ne va pas, bref tu es tout seul devant la bete et qu'elle est dans un état indéterminé parce quelque chose à planté... bah tu fais quoi?? Les constructeurs te vendent (cher) des solutions de debug in place (RVDS par exemple http://www.bluewatersys.com/development/doc/realview/rvds/) qui sont sous forme de suite logiciel sur PC (avec un compilo, un similateur cycle accurate, un gros boitier (qui coute très cher) à connecter à ton PC et à ta board ou ton open phone (forme facteur presque final mais avec les connecteurs de debug)).
- simulateur : si si si tu en as besoin, ton algo tu te test pas sur la board directement. Tu tests s'il fonctionne sur ton simulation instruction accurate (simul les instructions), puis sur le cycle accurate (voir si ça fout pas la merde en dessous). Evidement, c'est hyper lent, donc dès que ton algo est un minimum validé et que le mec qui est chargé de faire l'injecteur de code sur le DSP l'a fait, tu le fais tourner sur le dsp. Et tu pries.
Sur un close phone (ou ton forme facteur final), tu n'as aucun des pins de debug qui sorte, ou très rarement. C'est pour ça par exemple que le téléphone OpenMoko est d'abord sorti sous une forme non terminée, pour permettre d'y connecter son PC. Sans ses pin de debug, tu te repose sur le coeur ARM (avec un linux dessus) par exemple pour récupérer l'état des registres et resetter le coeur DSP. Mais si là aussi il y a un soucis, tu es mort. Le pire? C'est qu'electropniquement c'est pas trop complexe (un microcontrolleur pour router les info). Mais tout est obfusqué donc c'est difficile.
J'ai beaucoup de repect pour des projets comme openMoko, je trouve que c'est vraiment une très bonne idée et parfaitement louable. Enfin une plateforme ouverte. Mais est ce que ça marchera....
Le probleme d'un DSP, c'est la "distance" avec le CPU. Le DSP est loin. Sans outil pour aller lui ouvrir la tete, tu as une boite noir qui a planté, et souvent ça plante sur des traitement lourds et temps réel qui ne se reproduise pas quand tu fais du pas à pas.
Attention, OpenMax IL te fourni les primitive de décodage/encodage (idct, ...) alors que OpenCL te fourni un acces direct au "kernel" de calcul (pour coder une primitive ou un traitement particulier). C'est complémentaire. Je ne sais pas si les puces actuelles permettent de faire les 2 en même temps.
Pour moi le DSP est un faux probleme. Qu'il reste fermé si on peut en changer quand bon nous semble. Et des interfaces standards sont nécessaires. Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 3.
Par contre, j'adopte effectivement une position particulière, celle que j'avais à l'époque, je ne connais pas trop le "hack" d'un dsp qui marche bien sur une plateforme ouverte, désolé. Ma position est celle du "bring up". J'ai une brique, avec plein de connecteur autour. Et je dois coder tout ce qu'il faut pour commencer à faire en sorte qu'il me parle, puis me dise ce qui ne va pas, puis faire le traitement, ... Et pour ça il faut plein de truc:
- le compilo : bah, les compilo libres sont vraiment limité au niveau perf et support des DSP, tout simplement parce que les constructeurs cachent beaucoup d'info, les registres sont pas tous documenté,... les compilo interne sont rarement ouvert et sont très cher. TI en a libéré qque un je pense. Aussi parce que les cibles sont limités et changes trop souvent
- la connectique. Si, si, je t'assure, un DSP n'est pas un CPU généraliste où tu es assez "proche". J'ai une vision formatée parce que j'ai bosser avec et sans la board de développement. Et ton connecteur JTAG, mon ami, tu l'aimes. Car quand tu code en assembleur sans OS qui gère tes jolis exceptions et t'affiche des printf quand ça ne va pas, bref tu es tout seul devant la bete et qu'elle est dans un état indéterminé parce quelque chose à planté... bah tu fais quoi?? Les constructeurs te vendent (cher) des solutions de debug in place (RVDS par exemple http://www.bluewatersys.com/development/doc/realview/rvds/) qui sont sous forme de suite logiciel sur PC (avec un compilo, un similateur cycle accurate, un gros boitier (qui coute très cher) à connecter à ton PC et à ta board ou ton open phone (forme facteur presque final mais avec les connecteurs de debug)).
- simulateur : si si si tu en as besoin, ton algo tu te test pas sur la board directement. Tu tests s'il fonctionne sur ton simulation instruction accurate (simul les instructions), puis sur le cycle accurate (voir si ça fout pas la merde en dessous). Evidement, c'est hyper lent, donc dès que ton algo est un minimum validé et que le mec qui est chargé de faire l'injecteur de code sur le DSP l'a fait, tu le fais tourner sur le dsp. Et tu pries.
Sur un close phone (ou ton forme facteur final), tu n'as aucun des pins de debug qui sorte, ou très rarement. C'est pour ça par exemple que le téléphone OpenMoko est d'abord sorti sous une forme non terminée, pour permettre d'y connecter son PC. Sans ses pin de debug, tu te repose sur le coeur ARM (avec un linux dessus) par exemple pour récupérer l'état des registres et resetter le coeur DSP. Mais si là aussi il y a un soucis, tu es mort. Le pire? C'est qu'electropniquement c'est pas trop complexe (un microcontrolleur pour router les info). Mais tout est obfusqué donc c'est difficile.
J'ai beaucoup de repect pour des projets comme openMoko, je trouve que c'est vraiment une très bonne idée et parfaitement louable. Enfin une plateforme ouverte. Mais est ce que ça marchera....
Le probleme d'un DSP, c'est la "distance" avec le CPU. Le DSP est loin. Sans outil pour aller lui ouvrir la tete, tu as une boite noir qui a planté, et souvent ça plante sur des traitement lourds et temps réel qui ne se reproduise pas quand tu fais du pas à pas.
Attention, OpenMax IL te fourni les primitive de décodage/encodage (idct, ...) alors que OpenCL te fourni un acces direct au "kernel" de calcul (pour coder une primitive ou un traitement particulier). C'est complémentaire. Je ne sais pas si les puces actuelles permettent de faire les 2 en même temps.
Pour moi le DSP est un faux probleme. Qu'il reste fermé si on peut en changer quand bon nous semble. Et des interfaces standards sont nécessaires. Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...