Librairie Pal composite pour PIC18 : Interrogation sur la norme

[cyberdalek]

Bonsoir à tous,

Je suis en train d'écrire une librairie (qui fonctionne assez bien) pour utiliser un écran PAL (via composite) avec un PIC18F (en l’occurrence un PIC18F4685 à 40Mhz soit FOSC =10) en langage C sous XC8 (et asm) et j'obtiens une résolution assez sympa (enfin pour moi ) : 136 x 112 en noir et blanc(plutot gris) (cette dernière étant doublée sur l écran pour obtenir un affichage quasi plein écran et éviter un etirement excessif des pixels horizontaux).

J'ai lu pas mal sur le format PAL, notamment le site de Rickard Guinee, martin hinner et de batsocks qui sont une mine d'informations.

Je viens vers vous car je rencontre un petit problème de compatibilité, qui chez moi ne me pose pas de soucis, mais le but étant de partager cette lib en Open source, j aurais besoin de vos lumières et de vos avis afin qu elle fonctionne correctement pour tous (Si vous désirez l'essayer, faites le moi savoir, ce sera un plaisir d'avoir des testeurs. Pour l'instant elle ne dispose que des fonctions de remplissages diverses, de tracé de pixel et de ligne,de texte, et deux fontes 8x8 un peu grosses reprises des vieux ordinateurs sinclair et Thomson ).

Donc mon problème est le suivant:

J'ai choisi le format non interlacé pour plus de simplicité, d'autant plus que je ne génère qu une faible résolution. Selon le ce que j ai saisi du format PAL, je devrais générer (peut être ai je tort je ne suis pas un pro), 312 lignes, voir 304.

Dans ces 304/312 lignes, il y aurait 287/288 lignes sûres. J ai donc des lignes en trop que je n'utilise pas (112*2=224 lignes utilisées). Au début j'ai rempli ces lignes de lignes vides (noires), afin de faire du remplissage. Cependant comme ma librairie est pilotée par interruption, je me suis dit, pourquoi ne pas supprimer ces lignes, et placer via timer le délai pour les pulses de fin de pages. Ainsi je gagne du temps cpu qui me laisse du temps pour faire d'autre choses (et accélérer donc les fonctions graphiques)

J'ai testé la méthode sur plusieurs écrans, 1 sony cathodique, un DVD portable que j ai modifié pour accepter le composite, et 2 Ecrans plats (Un noname et un sony). Cela fonctionne partout excepté sur le noname ou l'image saute.

Ce procédé est il fonctionnel sur la majorité des tvs, ou est ce l'écran noname qui a un fonctionnement normal (Certains écrans comme le lecteur DVD sont ultra permissifs)?

Par ailleurs, j ai lu plusieurs textes sur le format PAL, Sauriez-vous quelles sont le nombre de lignes réellement utilisées dans l industrie pour le pal non interlacé , car j ai vu pas mal de choses différentes un peu partout.

Vous remerciant de m'éclairer sur le sujet, je vous souhaite de passer un bon week end
-----

[cyberdalek]

Note : je n'ai pas trouvé le moyen d'éditer la discussion.

Voici une petite photo faite avec mon telephone de la librairie sur un lecteur DVD portable afin de vous donner une idée.

[invite03481543]

Hello,

c'est quoi l'intérêt de nos jours de ton appli?

[cyberdalek]

Hello,

A vrai dire, a la base c'est surtout un projet personnel qui m a permis d'apprendre l'asm pic18 et de me perfectionner avec xc8.

C'est pour moi une partie d'un autre projet que je fais par hobby (un mini ordinateur style retro a base de pics).

Après avoir porté une lib pour lcd, je me suis dit que ca pourrait etre sympa d'avoir une lib tv, d'autant plus que j'avais un dvd portable que j'avais modifié.

C'est sans pretention (je suis un debutant en programmation pic), et l'intérêt est certes moindre de nos jours vu le prix des lcds, mais je trouve ca fun (et le defi aussi) surtout sur un uc ne disposant que de 3kos de ram!

Il y a par exemple la lib tvout sur arduino, que j'ai testée et trouvée sympa (et je suis impressionné de l'utilisation fun que certains en font). J'ai vu qu'il existait également une lib pal sur mikroc, mais comme je n'y connais rien en mikroc je me suis lancé ce petit défi sur un pic que j'avais et sur lequel j'essaie de progresser en programmation.

