SRAM que deux puces peuvent lire / écrire


9

Je recherche un petit périphérique SRAM de 32 Ko environ que deux MCU peuvent lire ou écrire (à deux moments différents; je n'ai pas besoin de lecture / écriture simultanée.) Ce serait bien s'il utilisait également une interface série.

Le problème que j'essaie de résoudre est d'envoyer des données entre deux appareils sans que l'autre appareil ait à s'arrêter pour recevoir cela. Je transfèrerais un échantillon audio dans le tampon, puis l'autre puce, au besoin, lirait l'audio et ferait quelque chose avec.

J'ai trouvé des SRAM série comme les 23A256 / 23K256 de Microchip, cependant, ils semblent avoir une seule interface série. Existe-t-il un moyen pour que deux puces y accèdent?

De plus, le périphérique de réception ne dispose que de 2 Ko de mémoire de données (maximum), il semble donc que l'utilisation de DMA ou d'un mécanisme de transfert similaire via I2C ou une autre interface ne fonctionnera pas.

Réponses:


10

Vous n'avez pas besoin de RAM à double port ou même d'une RAM série avec deux interfaces; Pour SPI, c'est un peu plus délicat, mais I2C autorise plusieurs maîtres "prêts à l'emploi". Quoi qu'il en soit, votre logiciel devra surveiller les conditions du bus pour voir s'il a perdu le bus et, le cas échéant, attendre une autre opportunité.

Pour SPI, les lignes MOSI, CS et CLK doivent être tri-déclarées (ou à collecteur ouvert) avec des résistances de rappel pour empêcher les lignes de flotter. Vous aurez également besoin d'une sorte d'arbitrage en bus. Cela peut être aussi simple qu'un GPIO unique entre les deux maîtres afin que celui avec une priorité plus élevée signale au maître de priorité inférieure que le bus n'est pas disponible, mais une solution plus élégante serait une seule ligne à collecteur ouvert entre les maîtres. Lorsque le bus est inactif, aucun des deux maîtres ne tire la ligne vers le bas de sorte qu'il flotte haut avec un pull-up. La logique est que si la ligne est haute, le bus est disponible. Le maître qui veut utiliser la mémoire regarde la ligne "bus disponible" et si elle est haute, baissez la ligne et attendez quelques ms pour vous assurer que l'autre maître n'a pas saisi le bus en même temps. Si la ligne RAM SPI CS est toujours inactive, il peut être sûr de supposer que le bus est le vôtre. Faites le transfert, tri-état de vos lignes MOSI / CLK et lâchez le signal "bus actif".

Le "attendre quelques ms après avoir tiré la ligne de demande de bus vers le bas" est nécessaire car il est possible pour les deux maîtres de saisir la ligne en même temps.

Si vous n'utilisez qu'un seul appareil partagé et que cet appareil ne nécessite pas plusieurs transferts, vous pouvez utiliser sa ligne CS comme signal "bus disponible", mais ce n'est pas aussi robuste.


Mais s'ils prennent tous les deux la ligne en même temps et attendent le même temps avant de transmettre, n'est-ce pas la même chose que de ne pas attendre du tout?
endolith

L'idée serait d'attendre quelques ms + quelques ms aléatoires. Vraisemblablement, ils exécuteraient différents logiciels et diverses latences / interruptions / etc. contribueraient au caractère aléatoire du retard.
akohlsmith

2
D'après mon expérience, I2C fonctionne bien dans un environnement multimaître. Cependant, il n'est pas aussi rapide que SPI, donc si vos objectifs de performances nécessitent des transferts en rafale supérieurs à 400 kb / s, vous devez poursuivre SPI.
RBerteig

1
@endolith: Si les deux appareils transmettent la même chose, ils ne seront pas conscients de l'existence de l'autre. S'ils transmettent des choses différentes, le premier appareil qui transmet un "1" tandis que l'autre transmettait un "0" devrait détecter qu'il a perdu l'arbitrage, cesser immédiatement de transmettre et s'attendre très probablement à retransmettre l'intégralité de sa commande depuis le début.
supercat

3

Le moyen le plus simple serait d'implémenter un bus SPI multi-maître. Vous pouvez utiliser deux lignes d'E / S supplémentaires entre les maîtres pour l'arbitrage à l'aide d'un mécanisme de négociation.


2

Je vois deux solutions possibles à votre problème:

1) Trouvez une puce FIFO adaptée à vos besoins (un exemple ). Il peut ne pas être simple / possible à utiliser car je ne sais pas s'il existe une puce FIFO avec une interface simple (telle que SPI). Les FIFO que je connais ont une interface parallèle.

