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 ---
Forum général sur l'Assembleur !

Modérateur : mazertoc

Migrer 16F vers 18F
paulfjujo
Avatar de l’utilisateur
Expert
Expert
Messages : 2589
Âge : 73
Enregistré en : juillet 2015
Localisation : 01800
Contact :

#21 Message par paulfjujo » sam. 9 juin 2018 20:34

Bonsoir,


"ç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.
Aide toi, le ciel ou FantasPic t'aidera

Migrer 16F vers 18F
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#22 Message par F6FCO » sam. 9 juin 2018 22:10

YESSS, c'est tout bon :-D.
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.
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:

Migrer 16F vers 18F
paulfjujo
Avatar de l’utilisateur
Expert
Expert
Messages : 2589
Âge : 73
Enregistré en : juillet 2015
Localisation : 01800
Contact :

#23 Message par paulfjujo » dim. 10 juin 2018 14:45

:bravo:

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

exit aux ASMistes de jouer!
Aide toi, le ciel ou FantasPic t'aidera

Migrer 16F vers 18F
F6FCO
Avatar de l’utilisateur
Expert
Expert
Messages : 1413
Âge : 70
Enregistré en : décembre 2017
Localisation : Furtif je suis.
Contact :

#24 Message par F6FCO » dim. 10 juin 2018 16:41

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.
Une porte nand prend 2 bits en entrée... la cochonne !!! :langue:


Retourner vers « Langage ASM »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 41 invités