je partage le code en open source , où ca pourra peut etre intéresser d autres bidouilleurs , histoire d'avoir une base ou d'utiliser telle quelle.

A+
Note : message envoyé de mon téléphone

[A voir en vidéo sur Futura]

[invite03481543]

MikroC reste du C ANSI, il n'y a aucune difficulté supplémentaire si tu utilises déjà XC8.
Tu partages ton code où?

[cyberdalek]

J avais répondu à ton message avec mon téléphone, apparremment ça n a pas fonctionné

MikroC reste du C ANSI, il n'y a aucune difficulté supplémentaire si tu utilises déjà XC8.
Tu partages ton code où?

Tout à fait, mais il nécessite tout de même une adaptation (timers, bibliothèques, directives etc...). Et comme mon but était de progresser dans l'exploration de XC8 que je découvre et même si cette librairie que je n'ai pas testée semble sympa (d ailleurs je me demande si elle n a pas servie de base pour TVout sur arduino), mon but était de me faire ma librairie tant par défi que d'avoir un truc qui corresponde à mes besoins .

Pour le partage, elle n'est pas encore en partage, mais le sera prochainement sur sourceforge (ou github ou autre peut importe) en licence lgpl. Il me reste à clarifier cette histoire de compatibilité, d'où ma question à l'ouverture de ce post. Cela a un impact quant au code, et à la rapidité générale de la lib. là je teste une alternative pour trouver un compromis.

Il me reste aussi quelques fonctions à implémenter : ajout d autres primitives graphiques pour les formes géométriques (cercles, triangles, boites etc..), ajout d'une fonte 5x7 en plus des 2 fontes 8x8 un peu grosses (dont une risque de disparaitre). Il faut aussi que je nettoie le code et que je rédige une petite doc.

[ranarama]

Je suis intéressé par ton chouette projet malgré que j'y connaisse rien à la base car je suis plutot branché oldies.

Après une rapide recherche google, je dirais que le pal c'est 625 lignes en interlacés standard en transmission sauf que dans ton cas : le non-interlacé ce n'est que la moitié en affichage, donc il faut que tu envoie 625/2 lignes ce qui impossible (corrige moi si je me trompe) du coup la synchro ne sera pas tout à fait à 50 HZ et je vois là une bonne raison qui pourrais expliquer le décrochage de ta tv noname.

Une idée se serais de tenter l'alternance : càd alimenter la tv de 312 lignes une fois, puis 313 lignes l'autre coup, puis 312...etc. Ce qui pourrait être vu par la noname comme du "pure 50Hz"

Bon je répète je connais peu le sujet donc pas taper ceci dit ça m’intéresse en plus j'ai commander mes petits PIC et j'ai mes deux vielles tv, un émetteur uhf, une carte d'entrée PC-TV composite, donc de quoi s'amuser avec

Je suis également intéressé sur la programmation des algos graphique. J'essayerai de trouver d'autres infos. Juste tu comptes les faire en C ou assembleur ? Moi je sais écrire un peu des deux.

Ben si tu es d'accord pour m'envoyer la lib je regarderais ça avec intérêt.

[cyberdalek]

Je suis intéressé par ton chouette projet malgré que j'y connaisse rien à la base car je suis plutot branché oldies.

Bonjour Ranaraman, je te remercie pour ton intérêt. Chouette je ne sais pas, dans la mesure où moi non plus je n'y connaissais rien à la base (Tant en programmation pic que j ai débuté il y a quelques mois que le format PAL). Si tu es branché oldies, on risque fort de s'entendre alors (La preuve en est que j'ai reprise dans mon projet la fonte des thomson MO5/TO7 et ordinateurs sinclair de l'époque! Meme si je vais devoir rajouter une fonte 5x7 car les 8x8 sont énormes sur une si faible résolution, et la fonte thomson ne rends pas super..)

