SONDAGE PROJET HARDWARE - Page 4

L'idée de l'uC c'était d'envoyer au bouzin une commande qu'il va traiter de façon asynchrone pendant que le 68000 s'occupe d'autres choses, et quand la cuisson est finie il va récupérer le plat encore tout chaud.

A ce compte, autant essayer de refaire le ICDLink et d'avoir accès à une plétore de périphériques SCSI depuis le port ACSI...

Kochise

le link ça doit etre cool mais j'imagine que les sources sont introuvables non?

Kochise (./91) :
L'idée de l'uC c'était d'envoyer au bouzin une commande qu'il va traiter de façon asynchrone pendant que le 68000 s'occupe d'autres choses, et quand la cuisson est finie il va récupérer le plat encore tout chaud.

J'avais bien compris l'idée mais le problème c'est que les fonctions de lectures / écritures sont synchrones sous TOS : temps que l'opération n'est pas finie, on reste bloqué.

Et puis ce que je voulais dire c'est que le temps de transfert/"traitement" sera quasiment le même entre une solution uC et une "gestion directe" puisque justement le temps de transfert via le port cartouche est largement supérieur au reste.

En d'autres termes je ne vois pas ou le gain de vitesse (significatif) se fait avec un uC via le port cartouche.

Note: Il manque une ligne d'IT sur ce port. C'est un peu dommage .

C'était justement pour le traitement des IT dont le 68000 pouvait continuer de s'occuper pendant que l'uC préparait les paquets. Ensuite la fin de cuisson peut être sous forme de sémaphore poolé toutes les 20 ms (ça tombe bien, 1 VBL)

Kochise

Je pense que le µC doit integrer les "drivers" qui existent dans les doc microchip pour une clef USB, souri, clavier, SD ..

Cela evite de refaire ce qui existe deja pour le PIC (oul'AVR)

sundance (./83) :
je connais pas le kit de dev Jajuar mais je demande qu'a apprendre. l'assembleur me suffit.

Parfait ^^
En fait tu n'auras pas grand-chose à apprendre, si tu n'utilises que l'assembleur, c'est exactement pareil que n'importe quel autre assembleur 68000 (y'a juste les trucs pas standards qui seront peut-être un peu différents, par exemple la syntaxe des macros)

