Module Ethernet

[blackbird]

Salut,

oui moi aussi je suis le projet, je suis juste un peu paumé dans la prog des pic et les registres!

Pour moi, remplacez juste le "un peu " par "complètement" mais sinon on suit !

A+

BlackBird

[xiantia]

Bien ben y'a du monde en fait

Alors étape 6, réponse au ping fait a 70% ...

Je vais utiliser le DMA interne du module (jamais fait) pour le transfert de données ..... Theoriquement ça va plus vite !

Bye Yannick

[shrad]

je pense que les PIC ont du DMA aussi non? mais je sais pas quelle version...

moi il faut que je m'y remette aussi... j'ai un module DDS avec lequel je voulais faire un generateur de fonction avec test de drivers de diodes USB

[xiantia]

re :

J'ai fait un petit test sur le temps de réponse du PIC par rapport au HC11 sur les requêtes ARP.

Le HC11 répondait en 30/40 ms à 4.915 Mhz
Le PIC avec une nouvelle gestion de cette trame répond en 20ms à 4.00 Mhz ce qui fait 16ms pour du 4.915Mhz, soit un gain de 2 à 3 !

Pourtant le PIC qui ne possède que des instructions réduites (RISC) doit tout de même pourvoir faire des additions et autre opérations en 16bits !
ce qui prend du temps.

Bye Yannick

[shrad]

==> PIC24JF

cout moindre, puissance max, 16-bit

[xiantia]

Petit retour,

alors dans mon précédant poste le disais que le HC 11 repondé en 30/40ms sur une requete ARP et le PIC en 20 ms( vu sous WireShark)
J'ai regardé sous le debuger de MPLAB le temps de gestion de la réponse et il me dit 16ms, ou sont donc passé les 4 ms !!!
J'ai donc refait les tests avec cette fois plus de précisions et la j'ai bien 16ms de moyen vu avec WireShark.