Après une rapide recherche google, je dirais que le pal c'est 625 lignes en interlacés standard en transmission sauf que dans ton cas : le non-interlacé ce n'est que la moitié en affichage, donc il faut que tu envoie 625/2 lignes ce qui impossible (corrige moi si je me trompe) du coup la synchro ne sera pas tout à fait à 50 HZ et je vois là une bonne raison qui pourrais expliquer le décrochage de ta tv noname.

Une idée se serais de tenter l'alternance : càd alimenter la tv de 312 lignes une fois, puis 313 lignes l'autre coup, puis 312...etc. Ce qui pourrait être vu par la noname comme du "pure 50Hz"

Je te remercie pour ces infos. Effectivement, les 312 lignes, sont un peu dures à tenir, j'ai essayé plusieurs compositions : 304 (Dans la rubrique tricks du site batsocks) et même 287 que j arrive à faire fonctionner sur le noname sans soucis en affichant des lignes vides (noires) pour combler les lignes qui ne sont pas affichées.

Cependant mon problème, est que générer ces lignes vides me prends du cpu. Mon pic18 à 40 mhz, qui a en fait une fréquence de 10 mhz (4 cycles sur les pics pour une instruction contrairement aux avr qui équipent par exemple les arduinos), est assez limité. Mon idée a donc été de supprimer ces lignes, par un signal vide (absence de d émission de signal), redonner le temps au cpu, puis de reprendre en fin de page par les pulsations de fin de pages (3 lignes de 64us).

Alors que beaucoup de TVS ignorent cette absence de signal et attendent le signal de fin, j ai l impression que cet écran capte le décrochage de signal et qu il essaie de se resynchroniser à partir de ce moment. J'ignore si c'est un comportement normal, car je n'ai rien trouvé à ce sujet. Certes l idée est saugrenue, mais les gains en vitesse sont énormes d'où mon intérêt pour cette petite "triche"

Bon je répète je connais peu le sujet donc pas taper ceci dit ça m’intéresse en plus j'ai commander mes petits PIC et j'ai mes deux vielles tv, un émetteur uhf, une carte d'entrée PC-TV composite, donc de quoi s'amuser avec

Je suis également intéressé sur la programmation des algos graphique. J'essayerai de trouver d'autres infos. Juste tu comptes les faire en C ou assembleur ? Moi je sais écrire un peu des deux.

Ben si tu es d'accord pour m'envoyer la lib je regarderais ça avec intérêt.

