Looking to gauge interest in a project I'm starting.
Would be modular on breadboard. Build microprocessors modules, hook them up to a shared static ram memory module. Experimental not practical. To explore subjects like memory contention and arbitration logic.
I have 6x ATmega1284s microprocessors, and 8x 71256 32Kx8 static RAM chips.
Experiments to explore the following:
Can I build a small cluster from the microprocessors? How much shared memory contention goes on? What the best way to deal with that? Do I partition the memory so it's divided between shared and private per processor, or make it all shared?
Power consumption and sleep modes. The RAM is quite power hungry taking about 1/3 AMP per chip. The RAM chips do have a variety of low power sleep modes. As part of my exploring the memory contention do I also try and minimise power use?
In additional because I'm playing with things and experimenting I bought some I2C RAM, ferromagnetic ram, and FIFO shift registers. What can be done with those?
New to Arduino but a simplified block diagram to give you an idea of what I'm aiming for.
That being said, I think the concept is 10 years dated. As a hardware-by-training person, building an external memory controller for bulk SRAM is an interesting "mind exercise" but the problem extends beyond hardware into the economic and Arduino software build scripting. I find it "of interest" but with every uC having much valuable discrete electronics (UART, I2C, SPI) making full economic use across 6 separate Atmega1284 separate uC is not suggestive of easy utilization; that is, the hardware in each uC would need virtualization and that implies some minimum RTOS. As the "Arduino" ecosystem is primarily built around a single physical chip with one or more cores, multiple physical chips do not fit into that paradigm.
Essentially, a Raspberry Pi device is a far more power efficient and economic way of achieving a multi-core, large RAM footprint with rich peripheral capabilities and true OS.
Now, as you have hardware already, I do hope you will move forward and perhaps a few forum members will find interest; by all means, I for one, would appreciate reading about your progress.
It looks interesting but not all microprocessors give you external access to its data bus. This sounds like a two year project, depending on your skill set. Take a look at using FRAM to store your data, (I use them on most of my projects), 32K x 8 and virtually no power draw and they are non volatile, with trillions of r/w cycles. Change the micro to an 8085 or similar device and there is your circuit. When we did this many years ago we used an interrupt priority controller for multiple access control. I think by the time you get through all the arbitration and bit control using something like CAN would be faster and more reliable. Good luck and let us know how you work.
The ATmega1284 is not one of the AVRs that directly supports an external memory interface. (unlike, say, the ATmega1280, or some of the XMega chips.)
Even on AVRs with the External SRAM interface are "synchronous" (send out your address and strobe, expect things to be done N clocks later) and lack the sort of "wait state generation" or "acknowledgement" setup that you'd want to handle contention between multiple processors.
I suppose you could do it all in software instead, but that doesn't seem like it would be very meaningful. (Hmm. Might be a good educational exercise, though, if that's what you're after.)
Hi guys. Thanks for the feedback.
I should have been clearer. The external memory is not seen as an extension of the internal memory of the microprocessor, but separate memory that can be accessed via software.
That 8 bit bi-directional address/data bus, and the control logic coming out of the microprocessor are a clue. All of that would be running off pins of the microprocessor.
That I am experimenting with multiple processors sharing the same memory and all the contention issues that brings also speaks to external memory rather than contiguous memory.
To read or write from this memory from any processor would involve a software call to a procedure passing local memory address start and end, external memory address start, and read or write. The code inside this function would have to deal with contention - is the memory free to use? I'm then left with things I have to deal with. If the memory is already i use do I wait, or try again later, or see if I can get the external contention logic to raise an interrupt with the microprocessor when its ready? This means any code calling for external memory access may have to wait for it to complete which means the code needs to be wait tolerant. There may even be a queue of memory access requests that build up within the chip all waiting for a turn at the memory. Which then raises another question, once the chip is granted memory access do I execute all the requests in the queue or just one? Multiple chips may have queues filling up, whats the best way to deal with that?
All that aside it opens up the possibility of the microprocessors passing each other information and requests by leaving each other messages in the shared memory. Which is a whole 'nother can of worms.
The project is not meant to be practical or real world. There are no sensors involved. It's more an exploration of the concept and undoubtably I will run into many issues along the way. Exploring the different possible solutions and the benefits and drawbacks of each is the experimental process.
Well, except that that's pretty much exactly how the external memory bus on microcontrollers that support it works. 16 bits of address, the high byte of which is multiplex with the (bi-directional) data bus.
Yep I'll be adding that to processors that don't inherently support it by using general purpose digital pins to perform the same function. I will then need software functions to access the external memory.
I'm interested more in hearing about your FRAM experience please.
When my FRAM arrived it was in over the top packaging I assumed was super anti-static, but it wasn't it was anti-moisture too. I haven't even opened the packaging yet. It makes me think once I open that package I have like 2 days to play with them before the FRAM chip dissolve in front of my eyes. Am I over-reacting as I usually do ?
I'm sticking to the ATmegas and Aurduino environment to start because it seems so simple. I'm not going to build anything that is usefull in a practical sense, it's more the journey that counts.
The simplicity of the Aurduino environment means I can concentrate on the chips on breadboard rather than learning toolchain and software packages. Just a single example to draw that picture I ended up using MS paint. I have downloaded Fritzing for breadboard diagrams, but it doesn't have the chips I need. Also downloaded LTspice with Bordodynov's parts libraries, but still not got everything I need. Too many chaining problems. Arduino's simplicity allows me to avoid long detours, so ATmegas for now. Also they are damn cheap the ATmega1284s are costing me ~ £6, memory chips were ~ £3, FRAM was most expensive at ~ £7, so not a large cash investment. Also buying through hole packages only. I know there are surface mount to through hole adapters, but I want to stick to through hole only.
Also I have to bear in mind clock frequencies. As those go up my literal bus wires on/between breadboards become a bigger problem. Sticking to ATmegas at 16MHz means I should avoid that issue ( I hope ). That frequency seems a bit of a sweet spot for what I'm trying to do.
Just a few suggestions. Delete the Frizzy, it be useless when you get a bit further down the line. For fun do your memory drawing showing all the interconnections, you will get the idea. I use KiCad on Linux Mint and it works great for schematic capture through generating Gerber files for PCB. It has design rule checking etc. It is not a weekend project learning it will take some time to learn. It is a full blown CAD without an autoroute which is good as I find errors when placing parts. There are many others, many such as Eagle limits the size etc of the board (not exactly sure) some others are great but after the trial period you need to pay. Start with simple schematics and go from there. There is a huge base on the internet that use it and offer help. Big hint to not flip packages, just rotate them.
Through hole devices are scarce and expensive. Start with something that has some simple SMD devices in it. Try with the larger packages such as 1206. A good soldering iron with a maybe 2mm or a bit smaller will be a good start. I use a 50 Watt Weller with Temperature control, works great. You will also need a pair of tweezers to handle the parts. For me an 8x pair of readers. You may be able to buy some practice boards. The first two weekends with it was very hard, but now I definitely prefer SMD, it is faster and easier to assemble. You can also get old boards remove and then put parts back on it to get a feel. The next thing you will need is a hot air gun with an adapter that will reduce the output to about 1/2".
For me the hardest thing was to connect my first unit, just like I2C EEPROM but with a WP (write protect) pin and very fast. It still has not melted. I downloaded a FRAM library: FRAM.cpp/h by Rob Tillaart GitHub - RobTillaart/FRAM_I2C: Arduino library for I2C FRAM , Spent a few minutes studying it then I loaded and examples, they worked immediately without any problems. Then I played with the WP pin, it works. There is some test code that will impress you on how fast it is. I mounted the Arduino Uno/NANO on a piece of plywood (painted white) with #2 sheet metal screws. Connected the parts with Dupont wires. The USB will more then power it. I then ran the test programs, it was impressive how fast it is. I have since written some code to dump the FRAM both in hex and ASCII to validate it, it was correct.
The modules I use are similar to the adafruit I2C units. There were no moisture warnings with my FRAM, the die was packaged in a soic 8 pin already mounted on the PC Board. I use hot water and soap to clean the boards and have had no problems doing that. If you you experimented with external EEPROM the odds are good the code will work with FRAM but because of the delays in the library it will be a bit slower. The only restriction on FRAM is you need to write or read a byte, no delays. As far as the eyes that is what the 8x readers are for. Very hard to find them.
Thanks for all the great feedback Gilshultz.
Frizzy fair enough. It's dreadful for 74HC and I don't want to spend a month or two learning how to make parts for it. I did see KiCad and Eagle on looking. I might give those a go. I'm on windows not Linux.
Through hole I'm sticking with. Yes on the scarcity, but between ebay and proper retailers like Mouser I've been able to source everything I want at reasonable cost. I stick with through hole for several reasons. An in law relative recently bought me Ben Eater's 8 bit breadboard computer kit. He is a crypto programmer but knows nothing about electronics, so we are building it together. He's enjoyed the bits we have built so far. I have a lot of old stock of 74HC through hole stuff, maybe 2-300 assorted chips. When I was younger I was a telecommunication electronic repair person working at the factory where the equipment was manufactured. Any faulty stuff came back to our repair department. Component level diagnosis and repair. Through hole and surface mount around 50/50. So I have diagnosed soldered and reworked both for a living. I'm older now, my eyesight is not good, surface mount is out of the question even with magifying glass help. The Ben Eater kit has like 15 large breadboards. If I need something that is very expensive through hole or unavailable I may consider SMD and an adapter board, but not if I can avoid it. Just my personal circumstances.
Your FRAM experiment sounds interesting. Did your FRAM come with giant moisture warnings? Thanks for the tip about the library. Once I've got bored of SRAM sharing I want to have a go with FRAM and 12C.
