InterfaceIR/HF - Page 2

moi je vous soutiens totalement sur ce projet...

squalyl> t'as des infos sur le protoype imprimante du Post 16 de NSPIRIT ?

je pense que l'interface par I2C est une bonne idée, on a déja des drivers

ouais, c bien I²C, mais quel est le débit de sortie maximal du port de la calc ?

pas des masses mais suffisant pour une printer ( 9600 )

c + que 9600 le débit maxi, c juste que c exploitrable stable juste à cette vitese

9*10=90
100000/90=1234 cps, si tu prog bien
Ce qui ma foi est largement suffisant non ?

Il y a des imprimantes qui se branchent sur un port série avec une liaison RS232 .
C'a pourrait etre encore plus simple que le port parrallèle ( mais plus rare ...)
[edit]Edité par SLR le 28-03-2002 à 08:54:42[/edit]

oui mais tout le monde a une imprimante // chez soit je pense alors autant en profiter non ?

C'est vrai .

ou une USB majheureusement, mais la c'est tant pis pour eux, parce que gérer un port USB sur la calc ca me parait chaud chaud

j'ai réfléchis sur le projet :
en fait l'interface // ne devrait pas être compliquée je m'explique :
il ne serait pas récessaire pour la calc de gérer les ctrl d'érreur :
le transf fonctionne comme ceci :
1-Strobe (-> init)
2-Envoi 1 octet de donnée via pins 2-9
3-Acknowledge (bien reçu!)
3-Busy (j'attend la suite)

à mon avis les 2 derniers ne sont nécessaires que si l'imprimante est succeptible de prendre du retard sur le Pc ... mais pour du transf de text, je pense qu'on pourrait faire sans.
L'envoi de données n'a pas besoin d'être synchronisé avec la zone de texte de l'imp est en train d'imprimer
En effet : sur Pc : qd l'imprimante est à la traine, la mémoire enregistre les données envoyées et les accumulent (le Pc n'a donc pas besoin d'attendre que l'imprimante ait fini d'imprimer une ligne pour passer à la suivante)
à l'inverse ...
merde j'ai cours je reviens ds une heure !

au boulot !

bon alors je disais
à l'inverse qd c'est le Pc qui a du retard, l'imprimante se met automatiquement en attente, il n'y à pas de Timeout
exemple : si on met en veille système un Pc lors d'une impression, çà continue la moitié de la page (la mémoire se vide) et ensuite elle s'arrête, mais dès qu'on rallume le Pc çà reprend ...
Conclusion : il n'est pas nécessaire d'utiliser les pins de ctrl type Acknowledge et Busy ...
la seule différence est que si une anomalie survenait au niveau de l'imprimante, (PaperOut ...) il ne serait pas possible, comme ds Windoz de reprendre l'impression automatiquement là où elle s'est arrêtée, car la calcu ne saurait pas ce qui a été reçu où non ...
Mais le problème ne se posera pas, car la mémoire de l'Imprimante sera largement suffisante pour emmagasiner tout le txt à imprimer (on va pas imprimer 10 pages derant donc la mémoire sera suffisante) avant même que l'erreur ne survienne, donc l'imp sera totalement autonome, et reprendra l'impression lorsqu'une nouvelle feuille aura été insérée
il peut arriver en effet que lorsque l'on imprime des feuilles avec uniquement du texte pas lourd, que l'imp finisse le trvail d'impression de façon totalement automatique et indépendante ...

Conclusion générale : on peut à mon avis se contenter du Pin Strobe et des 8 pins Data ... il suffirait d'envoyer les données suffisament lentement à vitesse constante pour que l'impr les reçoive et vala
la vitesse de transf serait la même quel que soit le model d'imp utilisé (les imp à rubans sont plus lentes que les Jet d'encre)
pour faire style on pourrait juste rajouter 2 DEL PaperOut et Error et encore ... celles ci sont djà sur l'imp
-------------------------------------------------------------
SLR> à mon avis je pense que le port // est plus simple à réaliser ...
il y a juste les 9 voies indépendantes à gérer mais les i2clib sont déjà crées dc çà devrait pas poser trop de prbs
de plus, pour un port série, il faudrait gérer le ctrl de flux avec DSR ... et çà risque d'être prise de tête
de plus le port // serait qd même plus pratik on pourrait l'utiliser même avec les veilles imp à ruban (et je dis pas çà pour moi, moi mon espon gère le port série pour Mac )