Ce serait super d'avoir un avis et que ça puisse en amuser d'autres . Pour les algos, ils sont assez simples à vrai dire, j'ai implémenté en C les pixels, l'algorithme de Bresenham que j ai très peu modifié pour le tracé des lignes, les fonctions clear,fill, revert, une commande drawchar, set cursor, et print. Me reste donc très peu de primitives de bases comme les cercles, triangles, et bitmap 8 bits (qui sera très rapide, car le framebuffer est lui même un bitmap.

Au passage j ai du recâbler le pic, et réécrire la lib, car au début j'étais en lsb et les bitmaps étaient inversés par rapport à ce qu on trouve généralement, ça fonctionnait bien, mais j ai préféré ne pas m éloigner des standards (et avoir des bitmaps comme dans les années 80 sur les ordinateurs familiaux ) d autant plus que c'était plus logique d avoir des pixels linéaires.

Une idée marrante à laquelle j'ai pensé et qui serait optionnelle serait de rajouter des tableaux de sinus cos etc et de réaliser des fonctions pour le rendu 3D en fil de fer, inutile mais fun

Si tu as des idées de fonctions sympathiques et/ou utiles, et si tu veux les rajouter ce serait cool .

Je ne sais pas ce qui tu as pris comme pics, pour ma part j utilises des pics 18F4685 car je commence à les connaitre, et qu ils ont une mémoire flash assez importante de 96 ko (mais pas d USB).

Une fois la lib terminée mon but est d'y ajouter une communication SPI et/ou série pour pouvoir l utiliser comme une pseudo carte graphique avec un autre pic, un arduino ou autre.

Je finis mes tests sur les lignes, et si tu es d accord, je pourrais t'envoyer la lib je pense d'ici quelques jours (ou la mettre sur sourceforge). Pour la connectique, il faut dont un pic 5V, 3 résistances d environ 1k, 470 ohms et une de 75 ohms (cette dernière pourrait être facultative et son absence pourrait rendre le blanc plus lumineux en contrepartie peut être d une compatibilité moindre).

A+

Note : J ai a moitié répondu à ta question, j ai codé la plupart de la lib en C xc8 (Le template C des lignes est lui généré sur pc avec Gcc), par contre l'affichage des lignes ou le timing est très important est lui codé en asm, ce qui m a permis de placer au mieux les instructions pour réduire le nombre de cycles. C est la première fois que je codais en asm sur Pic, j ai appris en regardant le datasheet, et le code généré par le compilateur. Donc je suis plus à l'aise avec le C, mais si es à l aise avec l'ASM et si tu veux écrire des functions dans ce langage, you are welcome

[RISC]

Salut,

Si tu es limité en performances sur les PIC18 classiques, tu peux utiliser les PIC18FxxKyy.
Par exemple le PIC18F46K80 tourne à 64MHz (16 MIPS) c'est à dire 60% plus rapide que son prédécesseur le PIC18F4685 et il est je pense compatible 100% coté hard et 95% coté soft.

a+

[ranarama]

Bonjour cyberdalek (mieux vaut tard que jamais )

Oui j'aime aussi bien les vieux nordis ils sont trop mignons je trouve le Z80 et les machines associées très intéressantes d'ailleurs il y a un certaine nombre de ressources qui pourraient s'adapter (au niveau format graphique) au pic, je pense à : la Gameboy avec son écran N/B et ses 160×144 pixels

=> Des petites fontes textes et scrolltext bien mignonnes trouvable sur le net (celles utilisées dans certains RPG par exemple sont très jolis) ainsi que des tableaux de sprites prêt à être réutilisés j'en ai mm peut être déjà faudrait que je fouille dans mon ordi... J'aimerais vraiment voir le résultat sur une meilleure définition Pal même "trické"

J'ai lu la page de trick vidéo PAL que tu avais cité, très intéressante et je trouve ça super que tu es réussi à le mettre en œuvre aussi rapidement. ça me donne bien envie de faire la même chose d’ailleurs, pas que j'aime tant la triche quoique… surtout la qualité d'affichage des tv à tube avec leur anti aliasing naturel qui réchauffe l'image comparé à la relative froideur des CRD, d'ailleurs ma principale TV est une grosse télé de 70 cm de 50kg ! assez récente d'ailleurs j'ai du matos en genie elec juste un oscillo normal pas encore numérique mais cela ne saurait tarder, combien de temps vais-je encore résister à ça ?

http://www.batronix.com/shop/oscillo...l-DS1052E.html

Pour le souci de décrochage, je viens de comprendre en fait c’est plus un problème de puissance de calcul que de signal/synchro finalement. C’est vrai que point fort des pics n'est pas la puissance : 4 cycles par instructions, 8 parfois sur certaines, voire bien plus pour les maths. J’ai commencé l’assembleur y a 10 ans Intel, Motorola, Microchip...
J’avais repris il y a deux ans en assembleur sur le Pic 16F887 et là je voudrais m’y remettre sur un modèle supérieur le 18F4553 à 48Mhz et seulement 12Ko ( T_T) je l’ai commandé en échantillon gratuit (je pense que tu connais l’astuce) à la base car ces capacité USB m’intéressent, mais si en plus il peut m’afficher des textes sur une TV c’est encore mieux, penses-tu qu’il a le bon profil ? Sinon je recommande comme toi dans 15 jours ce sera bcp + simple, c gratuit alors autant en profiter à donf. Sinon tu as connecté quoi, un quartz de 10 Mhz dont la freq est x4 grâce à la PLL ?

Une solution serait de prendre un µC plus haut de gamme ou comme tu l’as un peu évoqué la topologie de type PC + carte graphique c’est-à-dire utilisé un second pic comme carte vidéo et ne servant qu’à cela çad réceptionnant des infos type « mémoires vidéos » (donc la définition de l’écran puis l’état logique des n pixels tout simplement). Du coup ton 1er pics serait un petit peu soulagé et aurai un sursaut de « puissance » pour ses programmes. Le choix de la liaison entre les deux : // ou série … faut voir.

Au niveau algo En moteur 2D les meilleures algos assembleur Intel 8bits vu sont écrit par M. Abrash tu le trouves ici c’est « open source » Ça débute par fameux Bresenham et des optimisation maison pour finir loin très loin jusqu’au moteur de Doom. L’adaptation devrait être aisée (ça reste du 8 bits) sur les algos simple et vraiment utiles : comme la ligne à la base de tout le reste .

http://www.phatcode.net/res/224/files/html/

J’avais corrigé un moteur 3D rapide y a longtemps et en assembleur Motorola 16 bits donc ça pourrais s’adapter à du pic, là il y a du boulot mais c'est le genre de projet qui mérite d'être mené à terme ^^

Tableaux de sinus cos oui c’est vraiment amusant, comme premier programme 3D j'avais fait un ciel étoilé animé genre écran de veille Windows : une simple conversion polaire => rectangulaire, tu décrémentes la distance à l’origine (polaire) c simple efficace
Bon tout ça pour dire que nous avons quelques points communs alors on essaye de collaborer sur des petits projets si tu veux

Bonne fin de soirée et à bientôt

[jiherve]

Bonsoir,
Pour un téléviseur conçu pour de l'entrelacé il faut absolument que les synchro le soient, ensuite concernant le contenu vidéo il est possible d'envoyer deux fois la même chose.
En PAL il faut une base de temps tournant à 32µS (2xFh) et compter 625 demi lignes par trame (il y en a deux par image) cela entrelacera tout seul.
JR

[DAUDET78]

et compter 625 demi lignes par trame (il y en a deux par image) cela entrelacera tout seul.

Euh ... euh
312,5 lignes par trame à 50hz

[jiherve]

Re
625 demi lignes = 312,5 lignes ou bien je mange mon chapeau!
C'est comme çà que sont fait tout les générateurs de synchro, domaine que je pratique depuis 40 ans et plus encore.
JR

[DAUDET78]

625 demi lignes = 312,5 lignes ou bien je mange mon chapeau!

Oui , mais pas

compter 625 demi lignes

Mange ton chapeau !

[jiherve]

Re
ben non car compter 625 demi lignes dont la durée est de 32µS cela fait 625x32µS = 20ms => 50Hz = une trame = 1/2 image.
Tu es fatigué ce soir!
JR

[DAUDET78]

On ne fait JAMAIS des demi-lignes ! Mais une ligne sur deux ....

[jiherve]

Re
Désolé de te contredire mais pour entrelacer on compte des demi lignes, et bien sur on affiche 312 lignes entières, sauf la première demi ligne de la trame la plus haute (paire impaire est ambigu) et la dernière demi de la trame la plus basse .
http://www.google.fr/imgres?imgurl=h...Q9QEwAQ&dur=12
JR

[DAUDET78]

Tu jongles sur les mots pour réparer un lapsus ....

[jiherve]

re
trop courtes ces 5min!
la suite
L'entrelacement provient du fait que sur un CRT cela induit un déphasage de 32 µS entre la dent de scie trame et la dent de scie lignes et que donc le spot n'est pas au même endroit en vertical en début de ligne.
A l'origine, avec les tubes de prise de vue , vidicon, orthicon, nuvicon, la capture d'image était aussi entrelacée, donc on ne traitait pas une ligne sur 2, cela est apparu avec les capteurs progressifs et surtout les images de synthèse.
Sur un moniteur LCD ou Plasma pour une vidéo PAL ou NTSC on laisse tomber les deux demi lignes et dans le cas le plus simple(écran dont la résolution serait de 575/576 lignes) comme le bayage est progressif (625L en 20ms) chaque trame est dupliquée, la première trame est affichée (1,2)(3,4)....(286,287) la seconde sur (2,3)(4,5)...(287,288)en supposant là un affichage sur 576 lignes et c'est le cerveau qui fait le boulot la résolution verticale n'est pas 576L , c'est le mode trame image(bob) ou bien on mémorise toute l'image et on affiche de 1 à 287 : (1)(2)(3)... (285)(286)(287) mode image image (weave), résolution 575 lignes mais cisaillement lors de mouvement d'image horizontaux si la source est un capteur entrelacé.
http://www.100fps.com/
Dans le cas des écrans actuels qui ont une résolution verticale bien supérieure on a recours à un resizing et à des méthodes de desentrelacement bien plus savantes.
JR

[cyberdalek]

Bonjour à tous, et merci pour vos réponses. Désolé je n'ai pas pu me connecter comme je le voulais en début de semaine.

Je viens je pense de résoudre mon problème, en explosant mon code et en réécrivant entièrement l'interruption servant à l'affichage.

J'ai du coup choisi de procéder différemment. En l’occurrence plutôt que de provoquer une absence de signal, durant les lignes non utilisées, ou d’écrire une ligne entière très consommatrice de cpu, j'ai rusé . Je me suis calé sur le front porch, et je ne génère plus que les pulses de Front proch (avant la fin de la ligne) suivies du début de la nouvelle ligne.Résultat, la TV voit une ligne noire correcte, et je récupère les 52 us pour du temps cpu.

Comme je viens de tout réécrire, j'ai encore quelques modifs à faire avant de la partager, mais le plus gros est fait.

Note je n'affiche pas les 312 lignes, juste un petit moins (mes tests oscillent entre 304 et 310), je ne vois pas de différence notable. En dessous, l'image est coupée, mais à vérifier.


@Ranarama

Oui j'aime aussi bien les vieux nordis ils sont trop mignons je trouve le Z80 et les machines associées très intéressantes d'ailleurs il y a un certaine nombre de ressources qui pourraient s'adapter (au niveau format graphique) au pic, je pense à : la Gameboy avec son écran N/B et ses 160×144 pixels

=> Des petites fontes textes et scrolltext bien mignonnes trouvable sur le net (celles utilisées dans certains RPG par exemple sont très jolis) ainsi que des tableaux de sprites prêt à être réutilisés j'en ai mm peut être déjà faudrait que je fouille dans mon ordi... J'aimerais vraiment voir le résultat sur une meilleure définition Pal même "trické"

J'ai lu la page de trick vidéo PAL que tu avais cité, très intéressante et je trouve ça super que tu es réussi à le mettre en œuvre aussi rapidement. ça me donne bien envie de faire la même chose d’ailleurs, pas que j'aime tant la triche quoique… surtout la qualité d'affichage des tv à tube avec leur anti aliasing naturel qui réchauffe l'image comparé à la relative froideur des CRD, d'ailleurs ma principale TV est une grosse télé de 70 cm de 50kg ! assez récente d'ailleurs j'ai du matos en genie elec juste un oscillo normal pas encore numérique mais cela ne saurait tarder, combien de temps vais-je encore résister à ça ?

Moi historiquement j'étais plus 6809, mais j’apprécie les z80 également .Quant à la Gameboy, J'ai porté la librairie d'Adafruit pour les écrans nokia 3310(en y faisant quelques améliorations) pour les pics 18 (Pinguino quand j ai débuté, puis XC8 que j'ai optimisée puis ajouté le support d eeprom spi pour les fontes notamment) dans le but de me faire une petite console portable. Le hic comparé à la Gameboy (résolution plus élevée et niveau de gris) c est que le blanc est une absence de couleur. J'ai testé avec les sprites de megaman convertis en bitmap noir et blanc, ça fonctionne nickel, mais pour faire des décors, c est plus compliqué (mais pas impossible).

