0
\$\begingroup\$

I'm studying the development of a hardware composed of modules, I initially thought of a serial bus like ICSP, I2C or even CAM to communicate between modules, but I wonder if it could not use a ram in common between processes to build circular buffers for Each module and its serialized data structures, so the modules would be present through reserved spaces to identify them and each circular buffer would be defined according to the presence of the module.

These modules would be, for example, a GPS controlled by a Cortex-M0 (there being an alternative to an ESP8266 A7), an ESP8266 A6 would be used for cellular communication and another for WiFi communication, thus the GPS module would be depositing in its circular buffer the collected data And preprocessed GPS, the other Wireless modules would also maintain communication through their circular buffers in this ram memory, with pinnacles connected to the central cortex-M triggering ISR alerts when hearing emergency cases that need to be prioritized.

Well the big question is how to use a ram memory shared between these modules, I know there are Cortex-M line chips that allow such features, but would there be such a possibility with the ESP8266?

Assuming two scenarios:

A first one where all the modules would be based on Cortex-M, choosing the most suitable to work respectively GPS data collection, GSM / GPRS Communication and WiFi / BlueTooth Communication, and finally a central processing and logger module via SDCard.

And a second module has this mix between Cortex-M and ESP8266, with ESP8266 being responsible for Wireless and GPS communication, and Cortex-M for central processing and datalogger.

What would then be the Cortex-M models available for use with external ram memory, how to adapt the ESP8266 for such use? And Of course what external RAM could be used?

| improve this question | |
\$\endgroup\$
5
\$\begingroup\$

There are many issues here. The first is that many of these modules communicate with serial interfaces already, so if you want to dedicate a memory interface to each device, you'll have to add some logic (maybe even extra microcontrollers) to translate. Then, most RAMs are single ported, so you can't connect them directly to two devices. Either you will need an arbiter or you will need to get very expensive (and rather small) dual port RAM.

Or you can just use the hardware serial ports on your microcontroller and implement your circular buffers with software in the chip's on board RAM.

Now, if your chip doesn't have enough hardware serial ports for all the devices that you want to connect, then it might be worthwhile to add a secondary peripheral microcontroller that has more serial ports and can perform operations on behalf of the main controller and then aggregate responses. Something like the Atmel xmega series could be a good choice as these chips have gobs and gobs of serial ports (up to 8 UARTs, multiple I2C and SPI controllers, decent amount of RAM, will run at 32 MHz on the internal oscillator, etc.). Then all you need is a relatively fast interface between the two microcontrollers. A fast UART or I2C bus would be reasonable. Or you could even use USB if your main controller can act as a USB host.

| improve this answer | |
\$\endgroup\$
  • 2
    \$\begingroup\$ Pseudo-dual porting is also possible using temporal or spatial banking (e.g., the memory access speed being twice as fast as each microcontroller's access speed or at each time unit each microcontroller is guaranteed never to access a conflicting bank. Both of these might be considered a simplistic form of arbitration. \$\endgroup\$ – Paul A. Clayton Nov 14 '16 at 0:02
  • 2
    \$\begingroup\$ Yeah, these are both forms of arbitration that use some additional logic to 'share' a single port memory between multiple devices. To implement something like that here, you would probably need to use a CPLD or FPGA. \$\endgroup\$ – alex.forencich Nov 14 '16 at 2:00
  • 1
    \$\begingroup\$ The arbitration could be by software agreement (e.g., even and odd access cycles). It might also be worth noting that some SRAM memories are not true dual ported but provide separate read and write channels; this would allow alternating read and write phases (assuming the added latency was acceptable). \$\endgroup\$ – Paul A. Clayton Nov 14 '16 at 3:38
  • \$\begingroup\$ Bem, parece então que a solução melhor é conectar via um protocolo serial entre eles e usar a maior velocidade possível, o ICSP vai a 15Mbps então seria o mais indicado. O controlador principal seria responsável por gerir o buffer circular através de uma ISR que identifica a origem e preenche para que outras threads possam consumi-lo. \$\endgroup\$ – Delfino Nov 14 '16 at 22:55
1
\$\begingroup\$

There is a kind of RAM used for this sort of thing, it's dual ported memory. A single bank of RAM that can have two or more independent interfaces to it so multiple devices (or more accurately multiple memory locations) can be accessed simultaneously.

However, there is a catch: I've never seen any dual (or multi) port memory that didn't use a parallel interface (so 20+ pins each, 8/16/32 etc. for data, several for controls, and lots for the memory addresses).

As it sounds like your dealing with serial (and slow serial at that), I think you'd be better served by just using the onboard memory of a micro and implementing the buffer in software (and unless you needs tens of megabits, you can probably even use the onboard flash, although write endurance may be an issue - TI makes some chips with, in addition to the SRAM, FRAM instead of flash, they claim something like a trillion R/W cycles)

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ What is the code of this ram? How does it connect to the controllers? \$\endgroup\$ – Delfino Nov 14 '16 at 22:56
  • \$\begingroup\$ @Delfino You'll have to be a bit more specific, what do you mean by "the code of [the] ram"? Different chips have different interfaces, there's no one-size-fits-all interface. A cheap low power SRAM chip will be very different compared to a high performance SRAM chip, one might use I2C and run at a few hundred kbps, the other might be in a massive BGA package screaming along at 150Gbps (e.g. QDR IV). Consequentially, the software required will be very different between the two. "RAM" is a category, like "automobile", "dual-port RAM" is a sub category, like "truck", not a specific chip. \$\endgroup\$ – Sam Nov 15 '16 at 10:09
  • \$\begingroup\$ When I said code, I meant code for identifying some model of the chip that is of this type of RAM. However I am already determined to use a microcontroller to manage the communication bus between the modules by sharing the media. \$\endgroup\$ – Delfino Nov 17 '16 at 15:52
  • \$\begingroup\$ Do you perhaps mean a part number? Because there are literally thousands of different ones, and probably a dozen different interfaces. \$\endgroup\$ – Sam Nov 17 '16 at 20:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.