sundance (./83) :
(vbcc ? c'est quoi?)

C'est un compilo C concurrent de GCC, il a l'avantage d'être beaucoup plus léger.

sundance (./83) :
si tu participes et que tu maitrise déjà alors pas de problème, je postasse , éventuellement te poses quelques questions, et je serais efficace rapidement.

Je n'aurais pas le temps de participer à plein temps (j'ai déjà plein d'autres projets sur le feu) mais s'il te faut un coup de main sur des points précis, il n'y a pas de problème
J'ai une carte de dév (officielle) AT90USB dans mon placard d'ailleurs.

sundance (./83) :
tu pensais a quel micro dans la gamme ?

La gamme Mega : http://atmel.com/dyn/products/devices.asp?category_id=163&family_id=607&subfamily_id=760
Apparemment il y a une gamme encore supérieure (XMega) qui est sortie, mais je ne sais pas ce que ça vaut, et j'ai pas l'impression que ça fasse USB Host : http://atmel.com/dyn/products/devices.asp?category_id=163&family_id=607&subfamily_id=1965

Après, il faut voir si c'est avantageux d'utiliser un micro avec contrôleur USB intégré, ou de mettre à côté un composant spécialisé comme le FTDI Vinculum. L'USB intégré a l'avantage d'être plus flexible et moins cher, mais l'inconvénient de demander davantage de temps de développement et de débuguage (même si on a les sources pour gérer les périphériques USB, c'est toujours un peu galère à faire marcher).

johnz (./86) :
pourquoi ne pas utiliser les plans de ppera pour faire des interfaces ide tout simplement?

Ppera est un bricoleur dans le mauvais sens du terme, je connais quelqu'un qui a eu des données corrompues sur son disque dur à cause d'un de ses montages...

si vous partez sur une périphérique sur port cartouche, pensez que pour la plus part, on a d'autres hardware sur ce port. il serait peut être bien de reporté un port femelle. genre moi j'ai une Hydra sur le port cartouche.

Dans l'absolu il est pas possible de partager le port cartouche dans tous les cas.

Il est clair, que pour du stockage sur sdcard/CF (par ex) le mieux c'est de gérer tout direct du 68K.
Et je suis d'accord que ça ne changera pas grand de mettre un µp.
pour l'usb/eth c'est moins évident car le protocole est plus complexe mais pourquoi pas.
cela veut dire aussi que pour chaque port on rajoute un chip dédié.(usb/etn etc)
ça a l'avantage de faire une carte modulable ou on pourrait enficher les modules du commerce dessus.
du coup étude hard plus simple
il suffit d'avoir plusieurs lien spi gérer par la (ou le?) CPLD pour pouvoir y mettre des modules wiznet / ftdi / enj28C60 etc
et un plan mémoire en r/w pour y mettre le soft

mais Jeff si tu peux exposer plus précisément la solution que tu préconise de façon a chiffrer le rapport cout et fonctionnalité envisageables.

Le Satandisk est un très bon produit , mais pour celui qui a un chip dma buggé, c'est moyen.

Je veux aller au bout des raisonnement de chacun afin d'avoir toutes les solutions et que l'on puisse choisir ou faire des compromis

-1 Version micro-contrôleur
-2 Version CPLD stockage + chip dédié

dans les 2 cas il faut choisir les composants et chiffrer.

µp ?
CPLD?

Yep, pour la carte SD c'est du SPI bête et méchant, pas besoin de mettre un chip dédié pour ça (sauf si on veut l'utiliser en mode 4 bits, mais ça n'a pas d'intérêt, le débit sera de toute façon limité par celui du port cartouche).

sinon pour le controleur ide plugué sur le 68000 y a ce type de montage
http://amiga.erkan.se/index.php/internal-amiga-500-ide-hard-drive-controller-from-finland/

Y'a cette solution, mais ça demande d'ouvrir le ST et ça ne sera pas compatible avec tous les modèles (les plus récents ont un 68000 avec un boîtier différent). Ne parlons même pas des Falcon.

Et puis un disque dur, c'est encombrant et ça fait du bruit. Alors qu'une carte SD de 512 Mo par exemple, c'est tout petit, silencieux, c'est pas cher et c'est pratique à enlever si on doit transférer des fichiers.

bah apres libre a toi de mettre un adaptateur cf en interne. pour ma part je prefere les disques durs vu que des disques durs de tailles abordables ça se trouve gratos en poubelle

je viens de faire un tour chez ATMEL en effet la gamme xmega présente un certain intérêt.

mais coté perf c'est mieux qu'un pic 8 Bits il n'y a pas photo et moins bien qu'un pic 16bits à prix équivalent.
certaine fonctions (gestion ram dynamic/wave generator etc) ne se trouve que chez ATMEL.

merci Zerosquare pour ta proposition d'aide,j'aurais certainement besoin du des soft de dev jag....

après il y a le modèle 32bits (uc3) avec tous les travers des micro-contrôleurs 32 bits moderne (jeu d'instructions orienté optimisation c/java)
in_debugable temps réel (au timing plus ou moins fantaisiste...)

maintenant je vais regarder les modules FTDI...

Jeff tu verrais quoi comme CPLD ?




PS (merci Vince c'est corrigé)

sundance (./105) :
je viens de faire un tour chez ATMEL en effet la gamme xmega présente un certain intérêt.

mais coté perf c'est mieux qu'un pic 8 Bits il n'y a pas photo et moins bien qu'un pic 16bits à prix équivalent.
certaine fonctions (gestion ram dynamic/wave generator etc) ne se trouve que chez ATMEL.

après il y a le modèle 32bits (uc3) avec tous les travers des micro-contrôleurs 32 bits moderne (jeu d'instructions orienté optimisation c/java)
in_debugable temps réel (au timing plus ou moins fantaisiste...)

maintenant je vais regarder les modules FTDI...

Jeff tu verrais quoi comme CPLD ?

t'as oublie ""

Pour les CPLD, y'a quelques années les CoolRunner de Xilinx étaient pas chers et pas mal, Altera doit avoir un truc équivalent.

Par contre les CPLD 5V c'est devenu introuvable, donc faudra encore mettre un paquet des level-shifters :/

oui en effet seul max 3000 input tolérant 5v chez Altera
mais encore au catalogue!!

Probablement obsolète dans pas longtemps alors... je sais pas si c'est une bonne idée de partir sur des composants qu'on risque de ne plus trouver bientôt.

Moi aussi cela m'interresse pas mal ce petit projet, pour moi c'est d'avoir des ports usb permettant de brancher souris/clavier clé usb et en meme temps de pouvoir avoir une carte sd comme dd, et un port rj45=

Pardon de vous interrompre, je viens de découvrir la question de Sundance.

Pour moi qui ne fait que jouer sur Atari STe, le SDisk Emul m'a permis de renouer de plus belle avec cette machine.

Ma TV étant éloignée du canapé, mon ST se retrouve par terre entre le meuble TV et la table basse, écartelé par le cable vidéo vers la TV d'un côté et le cable de ma manette de l'autre. Ce qui m'embête un peu, c'est qu'il faut l'avoir près de soi parce qu'il faut appuyer sur telle touche du clavier, parce que le cable de la souris est pas assez long, pour faire un reset.....

J'aimerai donc avoir mon ST près de ma TV, et un clavier sans fil à portée de main. Puisque les ports manettes et souris sont solidaires du clavier, ce serait peut-être envisageable de remplacer les 6 ou 7 fils du clavier par un transmetteur (IR) ?!! Ou alors pouvoir connecter un récepteur sur l'Atari, compatible avec un clavier ou une manette sans fil actuelle (via USB).

Ce serait réalisable ??

Je n'y connais rien en hardware ou software, mais les soudures ne me font pas peur !

Merci

Faisable, maintenant il faut voir s'il y a d'autres personnes intéressées.

Sinon tu peux aussi acheter une carte Eiffel et y brancher un clavier et une souris sans-fil PS/2.

(et 112 à 211 au passage )

Pour les CPLD je pense que Jeff est le plus à même de savoir ...

en effet le kit Eiffel est très bien, de plus il intègre les gestions de raccourcis via une seule touche.
le tout en ps2 c'est vrai.

pour la gestion en usb c'est faisable sur le port cartouche via un module FTDI.

justement à propos du module FTDI viniculum 2, ce module est constitué d'un µp 16bits un de bibliothèque pré-compiler avec des applis std et code user!

bibli std : usb > spi/rs232/gestion de fat direct!!/adc/i/o etc

c'est assez bluffant ! pas mal de drivers coté pc sont fournis , l’environnement de dev à l'air pas mal.

après câblage du port cartouche

un petit coup d'analyseur logique :

Fichier joint : (CARTRIDGE.jpg)

après le reset et à chaque boot le 68k fait un accès en 0x0000 et 0x0002 vérification présence cartouche.
un cycle de lecture dure 500ns pour 16 bits.(rien de nouveau)

soit un débit théorique de 4Mo/s (ou 32 Mb/S)
je pense qu'en pratique on sera 2Mo/S

2Mo/s en lecture, en ecriture ca sera beaucoup plus lent

Faut voir comment on pourrait optimiser le code assembleur pour ça (movem ? blitter ?)

ben en écriture tu ne pourras pas optimiser vu qu'il faudra faire la bidouille de passer les datas par le bus d'adresse.

en effet mais je ne sais pas le quantifié....

a0=$fffa0000
a1=$fffb0000
d0=data en word
a2=buffer

lecture:

move.w (a0),d1 ??cycles
ou
move.w (a0),(a2)+ ??cycles

voir

movem.l (a0)+,d0-d7
movem.l d0-d7,(a2)+

écriture:

move.w (a1,d0.w),d1 ?? cycles
ou
tst.w (a1,d0.w) ?? cycles


il y a peut être d'autre moyen de codé sur 68 k....

après tu peux aussi décider que les adresses paires sont "données" et les adresses impaires sont "adresses" ça se "switche" juste avec un signal 0/1 facilement "câblable" sur le port cartouche et ça ne fait que diviser par deux ta plage d'adresse (et ta BP max...)