C'est vrai que je suis bluffé par cet anti aliasing des télés cathodiques, néanmoins les crt mise à part leurs marches d escaliers (avec de faibles résolutions comme la librairie pal) semblent plus nets

Pour le souci de décrochage, je viens de comprendre en fait c’est plus un problème de puissance de calcul que de signal/synchro finalement. C’est vrai que point fort des pics n'est pas la puissance : 4 cycles par instructions, 8 parfois sur certaines, voire bien plus pour les maths. J’ai commencé l’assembleur y a 10 ans Intel, Motorola, Microchip...
J’avais repris il y a deux ans en assembleur sur le Pic 16F887 et là je voudrais m’y remettre sur un modèle supérieur le 18F4553 à 48Mhz et seulement 12Ko ( T_T) je l’ai commandé en échantillon gratuit (je pense que tu connais l’astuce) à la base car ces capacité USB m’intéressent, mais si en plus il peut m’afficher des textes sur une TV c’est encore mieux, penses-tu qu’il a le bon profil ? Sinon je recommande comme toi dans 15 jours ce sera bcp + simple, c gratuit alors autant en profiter à donf. Sinon tu as connecté quoi, un quartz de 10 Mhz dont la freq est x4 grâce à la PLL ?

Une solution serait de prendre un µC plus haut de gamme ou comme tu l’as un peu évoqué la topologie de type PC + carte graphique c’est-à-dire utilisé un second pic comme carte vidéo et ne servant qu’à cela çad réceptionnant des infos type « mémoires vidéos » (donc la définition de l’écran puis l’état logique des n pixels tout simplement). Du coup ton 1er pics serait un petit peu soulagé et aurai un sursaut de « puissance » pour ses programmes. Le choix de la liaison entre les deux : // ou série … faut voir.