J'ai modifier le code pour qu'il soit plus rapide (ce qui ne veut pas dire qu'il est plus compact !!),
j'arrive à gagner environ 5ms soit une réponse à 10ms (vue sous debuger ) toujours avec le quartz a 4Mhz, cela reste tout de même 3 à 4 fois plus rapide
que le HC11 et avec un quartz moins rapide.

Cela ouvre de belles perspectives pour la suite. Par contre je commence à être un peut à l’étroit au niveau mémoire flash.
Je vais donc passé sur le petit frère du 16f84, ... le 16f877.

Oui Shrad pas de pb si j'arrive a avoir des performances au alentour de 25Kpps avec je passe sur du PIC plus puissant, mais en DIP !! pas de truc tout
petit, j'ai de gros doigt

Bye à tous et tous ce qui suivent ...

Yannick

[xiantia]

Petit retour,

alors dans mon précédant poste le disais que le HC 11 repondé en 30/40ms sur une requete ARP et le PIC en 20 ms( vu sous WireShark)
J'ai regardé sous le debuger de MPLAB le temps de gestion de la réponse et il me dit 16ms, ou sont donc passé les 4 ms !!!
J'ai donc refait les tests avec cette fois plus de précisions et la j'ai bien 16ms de moyen vu avec WireShark.

J'ai modifier le code pour qu'il soit plus rapide (ce qui ne veut pas dire qu'il est plus compact !!),
j'arrive à gagner environ 5ms soit une réponse à 10ms (vue sous debuger ) toujours avec le quartz a 4Mhz, cela reste tout de même 3 à 4 fois plus rapide
que le HC11 et avec un quartz moins rapide.

Cela ouvre de belles perspectives pour la suite. Par contre je commence à être un peut à l’étroit au niveau mémoire flash.
Je vais donc passé sur le petit frère du 16f84, ... le 16f877.

Oui Shrad pas de pb si j'arrive a avoir des performances au alentour de 25Kpps avec je passe sur du PIC plus puissant, mais en DIP !! pas de truc tout
petit, j'ai de gros doigt

Bye à tous et tous ce qui suivent ...

Yannick

Ps: je ne vois plus mon ami ProgramFiles ... si vous avez des nouvelles ...

[xiantia]

Oupps me suis Cité au lieu d'editer !

re bye

[xiantia]

Bien étape 6 ok, le module répond au ping :

64 bytes from 192.168.1.33: icmp_req=710 ttl=64 time=19.0 ms
64 bytes from 192.168.1.33: icmp_req=711 ttl=64 time=19.5 ms
64 bytes from 192.168.1.33: icmp_req=712 ttl=64 time=19.5 ms
64 bytes from 192.168.1.33: icmp_req=713 ttl=64 time=19.5 ms


Pas trop mal pour un PIC à 4Mhz comparé au 28ms du HC11 en 4.915Mhz, toujours un petit gain en vitesse.

Prochaine étape réception des données ILDA ....

Bye Yannick

[shrad]

joli travail!

tu peux nous implementer une regulation PID avec un pic 12F et un petit pont en H ?

ca serait top pour les peltiers car un IC de ce genre coute une vingtaine d'euros sans les composants autour... ^^

hate de voir ce que tu peux sortir en ILDA... ce qui me fais le plus peur c'est le DAC en lui meme, est-ce que tu comptes utiliser un DAC externe ou faire autrement?

si je puis me permettre, je pense que la facon la plus aisee de le faire en 8 bits serait d'utiliser un port complet pour la facilite de copie du registre, et de sortir en R/2R... mais il faut alors 5 ports de 8 bits complets... ou alors un registre a decalage et des latch, mais ca deviens gros...

ce qui me fais peur c'est de devoir multiplier les usages de l'I2C a plusieurs peripheriques, ca va multiplier ta latence par le nombre de periph...

[xiantia]

joli travail!

tu peux nous implementer une regulation PID avec un pic 12F et un petit pont en H ?

ca serait top pour les peltiers car un IC de ce genre coute une vingtaine d'euros sans les composants autour... ^^

hate de voir ce que tu peux sortir en ILDA... ce qui me fais le plus peur c'est le DAC en lui meme, est-ce que tu comptes utiliser un DAC externe ou faire autrement?

si je puis me permettre, je pense que la facon la plus aisee de le faire en 8 bits serait d'utiliser un port complet pour la facilite de copie du registre, et de sortir en R/2R... mais il faut alors 5 ports de 8 bits complets... ou alors un registre a decalage et des latch, mais ca deviens gros...

ce qui me fais peur c'est de devoir multiplier les usages de l'I2C a plusieurs périphériques, ca va multiplier ta latence par le nombre de periph...

Re :

- Pour le PID il faut un µP qui peut faire une multiplication 8bit en flottant a cause des Ki, Kp et Kd, j'ai eu ce genre de problème avec le HC11 lors d'un test en PID numérique. de plus le µP doit avoir au moins un entré analogique, je sais pas si le 12F a ce genre d'entrée.


- Pour la partie DAC effectivement une sortie direct en 8 bits est plus rapide que du SPI ou autre.
Mes DAC sont des dac 16 bits série en flow continu, c'est a dire qu'il lit les 16 bits et converti en analogique sur DAC1 et les 16 bits suivant sur DAC2, puis les 16 bits suivant sur DAC1, ..... (un coup DAC1 un coup DAC2) et cela sans op-code ou adresse ...

- Les réseau R2/R fonctionne très bien et ne coûte rien, sauf qu'il faut toujours les bit // pour la sortie (test fait dans l'un de mes premier post avec le HC11)

Bye Yannick

[xiantia]

Petit re:

Le system de transfert DMA et le calcul du CRC des trames réseaux sont maintenant gérés par le module (fonction interne) et fonctionnels

By Yannick

[xiantia]

Bien, vu que la place commence à être épuisé dans le PIC , je me suis donc mis à effectuer un test des DAC 16 bits.
Leurs contrôles restent très simple par sélection du boîtier et envois des 16 bits. Ben ça marche pas
Il doit y avoir une erreurs tellement grosse que je la vois pas ....


Bye Yannick

[julienlev]

c'est souvent les trucs les plus simples qui merdent!

[xiantia]

Oui, après avoir géré le module Ethernet beaucoup plus compliqué, c'est le(s) dac qui veux pas !

Bye Yannick

[shrad]

est-ce que tu ne dois pas raccorder une reference de tension externe? ou initialiser les DACs avec une trame de config?

[xiantia]

Justement non, les dac n'ont pas de config, juste une sorte de chip select pour le dac 1 ou 2, puis envois des 16 bits. Pour la référence, non plus, c'est eux qui génère la ref a 0.5 * Vcc, comme cela il sont directement compatible avec un AOP en soustracteur pour avoir +/-2.5V en sortie au lieu de 0 a 5 V par exemple.
D’ailleurs en disant ça, c'est pas des volts mais un générateur de courant interne au DAC ... il doit me manquer une tite résistance sur la sortie ...


Bye Yannick

[shrad]

=> ampli transconductance (c'est bien celui la?) enfin, un convertisseur courant->tension quoi

[xiantia]

Mouai ok , j'avais lu le datasheet un peut vite lorsque j'ai choisi les DAC, en fait il a un timing un peut chiant pour la sélection dac1 / dac2.

On retrouve le dernier bit d'un mot après changement de la voie. pas simple à expliquer, mais en gros on dit "attention on change de voie" juste après ce bit.
On a déjà changé de voie alors que le dernier bit n'est pas encore envoyé, c'est pas très logique et il faut surtout faire gaffe au diagram de timing pour le voire.

Une autre astuce du datasheet "The most significant bit (bit 1) must always be first.", pour moi le MSB = bit 15 ? donc on envois quoi le bit 1 en premier donc LSB ou le MSB qui est le bit 15 ?

De toute façon faudra bien qu'il crack !

Bye Yannick

[xiantia]

De toute façon faudra bien qu'il crack !

Bon ben c'est les dac qui ont gagnés !! j'arrive sur à les faire tourner en 16 bits, seulement en 9 bits !! 512 valeurs après le dac revient à 0.
J'ai demandé de l'aide sur le net et les réponses sont pas très claire.

Je pense donc passer en dac 8 bit // (plus rapide et plus simple à piloter).

J'attend mon programmateur de PIC pour implémenter toute la gestion du dac en Ethernet .... à suivre.

Bye Yannick.

[shrad]

hmm je pense que 8 bits c'est peu... est-ce que tu n'as pas un efaut de soudure? ca a l'air d'etre un truc du genre seulement les 9 premiers bits passent... ou un probleme de vitesse serielle?

[xiantia]

Salut Shrad:

Les soudures, ben y'en a pas, plaque d’essai.
Le problème sérielle, c'est moi qui génère le clock, donc pas de problème de ce coté. testé sous simulateur MPLAB, sur pic et sur 68HC11, même problème.

J'ai donc envoyé 7 bits avant le MSB (sorte de dummy bit) affin d'effectuer un décalage, et la le dac sorte bien une tension de 1.8V a 3.8v et les 16 bits de données sont bien pris en compte cette fois !!! Mais bon y'a pas de logique au problème, puis 16 + 7 bits ça fait 23 bits même pas 24 !!
De plus ça me fait 7 tops en plus par dac, donc perte encore en vitesse lors de l’échange.

Je sent que je vais sortir mes vieux registres à décalages et faire péter des bon vieux dac DAC(0800) // 8 bits (2 par canal) soit 16 bits ! ou du R2R direct.

Bye Yannick

[shrad]

hmm les plaques d'essais sont bourrees de capacites parasites, est-ce que tu vois les 16 bit sur une trame a l'oscillo?

rien a faire, pour ce genre de choses, je pense qu'un DAC parallele serait plus performant (meme un R/2R)

EDIT

si tu veux je vends une carte explorer 16 de microchip avec deux ou trois modules PIM (pic 16 bit et 32 bit 100 broches)

avec ce genre de choses tu peux developper tout ce que tu desires et passer par apres a un PIC de la meme serie mais ne contenant que les peripheriques que tu as utilise sur son grand frere... c'est en etat quasi neuf et la qualite est au rendez-vous (c'est un modele qui n'est pas obsolete pour lequel tu peux trouver des modules facilement, avec programmateur integre)

[xiantia]

re :

Ben je vient de recevoir mon programmateur de PIC, il marche nickel en machine virtuelle.

Donc passage en 16F877A de la gestion de l'Ethernet, et comme il a plusieurs port 8 bits je vais voir pour des dac // ou en R2R.

Bye Yannick

La liste de µP supportés, y'a de quoi faire :

‘LF’ versions of all devices are also supported
8 Pin: PIC10F200, PIC10F202, PIC10F204, PIC10F206, PIC10F220, PIC10F222, PIC12F508, PIC12F509, PIC12F510, PIC12F617, PIC12F519, PIC12F609, PIC12F615, PIC12F629, PIC12F635, PIC12F675, PIC12F679, PIC12F683, PIC12F1822, PIC12F1840
14 Pin: PIC16F505, PIC16F506, PIC16F526, PIC16F610, PIC16F616, PIC16F630, PIC16F636, PIC16F676, PIC16F684, PIC16F688, PIC16F1823, PIC16F1824, PIC16F1825
18 Pin: PIC16F54, PIC16F84A, PIC16F87, PIC16F88, PIC16F627, PIC16F627A, PIC16F628, PIC16F628A, PIC16F648A, PIC16F716, PIC16F818, PIC16F819, PIC16F1826, PIC16F1827, PIC18F1220, PIC18F1230, PIC18F1320, PIC18F1330, PIC16F1847
20 Pin: PIC16F631, PIC16F639, PIC16F677, PIC16F685, PIC16F687, PIC16F689, PIC16F690, PIC16F720, PIC16F721, PIC16F785, PIC16F1828, PIC16F1829, PIC18F13K22, PIC18F13K50, PIC18F14K22, PIC18F14K50, PIC18F13K22, PIC18F13K50, PIC18F14K22, PIC18F14K50
28 Pin: PIC16F57, PIC16F72, PIC16F73, PIC16F76, PIC16F722, PIC16F722A, PIC16F723, PIC16F723A, PIC16F726, PIC16F737, PIC16F767, PIC16F870, PIC16F872, PIC16F873, PIC16F873A, PIC16F876, PIC16F876A, PIC16F882, PIC16F883, PIC16F886, PIC16F913, PIC16F916, PIC16F1516, PIC16F1518, PIC16F1782, PIC16F1783, PIC16F1933, PIC16F1936, PIC16F1938, PIC16LF1902, PIC16LF1903, PIC16LF1906, PIC18F242, PIC18F252, PIC18F248, PIC18F258, PIC18F2220, PIC18F2221, PIC18F2320, PIC18F2321, PIC18F2331, PIC18F2410, PIC18F2420, PIC18F2423, PIC18F2431, PIC18F2450, PIC18F2455, PIC18F2458, PIC18F2480, PIC18F2510, PIC18F2515, PIC18F2520, PIC18F2523, PIC18F2525, PIC18F2550, PIC18F2553, PIC18F2580, PIC18F2585, PIC18F2610, PIC18F2620, PIC18F2680, PIC18F2682, PIC18F2685, PIC18F24J10, PIC18F24J11, PIC18F24J50, PIC18F25J10, PIC18F25J11, PIC18F25J50, PIC18F26J11, PIC18F26J50, PIC18F23K20, PIC18F23K22, PIC18F24K22, PIC18F25K22, PIC18F24K20, PIC18F25K20, PIC18F26K20, PIC18F26K22
40 Pin: PIC16F59, PIC16F74, PIC16F77, PIC16F707, PIC16F724, PIC16F727, PIC16F747, PIC16F777, PIC16F871, PIC16F874, PIC16F874A, PIC16F877, PIC16F877A, PIC16F884, PIC16F887, PIC16F914, PIC16F917, PIC16F1517, PIC16F1519, PIC16F1934, PIC16F1937, PIC16F1939, PIC16LF1904, PIC16LF1907, PIC18F442, PIC18F452, PIC18F448, PIC18F458, PIC18F4220, PIC18F4221, PIC18F4320, PIC18F4321, PIC18F4331, PIC18F4410, PIC18F4420, PIC18F4423, PIC18F4431, PIC18F4450, PIC18F4455, PIC18F4458, PIC18F4480, PIC18F4510, PIC18F4515, PIC18F4520, PIC18F4523, PIC18F4525, PIC18F4550, PIC18F4553, PIC18F4580, PIC18F4585, PIC18F4610, PIC18F4620, PIC18F4680, PIC18F4682, PIC18F4685, PIC18F44J10, PIC18F45J10, PIC18F45J11, PIC18F45J50, PIC18F43K20, PIC18F44K20, PIC18F45K20, PIC18F46K20, PIC18F43K22 PIC18F44K22, PIC18F45K22, PIC18F46K22



dsPIC/PIC24F Microcontroller

18 Pin: PIC24HJ12GP201, dsPIC30F2011, dsPIC30F3012, dsPIC33FJ12GP201
20 Pin: PIC24F04KA201, PIC24F08KA101, PIC24F16KA101
28 Pin:
PIC24HJ12GP202, PIC24F08KA102, PIC24F16KA102, PIC24FJ32GB002, PIC24FJ64GB002, PIC24HJ32GP202, PIC24HJ32GP302, PIC24HJ64GP202, PIC24HJ64GP802, PIC24HJ128GP202, PIC24HJ128GP502, PIC24HJ128GP802, PIC24FJ16GA002, PIC24FJ32GA002, PIC24FJ48GA002, PIC24FJ64GA002, PIC24FJ32GA102, PIC24FJ64GA102
dsPIC30F1010, dsPIC30F2010, dsPIC30F2012, dsPIC30F2020, dsPIC30F3010, dsPIC30F3013, dsPIC30F4012
dsPIC33FJ12GP202, dsPIC33FJ64GP802, dsPIC33FJ32GP302, dsPIC33FJ64GP202, dsPIC33FJ64GP802, dsPIC33FJ128GP202, dsPIC33FJ128GP802, dsPIC33FJ06GS102, dsPIC33FJ06GS202, dsPIC33FJ16GS402, dsPIC33FJ16GS502, dsPIC33FJ12MC202, dsPIC33FJ32MC202, dsPIC33FJ32MC302, dsPIC33FJ64MC202, dsPIC33FJ64MC802, dsPIC33FJ128MC202, dsPIC33FJ128MC802
40 Pin: dsPIC30F3011, dsPIC30F4011



Serial EEPROM

11LCXX (With iCP11): 11LC010, 11LC020, 11LC040, 11LC080, 11LC160
24LCXX (With iCP03v2 or iCP11): 24LC00, 24LC01B, 24LC02B, 24LC32A, 24LC64, 24LC128, 24LC256, 24LC512, 24LC1025
25LCXX (With iCP03v2 or iCP11): 25LC010A, 25LC020A, 25LC040A, 25LC080A, 25LC080B, 25LC128, 25LC160A, 25LC160B, 25LC256, 25LC320A, 25LC512, 25LC640A, 25LC1024
93LCXX[A/B/C] (With iCP11): 93LC46, 93LC56, 93LC66, 93LC76, 93LC86
HCSXX (With iCP11): HCS200, HCS201, HCS300, HCS301, HCS320, HCS360, HCS361, HCS362

[xiantia]

Salut a tous:

Âpres quelques tests et autre au niveau des DAC serie 16 bits ... ben j'arrive pas trop à le faire tourner La doc ne correspond pas vraiment.
La seule chose qui marche c'est l’envoi des données non pas en 16 mais en 24 bits (ce qui diminue les performances du fait du nombre de bits en plus).

Dommage car le system était pratiquement fonctionnel pour un essais à l'oscillo. De plus c'était vraiment compacte !

Modul Ethernet :

IMAG0076.jpg

Modul RS232 pour debugage.

IMAG0077.jpg

Et le DAC en lui même ( a droite le pic 16f84 et juste a coté le DAC 16 bits).

IMAG0079.jpg

Voila donc cet après midi démontage de l'oscillo pour petite révision et passage du code 16F84 en version 16F877 pour pilotage d'un DAC 8 bit mais en données //.


Bye Yannick.

[shrad]

est-ce que ton DAC ne fonctionne pas avec des dummy bits en endian inverse? si c'est le cas et que tu dois envoyer une trame de 24bit c'est un DAC un peu naze non?

ne vaudrait il pas mieux en trouver un autre, voire utiliser une I/O deportee 16bit avec un R/2R?

[xiantia]

re :

Pour le DAC j'ai tester un peut toutes les possibilités (little endia / big endia), mais pas grand chose de probant !

Un autre DAC série ... je sais pas (prix, datasheet, pilotage ...)

En ce qui concerne le R2R oui mais ça pose problème au niveau I/O du µP, il faut le coupler à des bascules pour utiliser les mêmes lignes pour X et Y.
Du coup ça fait plus de composants , mais les performances sont plus importantes.

Bye Yannick.

[shrad]

chez microchip ils en ont des sympa

http://ww1.microchip.com/downloads/en/d ... 21897a.pdf

http://www.ee.ic.ac.uk/pcheung/teaching ... al/DAC.pdf

en gros, je pense que 8 bit c'est trop peu et 16bit trop, car les gens ne voudront pas un DAC avec une definition aussi basse, mais n'ont pas besoin de 16 bit

l'avantage des DAC microchip est egalement que tu peux trouver des librairies chez eux, que tu peux a la rigueur modifier ou ne prendre que la partie interessante... maintenant c'est ce que j'en dis hein...