bon j'ai devoir de Maths à 13h00 donc fo que j'aille bosser un peu qd même !! (probas et exp)

IMPECCABLE!!!
La première adresse est la bonne.
Lisez la d'abord.
Le projet est réalisable.
Les lignes à utiliser seront d0-d7 et toutes les autres sauf ACK.
En effet cette ligne de l'imprimante vers le PC signale que l'imprimante a reçu la caractère mais:
1) Le signal qu'elle envoie est trop court pour être détecté sans gestion d'interruptions;
2) Si BUSY n'est pas actif, c'est que le caractère a été recu, donc ACK sert à rien.

Alors le protocole c'est le suivant:
1) on active SELECT
2) On lit BUSY, ERROR
3) si c pas bon on blègue (attente, timeout, erreur, message,...)
4) si c bon on met l'octet sur d0-d7
5) on met STROBE à l'état bas pdt un petit moment.
On recommence pour les octets suivants.
C tout.
Le reste c'est de la programmation.
Je m'en occuperai ce week-end, du driver. Mais j'ai qu'un PCF8574 pour I2C, je sais pas si je pourrai en acheter un autre cette semaine.

tu es sur que les phases 2) et 3) on est obligé des les mettre ?
si on attend un peu avant de mettre l'octet çà dvré passer ... par contre on aura pas de msg d'erreur sur la calto c'est tout ...
l'imprimante sait attendre donc on est pas obligé d'envoyer l'octet immédiatement après que l'imprimante signale busy off

çà devrait pouvoir marcher et çà simplifirait pas mal ...

[edit]Edité par Electrocut le 28-03-2002 à 17:19:32[/edit]

oui mais un message d'erreur style "plus de papier" sur la TI ca ferait classe

mais une ptite del c'est bocou plus simple

c sur ca evite à avoir à gerer les retour de l'imprimante

un msg d'erreur, c'est beaucoup plus class

c bien ce que je disais...
je vois déja le truc mdr
les casio user vont raler

autant commencer par un truc simple qui marche plutôt que de foirer nan ?

mais on peut faire plusieurs version du sotf, mais pas du hard parce que c chiant ça

c'est mieux de commencer avec la gestion des erreurs, même si le logiciel n'en tient pas compte au départ. Vaut mieut prévoir plutot que de refaire 10 fois le montage
[edit]Edité par SLR le 28-03-2002 à 20:44:27[/edit]

c ce que je dis exactement

je vais commencer par tester avec une pile 4.5 sur le port // pour voir si l'imprimante prend ...
pour l'interface faudra qu'on ai un gros coup de main !

oui parce que moi l'electronique...

c la progra ton domaine ?

Si le port // prend po le 4,5V, tu fous un DC/DC.
Pour le montage, c'est tout con par contre.
Sachant que :
1 pcf 8574 pour les données (Entré et sortie svp !!!)
1 pcf 8574 pour les signeaux de controles.

Mais dans ce cas, va falloir gicler un signal, car ca ne fait que 16 I/O.
On peut aussi émuler un signal avec une logique simple ....

Pour la parti electrique, les pcf fonctionnent bien sur 4,5V, meme pasbesoin de leur adjoindre un condo de découplage, un seul pour l'alim général du circuit suffira si l'alim est bien découplé ou sur pile.

Pour les sortie de puissance, c'est pas vraiment la peine, mais on peut aussi tantqu'à faire, donner un accés sur le pcb pour piquer les signeaux

NSPIRIT: Lis mon post 45!!!

Le signal à gicler c ACK.

Ce week-end je vais essayer.
Le montage c du basique:


Moi je vois pas pourquoi on pourrait pas faire des drivers pour chaque type d'imprimante. Une LIB spécifique par imprimante contenant les mêmes fonctions adaptées pour chaque imprimante.
Je crois qu'il faut des pull-up pour le port I2C non?

[edit]Edité par squalyl le 29-03-2002 à 13:05:35[/edit]