Au niveau algo En moteur 2D les meilleures algos assembleur Intel 8bits vu sont écrit par M. Abrash tu le trouves ici c’est « open source » Ça débute par fameux Bresenham et des optimisation maison pour finir loin très loin jusqu’au moteur de Doom. L’adaptation devrait être aisée (ça reste du 8 bits) sur les algos simple et vraiment utiles : comme la ligne à la base de tout le reste .

http://www.phatcode.net/res/224/files/html/

Merci pour le lien, enregistré dans mes favoris.

Malheureusement, je ne pense pas que ton PIC18F4553 pourra stocker la librairie .

Voii sa taille à l 'heure actuelle :

 Program space        used  5A61h ( 23137) of 18000h bytes   ( 23.5%)
*Note j ai mis au chaud 200 octets pour mon bootloader 
Data space           used   7A5h (  1957) of   D00h bytes   ( 58.8%) 
  

Donc la lib ne pourra pas rentrer dessus (je l ai compilée avec l option space au lieu de vitesse). J'ai choisi un pic4685, mais libre à toi d'en sampler un autre avec plus de ram (Environ 3ko car l array de l écran fait 17 *112 soit 1904 octets) et de flash, je ne fais que du code pic18 de base, et je désactive tout ce qui ne me sert pas. Note au niveaux des pins, j'utilise l’intégralité du port B (Je fais une rotation sur ce dernier pour afficher le pixel) même si une seule pin est utilisée, et une pin au choix.