2) Partagez le SRAM mentionné de Microchip avec deux maîtres SPI (dans deux uControllers). Lors de la première utilisation, les ports SPI des autres uController doivent être à haute impédance et opposés lorsque le deuxième uController utilise la SRAM. Vous aurez besoin d'une interface de prise de contact simple entre les uControllers (quelque chose comme la demande de lecture / lecture terminée / lignes occupées). Cela peut être implémenté en utilisant 2 ou 3 connexions unidirectionnelles entre les uControllers. La limite, c'est votre imagination.


1

Soit dit en passant, une approche non encore mentionnée pour une utilisation avec des mémoires parallèles consiste à avoir deux dispositifs ou plus dotés de tranches de temps fixes pour accéder aux données. Cette approche a été utilisée dans de nombreux ordinateurs basés sur 6502 fabriqués à la fois par Apple, Commodore et certains autres fournisseurs (pas, fait intéressant, Atari). Le microprocesseur 6502 populaire utilisait une horloge biphasée et effectuait toujours ses accès à la mémoire sur la seconde moitié de chaque cycle (l'adresse était disponible pendant la première moitié, mais les données seraient écrites pendant la seconde moitié ou verrouillées à la fin de la seconde moitié). Les machines Apple et Commodore utiliseraient ainsi pendant la première moitié de chaque cycle de mémoire une adresse générée par les circuits vidéo, verrouillant les données à la fin de la moitié; au cours de la seconde moitié de chaque cycle, ils utiliseraient l'adresse générée par la CPU,

Cette approche nécessitait une mémoire deux fois plus rapide que ce qui aurait été nécessaire sans entrelacement de la mémoire, et a nécessité l'ajout de pilotes à 3 états sur les sorties d'adresse du processeur (les sorties d'adresse du 6502 étaient toujours pilotées haut ou bas) mais cela fonctionnait par ailleurs très bien. pour mettre la même mémoire à la disposition du processeur et des circuits externes.


0

Il existe plusieurs façons de faire ce que vous voulez.

  • Programmer un autre "buffer MCU" pour s'asseoir entre vos deux CPU et mettre en tampon la communication - quelque chose comme le "convertisseur de Baudrate" montré sur http://www.romanblack.com/PICthread.htm . Programmez-le pour présenter "dual-port" une interface indépendante de chaque côté. La SRAM (interne ou externe) est directement connectée uniquement à cette MCU tampon.
  • Reprogrammer votre MCU «émetteur» pour stocker un tampon dans SRAM, au lieu de l'envoyer directement au récepteur, et agir comme un esclave pour extraire les données de ce tampon et l'envoyer uniquement lorsque votre MCU «récepteur» (agissant en tant que maître) le demande il. Le tampon SRAM (externe ou interne) est directement connecté uniquement à l'émetteur. (c.-à-d., combinez la fonctionnalité de ce que fait actuellement votre récepteur et du "MCU tampon" ci-dessus).
  • Utilisez certaines lignes GPIO, comme l'ont suggéré Andrew Kohlsmith et mjh2007, pour arbitrer entre l'émetteur et le récepteur qui ont accès à une puce SRAM externe partagée de 32 Ko comme la RAMTRON FM24C256.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.