Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : mazertoc
Migrer 16F vers 18F
- paulfjujo
Expert- Messages : 2598
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Bonsoir,
"ça tombe en marche "
Oui, c'est bien un CALL , .....Call Trait_IT_High .. retour avec le return
par contre effectivement
un "return" aurait été plus judicieux au lieu du "retfie" (situé dans le sous programme)
En fait ,c'est plutot ceci que j'aurais du faire
mais si le retfie assume la restitution des registres empilé au moment de l'appel de l'interrupt
il ne devrait pas y avoir de probleme avec retfie au lieu de return.
Nota:
je n'ai pas verifié si le pointeur de pile fait partie des registres sauvegardes
sinon cela pourrait creer un plantage à plus long terme.
Tu ne peux pas envoyer tes caracteres dans le main, parceque justement
tu as armé l'interuption TX
qui deroute le main.. vers le traitement IT interrupt..
Je ne vois aucun interet à utiliser TX interrupt dans cet exemple .
Sur une reception tendue ( un bon paquet de caracteres à recevoir , sans espaces temporel entre les caracteres)
l'envoi de plusieurs caracteres dans le traitement IT RX, pourrait serieusement celle ci.
( meme si on suppose quand meme qu'on utilise un buffer pour receptionner un paquet de caractere)
car bouffe du temps CPU . dans le traitement meme de l'IT RX.
l'envoi de F6FC0 CR,LF 10 cars à 9600bds va bouffer > 10mS , ou RX IT est aveugle pendant ce temps.
D'ailleurs, j'aimerai bien qu'on me montre un exemple utile d'usage IT TX ..
les seuls cas que j'envisage pour l'instant serait basé sur une retransmission quasi automatique :
on recoit sur UART1 RX et on Retransmet par IT TX sur UART2 TX
ou un recoit un byte par SPI ou I2C et le RETRANSMET par UART11 TX IT.
ou IT sur mesure ADC => envoi automatique valeur sur UART1 TX IT.
"ça tombe en marche "
Je pense que tu as pensé 'call' et écris 'goto'
Oui, c'est bien un CALL , .....Call Trait_IT_High .. retour avec le return
Code : Tout sélectionner
ORG H'08'
call Traite_IT_High
retfie
reception
....
...
return <- retour à l'appel du sosu programme
par contre effectivement
un "return" aurait été plus judicieux au lieu du "retfie" (situé dans le sous programme)
En fait ,c'est plutot ceci que j'aurais du faire
Code : Tout sélectionner
Traite_IT_High
...
btfsc PIR1,RC1IF
goto reception
return <-- un retour normal à l'appelant au lieu du retfie
mais si le retfie assume la restitution des registres empilé au moment de l'appel de l'interrupt
il ne devrait pas y avoir de probleme avec retfie au lieu de return.
Nota:
je n'ai pas verifié si le pointeur de pile fait partie des registres sauvegardes
sinon cela pourrait creer un plantage à plus long terme.
Tu ne peux pas envoyer tes caracteres dans le main, parceque justement
tu as armé l'interuption TX
qui deroute le main.. vers le traitement IT interrupt..
Je ne vois aucun interet à utiliser TX interrupt dans cet exemple .
Sur une reception tendue ( un bon paquet de caracteres à recevoir , sans espaces temporel entre les caracteres)
l'envoi de plusieurs caracteres dans le traitement IT RX, pourrait serieusement celle ci.
( meme si on suppose quand meme qu'on utilise un buffer pour receptionner un paquet de caractere)
car bouffe du temps CPU . dans le traitement meme de l'IT RX.
l'envoi de F6FC0 CR,LF 10 cars à 9600bds va bouffer > 10mS , ou RX IT est aveugle pendant ce temps.
D'ailleurs, j'aimerai bien qu'on me montre un exemple utile d'usage IT TX ..
les seuls cas que j'envisage pour l'instant serait basé sur une retransmission quasi automatique :
on recoit sur UART1 RX et on Retransmet par IT TX sur UART2 TX
ou un recoit un byte par SPI ou I2C et le RETRANSMET par UART11 TX IT.
ou IT sur mesure ADC => envoi automatique valeur sur UART1 TX IT.
Migrer 16F vers 18F
- F6FCO
Expert- Messages : 1420
- Âge : 70
- Enregistré en : décembre 2017
- Localisation : Furtif je suis.
- Contact :
YESSS, c'est tout bon .
Effectivement en n'utilisant que l'interrupt RX çà marche au poil. Avec les deux validées j'utilisais tout le temps machine et il n'y avait plus de place pour le main.
Reste à gérer le flux avant de pouvoir repasser sur le soft CNC.
Effectivement en n'utilisant que l'interrupt RX çà marche au poil. Avec les deux validées j'utilisais tout le temps machine et il n'y avait plus de place pour le main.
Reste à gérer le flux avant de pouvoir repasser sur le soft CNC.
Migrer 16F vers 18F
- paulfjujo
Expert- Messages : 2598
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
donc, à rajouter un buffer de reception, un index ..etc
J'ai eu l'occasion de refaire mon programmateur d' AT89C2051 basés ur PIC18F46K22
avec cette fois, le protocole software XON XOFF au lieu du protocole CTS/RTS Hardware
pour éviter l'usage d' un MAX322 pour avoir TX,RX et CTS ou un cordon TTL/USB en 6 fils (pour avoir CTS !)
donc allege l'interface UART , car uniquement la liaison TX,RX (et 0V!) sur un cable Prolific USB standard à 4 fils .
Ca reste tres fiable pour envoyer un fichier *.HEX de 2Ko, (ou nettement plus) dont chaque ligne se termine par un CR LF
Envoi d'un message demandant d'entrer le nom du fichier (sur le terminal)
delay de 20 sec accordé pour la saisie du nom et tape sur ENVOI
Envoi d'un XON
si rien n'est arrivé apres le delay accordé => bad link, sortie de programme
sinon , ça arrive ..
je recupere donc une ligne à la fois sur detection du caractere CR,
Bloque l'envoi avec un TXREG1=XOFF;
recupere l'index de debut de chaque ligne ..l'adresse , les datas .. et le CRC en fin de ligne,
comparé à celui calculé pendant la reception.
si c'est OK, je l'ecrit dans l' AT89C2051 , sinon sortie sur erreur
renvoi un XON ..pour lire la suite du fichier
..etc
donc à priori , no problemo avec un fichier Gcode. !
un buffer de 80 caracteres est suffisant dans mon cas, pour contenir une ligne du fichier HEX (<80 cars) .
mais c'est en C ... pas en ASM
aux ASMistes de jouer!
Migrer 16F vers 18F
- F6FCO
Expert- Messages : 1420
- Âge : 70
- Enregistré en : décembre 2017
- Localisation : Furtif je suis.
- Contact :
Bonjour,
De mon coté tester la macro de Satinas sur Teraterm en envoyant à partir du PIC un ACK et NAK, le but étant de travailler que sur des trains de 9 octets. Les fichiers gcode risquent d'être bien plus gros que les tiens. Puis peut-être aussi faire des essais hard avec CTS/RTS maintenant que je maîtrise mieux la chose, histoire de me faire des routines toutes prêtes à servir que je rangerai dans la caisse à outil. Peut-être aussi XON/XOFF, pour explorer la RS232 à fond.
De mon coté tester la macro de Satinas sur Teraterm en envoyant à partir du PIC un ACK et NAK, le but étant de travailler que sur des trains de 9 octets. Les fichiers gcode risquent d'être bien plus gros que les tiens. Puis peut-être aussi faire des essais hard avec CTS/RTS maintenant que je maîtrise mieux la chose, histoire de me faire des routines toutes prêtes à servir que je rangerai dans la caisse à outil. Peut-être aussi XON/XOFF, pour explorer la RS232 à fond.
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 133 invités