comme le dit Risc, tu as des nouveaux pics plus performants. J utilise effectivement un quartz de 10 Mhz avec la pll (Soit 40 Mhz mais fosc 10). si tu voulais utiliser un autre pic, et une autre fréquence il n'y as pas de soucis, néanmoins il faudra t 'amuser à recalculer les cycles

Ca faisait un bail que je n avais pas fait d assembleur, ça remonte au temps des motorola 8/16bits et du début du 386. Pour les histoires de puissances, quand j ai commencé à m y intéresser avec mon arduino, je me suis dit pourquoi seulement 16mhz alors ques pics c 'est 40-48mhz, mauvais choix

Une solution serait de prendre un µC plus haut de gamme ou comme tu l’as un peu évoqué la topologie de type PC + carte graphique c’est-à-dire utilisé un second pic comme carte vidéo et ne servant qu’à cela çad réceptionnant des infos type « mémoires vidéos » (donc la définition de l’écran puis l’état logique des n pixels tout simplement). Du coup ton 1er pics serait un petit peu soulagé et aurai un sursaut de « puissance » pour ses programmes. Le choix de la liaison entre les deux : // ou série … faut voir.

Au niveau algo En moteur 2D les meilleures algos assembleur Intel 8bits vu sont écrit par M. Abrash tu le trouves ici c’est « open source » Ça débute par fameux Bresenham et des optimisation maison pour finir loin très loin jusqu’au moteur de Doom. L’adaptation devrait être aisée (ça reste du 8 bits) sur les algos simple et vraiment utiles : comme la ligne à la base de tout le reste .

