I wish to store a large amount of data on the Edison onboard Static RAM. Within a C written program (written within the IDE) about how much Static RAM is available for a very small C program. Is a GB available for example?
Yes I know that, what I want to know is how much is available when say The "Hello World" C program is running.
Pointers to scripts are no use. I don't have a running system.
Can somebody just check on their system.
I did a quick test to see how much free RAM there is available after running a small blink test code. The total RAM memory is 983068KB. Before running the test code, the total free RAM memory was 852472KB. After running the test code and while it was running, the total free RAM memory was 852332KB.
I hope you find these results useful.
Its a long story, but I "do" S100 bus boards for myself and others. See for example
http://s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm S100 Computers - 80486 CPU Board
http://s100computers.com/My%20System%20Pages/68030%20Board/68030%20Board.htm S100 Computers - 68030 CPU Board
While I have a 32/64 MB Static RAM board see:-
http://s100computers.com/My%20System%20Pages/80386%20-%2032MG%20RAM%20Board/32MG%20Static%20RAM%20Bo... S100 Computers - 32 MB RAM Board
I would like to get to GB capacities. I'm not up to designing a DDRAM based board (yet) so I thought I could use the large amount of RAM on 1,2,3 or 4 Edison modules. There are just enough pins to have 32 bit access to transfer the CPU data to the Edison onboard RAM. This way the refresh is transparent to the S100 system. Ultra high speed is not required with this hardware.
Static RAM is very expensive and power consuming (when active). Thus, modern SoCs operates with hundreds kBytes of such memory, in some cases up to few MBytes.
I would like to get to GB capacities.
My point that on modern systems you need to use external static RAM storage to have dozens of MBytes to Gbyte to Gbytes of it.
Intel Edison here is not different to the rest of the SoCs on the market.
Yes that is why I'm using the Edison setup. Hopefully it will give me access to GB RAM storage without figuring out a DRAM board with a FPGA/refresh setup
I think I understand what you want to do:
- instead of creating a DRAM interface you want to use the DRAM inside the Edison
Not sure if you want the Edison to mimic a SRAM interface (so you can execute code directly from it)? Or create a sort of backup or swap storage, f.i. by creating a DMA interface on your processor?
If you want the first (what I get from 'transparent'): you can not acces the Edison memory directly from the pins. You can write a piece of software that implements a SRAM interface. But the latency of the Edison (even when running RT kernel) will make that hard, or very slow.
Yes its to store and execute things like 80486 code in the Edison RAM. The S100 CPU board should not know it not "regular" RAM. I know it's slow but the CPU clock speed is only 10-20MHz in these (old) systems. The Edison is 100X that number.
In other words, you need to implement an SRAM interface in software. So that would be (I guess) WR/~RD, ~EN and muxed data/address bus. After applying a RD + EN and address, the data needs to appear within 100ns or so. That would then be your hard realtime requirement. Realistically, that can't be done. AFAIK with a preempt_rt version of linux you will have probably 1 - 10 us latency. If you remove the kernel and write your own code to implement the SRAM interface (I believe that is called in ring 0?) with interrupts disabled, maybe that would work, but I don't really believe that it will work.
You are probably much better off replacing your 40486 + SRAM by an Edison. The Edison is after all a complete computer.
Of course it can be done, it's a question of how fast the process is. You don't seem to know much about hardware or at least what I'm doing. For example I have a S100 bus board with an Edison that completely monitors the S100 bus running a 10mHz z80 CPU. All bus signals are trapped, the bus can be controlled by Edison software etc... If you have time read/see here.
http://s100computers.com/My%20System%20Pages/Edison%20II_CPU%20Board/Edison_II_CPU%20Board.htm S100 Computers - Edison CPU Board
The trick is to put the CPU in a wait state while the hardware catches up. There is no limit how long that ca be.....
Anyway the point of this tread is not to discuss hardware - I know that, the point is to get advice from a C/IOT programming expert as to what way is the fastest/most efficient way to allocate Edison onboard RAM and write a routine to quickly store /retrieve long words from it. Again, is the a way to do it in an assembly routine. Has anybody done anything like this.
PS This is a hobby, It's no fun just to program a necked Edison
Well, that may be true. Or maybe your question is just not that clear.
AFAIK SRAM does not let the CPU WAIT.
Otoh you seem to be smart enough. So I assume you already know how to allocate a block of memory and how to move data from one location to another. If you do this in C it will be almost as fast as can be.
The problem is: you want to move to/from the GPIO's. You may have already tried to just toggle GPIO's to see how fast that is (slow, not sure 20 or 50us from user space). The fastest I got using mmapped gpio is in the order of 2us. This was using a C program from user space using the MRAA library see http://iotdk.intel.com/docs/master/mraa/gpio_8h.html mraa: api/mraa/gpio.h File Reference
It might get better get a bit if you bypass MRAA and steal bit of code from MRAA that does this. And even better if you write a kernel driver that does this.
And I guess you already know that the linux kernel does try to do other stuff than poll the RW/WR assigned GPIO, but if you don't mind locking up the kernel by disabling all interrupts while polling that will probably be the fastest.
The wait states are on the CPU's not the RAM. The data is sent to the Edison one long word at a time. The Edison puts its S100 bus CPU in await state. The Edison processes the data and writes it to its SRAM (whenever it want to). When done the Edison releases the wait state on the S100 bus CPU, the next long word is processed ete etc. Standard stuff done all the time in S100 bus systems.
Of course the wait states are on the CPU, where else. My point is: you want to replace SRAM by a Edison. But SRAM does not stretch the CPU clock or generate a WAIT signal to the CPU. SRAM is asynchronous.
Question: why do you think the Edison has SRAM? AFAIK it is DRAM. And why would that matter?