http://www.phatcode.net/res/224/files/html/

J’avais corrigé un moteur 3D rapide y a longtemps et en assembleur Motorola 16 bits donc ça pourrais s’adapter à du pic, là il y a du boulot mais c'est le genre de projet qui mérite d'être mené à terme ^^

Tableaux de sinus cos oui c’est vraiment amusant, comme premier programme 3D j'avais fait un ciel étoilé animé genre écran de veille Windows : une simple conversion polaire => rectangulaire, tu décrémentes la distance à l’origine (polaire) c simple efficace
Bon tout ça pour dire que nous avons quelques points communs alors on essaye de collaborer sur des petits projets si tu veux

Bonne fin de soirée et à bientôt

Actuellement, je teste sur une carte maison avec deux pics, et le but justement de ma lib à la base et de ne me servir du deuxième pic que comme pseudo carte graphique pour le premier (et peut etre autre chose à voir) . D'ailleur la lib consomme des ressources, et de la RAM, donc a moins de faire de petits projets, ça limite pas mal. un des truc aussi qui pourrait etre sympa est de l utiliser avec des arduino, des arms etc et avoir le même écran pour toutes ces petites cartes

le problème des moteurs 3D et du pics, c'est la limitation tant mémoire que cpu Aussi bien la 3D fil de fer pourrait passer mais le reste malheureusement, d'autant plus qu'avec du noir et blanc ce ne serait pas terrible. Quoique j'ai vu un projet super fun, un OutRun sur arduino http://www.youtube.com/watch?v=gk1YBu-7jXo

Pour la question de collaborer sur des projets, ce sera avec plaisir. En fait pour l'instant j'essaie de réinventer la roue, à faire un mini rétro computer à base de deux pics18 sur une carte mère dont cette lib est issue

Par contre pour la lib, comme je viens de casser le code, et que je manque un peu de temps, je vais essayer d accélérer les choses pour qu elle soit dispo rapidement afin que d autres puissent s'amuser avec

A bientôt
@RISC

Salut,

Si tu es limité en performances sur les PIC18 classiques, tu peux utiliser les PIC18FxxKyy.
Par exemple le PIC18F46K80 tourne à 64MHz (16 MIPS) c'est à dire 60% plus rapide que son prédécesseur le PIC18F4685 et il est je pense compatible 100% coté hard et 95% coté soft.

a+

Salut et merci, je ne connaissais pas ces pics. malheureusement j ai un stock de pic18F4685 à utiliser, mais je note pour l'avenir . Par contre je me demande si il ne serait pas plus judicieux de passer à du pic32 pour mes projets, du moins ceux qui existent en DIP, qui me procureraient un peu plus de puissance?

@JIHERVE et @DAUDET78

Bonjour et merci, je ne rentrerais pas dans votre débat, n'ayant pas les compétences sur le sujet, il y a encore quelques temps j ignorais à quoi ressemblait un signal pal. Par contre niveau ligne, je suis en train de faire différents test en non entrelacé, et je dois reconnaître que je reste dubitatif quand au nombre de lignes. Au dessus de 304 lignes, j'ai l'impression que les téléviseurs, acceptent tout du moment qu'on reste en dessous des 312 lignes. Peut être ai je tort? que préconisez vous? sur le batsock il conseille d utiliser 304 lignes sur le fake progressive.

Bonne soirée