Peter and Duane, can you mention what features are important to you?
The SDRAM design is working on all boards that we built in last the few weeks. They all boot/run the ZOG FIBO program from SDCARD for example. I just want to spend a few hours with them today to ensure that the entire memory range works on all boards before they are ready "for customer shipment" or FCS.
The SDRAM driver is already available in the ZOG thread and I will post a frozen copy of that in this thread. One of my high priorities is getting a flashy ZOG demo running. Nick I owe you some ZIPs of software and hardware documents.
The boards have been delayed by the PS2 keyboard/mouse interface ports. The ports will not be "officially supported" on today's boards. The keyboard or mouse work beautifully one at a time. You just can't use them plugged in simultaneously today.
I'll post software for using either mouse or keyboard in the the one mouse port later. The keyboard port today should be avoided for anything but a single ADC channel since using both pins on that port requires burning the AVR "reset pin as I/O" fuse today.
A new Propeller based I2C Peripheral Playground board will be designed to provide simultaneous keyboard/mouse and other features such AVR programmable by the on-board Propeller for ADC and other functions.
When current SDRAM board stock is sold, a new "half size" board will replace it that removes the Keyboard/Mouse and VGA connectors.
I know you have set your sights on uCLinux but in the mean time...
So much to do
Ultimately, a large application with a richly textured TV User Interface would be a great demo. I really like 3D buttons and graphics. The SDRAM can be read at 5.3MB/s so this is not an unrealistic goal.
My own plan is to attach a 3.5" SPI interface touch-screen LCD at some point to use as a pluggable PDA for my car - think detachable face-plate radio.
My interest is mostly the SDRAM. That and the ASM routines that speak to the chip. Although for testing the SD card interface would be a big help. I'm looking at this as an eval board for the SDRAM. I've got an application where I need a high-speed buffer and this looks the part.
I know you've had some issues getting the i2c mouse/keyboard working together. Presently, I've got no interest in either of those.
My interest is mostly the SDRAM. That and the ASM routines that speak to the chip. Although for testing the SD card interface would be a big help. I'm looking at this as an eval board for the SDRAM. I've got an application where I need a high-speed buffer and this looks the part.
Hi Peter,
There some boards that are just SDRAM and SDCARD.
I'll attach a clean copy of the SdramCache.spin driver for you later. The interface is based on buffering and the address for access is really all you need to pass to the PASM mailbox for access. If the buffer at the address is not in the cache line table, the buffer gets swapped (write-back/read) with HUB and SDRAM memory.
I'm thinking a richly textured video driver needs to be developed which uses cached SDRAM for filling video lines - this is one reason why the VGA option is on the SDRAM board. Of course ZOG can use TV since SDCARD is available with that.
After a TV driver is ready a split SdramCache.spin that keeps 2 caches could be used for ZOG and video. The ZOG version would be time-shared as you mentioned, but splitting the cache into 2 would help performance.
Maybe it's wishful thinking, but it seems like things that are more impossible have been done around here.
Any rough price yet? I might actually be interested in buying one of these....Having 32MB's of extra RAM could open up a ton of possibilities. We could finally have a REAL Prop computer that could run graphic intensive programs and even have its own OS...It must have been a pain to get the SDRAM to work(No easy feat to communicate with SDRAM, you have all these timing issues, plus the constant refresh)
Nick and I have discussed pricing briefly. Nick will be answering this question.
As far as "open up a ton of possibilities" .... Yes, I absolutely agree.
Hopefully more and more people will be interested in this ton of possibilities.
Just an update, I have boards on hand, I'm waiting for 2 parts (4.7k Resistor Network & TV Audio connector), which I should get in a few days. There will be 3 versions available;
1 - SDRAM + SD($49.95)
Includes 32MB SDRAM and microSD
2 - SDRAM + VGA ($49.95)
Includes 32MB SDRAM, VGA connector (but no microSD), and PS/2
3 - SDRAM + SD + TV ($59.95)
Includes 32MB SDRAM, TV connector, microSD, and PS/2
This will be an extremely limited release, I only have 4 boards available. There will be a real product release in about a month, but I want to give advanced users a chance to try 32MB as soon as possible. I'll update this thread when it's available!
I've attached an Sdram Test archive that demonstrates the SdramCache.spin driver and allows comprehensive test and debug utilities. You must use BST or BSTC to build the program because of the #define options. I could create an unsupported version for Propeller Tool if necessary.
Thanks for the code. I haven't looked at it yet, but using bst isn't a problem for me. I'm running 0.19.3 I haven't checked lately for updates. Do you think that will work?
I've already ordered my board. I hope to get testing this right away.
My goal is to use the SDRAM as buffer space for some burst data that's too fast for the SD card directly. I'll let you know how I get on. Maybe I'll be able to setup a FIFO if my time between writes is large enough or if I can afford a small buffer on the Prop where things can launch/land.
Thanks for the code. I haven't looked at it yet, but using bst isn't a problem for me. I'm running 0.19.3 I haven't checked lately for updates. Do you think that will work?
I've already ordered my board. I hope to get testing this right away.
My goal is to use the SDRAM as buffer space for some burst data that's too fast for the SD card directly. I'll let you know how I get on. Maybe I'll be able to setup a FIFO if my time between writes is large enough or if I can afford a small buffer on the Prop where things can launch/land.
SDRAM is definitely more painful then SRAM - and I am jealous of the 32MB of memory
Ravenkallen, I feel I should point out that there has been a "REAL Prop computer that could run graphic intensive programs and even have its own OS" available since June '09 - see the original "Morpheus" thread for more info.
Any rough price yet? I might actually be interested in buying one of these....Having 32MB's of extra RAM could open up a ton of possibilities. We could finally have a REAL Prop computer that could run graphic intensive programs and even have its own OS...It must have been a pain to get the SDRAM to work(No easy feat to communicate with SDRAM, you have all these timing issues, plus the constant refresh)
Ravenkallen: As Bill has said, we have prop OSes running for a considerable time. This and other SRAM boards just open up the prop to bigger and better things. Remember, the prop is supposed to be a micro not a processor, but we have just decided that it can do the processor job quite nicely anyway.
It's hard to beat the cost per MB of SDRAM. Can't wait to test 128MB chips
Here is a .zip package for the TV-Mouse demo I use for testing on the SDRAM PS2 combo board. Sorry it is not as clean as the SdramTest package I posted. I'll make it pretty and more readable later.
The demo only supports wheel-mouse types. I may work on the older mouse type later when I have time. Only the "MOUSE" port is supported for now. Do not connect anything into the "KEYBOAD" port until the atTiny85 ships with the bootloader.
It is possible to use a keyboard in the "MOUSE" port with a Propeller software change. I'll release a version of that next week.
Where can I find a description of these boards? I've looked at the first post but it doesn't give a lot of details. I assume these are add-on boards. What do they require of the host processor other than lots of pins? Are there any requirements for which pins have to be dedicated to the SDRAM interface?
{{
=====================================================================
Any memory interface can be used given enough pins; a parallel
bus interface is challenging since Propeller only has 32 pins.
An 8 bit data bus is a reasonable trade for pin use/performance.
With cache a bus width > 8 bits is best if possible.
This SDRAM solution uses 20 propeller pins.
for A0-12, BA0-1, CS*, CLK, RAS*, CAS*, D0-7 (CKE is pulled high).
The CS* and DQM pins are permanently pulled low for a 32Mx8 memory.
D0-7 on P0-7
A0-7 on P0-7 via ALE on P15
A8-14 on P8-14
SDRAM ALE on P15
SDRAM CLK on P24
SDRAM RAS on P25
SDRAM CAS on P26
SDRAM WE* on P27
With this design, there are 8 Propeller pins (P16-23) free for other IO.
Current pin usage: P0-15 & P24-27 SDRAM, P28-29 I2C, P30-31 Serial Port.
=====================================================================
}}
I don't have pictures of a stuffed board right now. Nick is working on that. Here is an example of the bare board:
I believe Nick is working on a GadgetGangster project page. The URL on the board's silkscreen exists but is not populated just yet.
@David - everything jazzed said. More details, photos, etc., upcoming.
These boards 'could' be used with another microcontroller, but I think it's a fair amount of work to get them working & the effort has been on the Prop. They fit on the Propeller Platform, but you could use them with something else, they use standard spacing & fit on a breadboard.
@Ray & others - I can take no credit for the design, this is jazzed's genius. I'm excited about it, though - the objects he showed me for using it were simple enough even for me. Having a ton of ram available opens up a lot of new possibilities. Maybe even nethack!
These boards 'could' be used with another microcontroller, but I think it's a fair amount of work to get them working & the effort has been on the Prop.
Sorry, I guess I wasn't clear. I wasn't interested in using the board with a different microcontroller, just a different Propeller board (like the C3). Now that I see how many pins are required I guess that won't be possible anyway. Maybe it's time to order a Propeller Platform board! :-)
@Cluso and Bill...I didn't mean any disrespect by saying "real OS". Your OS's are just as real as anything out there. By real i mean one that is capable of running extremely large program, involving graphics...
@Nick...SO this particular batch of SDRAM modules are a limited supply? When do you guys expect a full production run???
Ravenkallen: No offence taken. I was just merely pointing out there are other prop oses running. I did not write an OS, but rather took others such as PropDos and PropCmd. Then I found Sphinx which was more for compiling on the prop but it had so many features for an OS it just made sense for it to be expanded. Unfortunately time has interfered
However, from your explanation, you are not meaning OSes but rather large programs. There are many of these using Bill's various RAM cache methods as well as the two C compilers which can handle large memory. Of course once you require large resolution graphics this complicates things, which is why Bill and I have concentrated more on using 2 props. I think you may find this could happen with Steve's boards too, even though that is not where he is starting from. It is just that this year we have really discovered what a prop or two can do.
Be warned... Never say the Prop cannot do something on this forum because you are likely to be eating prop chips!
I am not even certain the PropII will solve this because we will push it to it's limits too! So with PropII we will have nice HD graphics and memory and a main program but I bet we run out of cogs to add all the other things that will be required with this. Anyway, a second prop to do the slower I/O will be fine when it can be loaded by the PropII and no doubt we can also supply the clock too, so it could be a bare Prop (no eeprom & xtal).
I just wanted to clear up your apparent misunderstanding that large memory programs will "finally" be possible ... Cluso and I have had products capable of doing that for a LONG time, Dr_Acula has Dracblade, there is a three-prop design in Germany, Steve is bringing out a 32MB board... and Andre had Hydra+memory card and now C3
As for graphics, Morpheus has been doing high resolution bitmapped VGA graphics for about 2.5 years now (and has been available for sale since June '09 UPEW)
I am afraid that single-bit wide SPI ram does not have the bandwidth to do high resolution VGA graphics, however bitmapped TV graphics from SPI ram is barely possible on C3, PropCade, and other SPI-ram utilizing designs.
UPDATE: After gulping down some coffee, I just spent some quality time with a calculator - actually 2 color 320x200 TV or VGA bitmap graphics with the frame buffer being in two single channel SPI ram's running at 10Mbps IS possible, if you are willing to put up with very slow screen updates. Actually four colors per pixel is possible if you are willing to give up updating the screen.
If the SPI ram could be read at 20Mbps, 320x200 4 colors per pixel would be possible with very slow updates, using four chips. This would probably need two cogs and using counters just for reading the memory.
Steve's board should allow for 4 pin high res VGA :-)
FYI, high-res graphics should be possible on 8-bit wide SPI ram board using 8 chips and 10 pins, however updating the screen would be very slow.
@Cluso and Bill...I didn't mean any disrespect by saying "real OS". Your OS's are just as real as anything out there. By real i mean one that is capable of running extremely large program, involving graphics...
@Nick...SO this particular batch of SDRAM modules are a limited supply? When do you guys expect a full production run???
Comments
How are these boards coming along? I'm interested in buying one to start working with the SDRAM and prop combo.
I checked Nick's site but couldn't find anything matching this. Did I miss it?
This board looks great, and very useful.
Thanks,
Peter
Thanks for working on it.
Duane Degn
I'll get them back this weekend and they should be available Tuesday. When they're up, I'll also update the thread.
The SDRAM design is working on all boards that we built in last the few weeks. They all boot/run the ZOG FIBO program from SDCARD for example. I just want to spend a few hours with them today to ensure that the entire memory range works on all boards before they are ready "for customer shipment" or FCS.
The SDRAM driver is already available in the ZOG thread and I will post a frozen copy of that in this thread. One of my high priorities is getting a flashy ZOG demo running. Nick I owe you some ZIPs of software and hardware documents.
The boards have been delayed by the PS2 keyboard/mouse interface ports. The ports will not be "officially supported" on today's boards. The keyboard or mouse work beautifully one at a time. You just can't use them plugged in simultaneously today.
I'll post software for using either mouse or keyboard in the the one mouse port later. The keyboard port today should be avoided for anything but a single ADC channel since using both pins on that port requires burning the AVR "reset pin as I/O" fuse today.
A new Propeller based I2C Peripheral Playground board will be designed to provide simultaneous keyboard/mouse and other features such AVR programmable by the on-board Propeller for ADC and other functions.
When current SDRAM board stock is sold, a new "half size" board will replace it that removes the Keyboard/Mouse and VGA connectors.
What would constitute a "flashy ZOG demo"?
I know you have set your sights on uCLinux but in the mean time...
So much to do
Ultimately, a large application with a richly textured TV User Interface would be a great demo. I really like 3D buttons and graphics. The SDRAM can be read at 5.3MB/s so this is not an unrealistic goal.
My own plan is to attach a 3.5" SPI interface touch-screen LCD at some point to use as a pluggable PDA for my car - think detachable face-plate radio.
My interest is mostly the SDRAM. That and the ASM routines that speak to the chip. Although for testing the SD card interface would be a big help. I'm looking at this as an eval board for the SDRAM. I've got an application where I need a high-speed buffer and this looks the part.
I know you've had some issues getting the i2c mouse/keyboard working together. Presently, I've got no interest in either of those.
p
There some boards that are just SDRAM and SDCARD.
I'll attach a clean copy of the SdramCache.spin driver for you later. The interface is based on buffering and the address for access is really all you need to pass to the PASM mailbox for access. If the buffer at the address is not in the cache line table, the buffer gets swapped (write-back/read) with HUB and SDRAM memory.
Cheers.
Great work! As far as snazzy demo, I'd really like to see a platform that could run Nethack...
A board with SDRAM and SDCARD only would suit me fine. I look forward to seeing the code and hopefully buying a board later this week.
p
"...a large application with a richly textured TV User Interface would be a great demo."
It occurred to me you would want to show off the graphics aspect after I posted.
How will we deal with contention between the graphics driver and Zog for access time to the SDRAM?
Do we end up with Zog only being able to execute code from SDRAM between video frames?
Is Zog even running code from SDRAM anyway or just using it as the frame buffer?
I'm thinking a richly textured video driver needs to be developed which uses cached SDRAM for filling video lines - this is one reason why the VGA option is on the SDRAM board. Of course ZOG can use TV since SDCARD is available with that.
After a TV driver is ready a split SdramCache.spin that keeps 2 caches could be used for ZOG and video. The ZOG version would be time-shared as you mentioned, but splitting the cache into 2 would help performance.
Maybe it's wishful thinking, but it seems like things that are more impossible have been done around here.
Cheers.
--Steve
Nice work Jazz and Nick!!
As far as "open up a ton of possibilities" .... Yes, I absolutely agree.
Hopefully more and more people will be interested in this ton of possibilities.
Thanks !!
1 - SDRAM + SD($49.95)
Includes 32MB SDRAM and microSD
2 - SDRAM + VGA ($49.95)
Includes 32MB SDRAM, VGA connector (but no microSD), and PS/2
3 - SDRAM + SD + TV ($59.95)
Includes 32MB SDRAM, TV connector, microSD, and PS/2
This will be an extremely limited release, I only have 4 boards available. There will be a real product release in about a month, but I want to give advanced users a chance to try 32MB as soon as possible. I'll update this thread when it's available!
Thanks for the update. Can I get on the list for one of the SDRAM and SD card boards?
I'm ready to buy, just need something to purchase and a place to pay. Have VISA will spend...
One is all I'm looking for at this point.
Thanks,
Peter
I've attached an Sdram Test archive that demonstrates the SdramCache.spin driver and allows comprehensive test and debug utilities. You must use BST or BSTC to build the program because of the #define options. I could create an unsupported version for Propeller Tool if necessary.
Cheers.
--Steve
Thanks for the code. I haven't looked at it yet, but using bst isn't a problem for me. I'm running 0.19.3 I haven't checked lately for updates. Do you think that will work?
I've already ordered my board. I hope to get testing this right away.
My goal is to use the SDRAM as buffer space for some burst data that's too fast for the SD card directly. I'll let you know how I get on. Maybe I'll be able to setup a FIFO if my time between writes is large enough or if I can afford a small buffer on the Prop where things can launch/land.
I'm really looking forward to working with this.
Thanks,
Peter
The main item for building the code with BST is to enable "non-parallax compatible extensions" in Menu Bar -> Tools -> Compiler Preferences.
Your project sounds very useful. I hope the hardware/code can serve as a handy reference design for you.
If you have any questions, I'll be here with answers.
Best of luck and thanks,
--Steve
SDRAM is definitely more painful then SRAM - and I am jealous of the 32MB of memory
Ravenkallen, I feel I should point out that there has been a "REAL Prop computer that could run graphic intensive programs and even have its own OS" available since June '09 - see the original "Morpheus" thread for more info.
p.s.
Another great product for GadgetGangster!
Ravenkallen: As Bill has said, we have prop OSes running for a considerable time. This and other SRAM boards just open up the prop to bigger and better things. Remember, the prop is supposed to be a micro not a processor, but we have just decided that it can do the processor job quite nicely anyway.
It's hard to beat the cost per MB of SDRAM. Can't wait to test 128MB chips
Here is a .zip package for the TV-Mouse demo I use for testing on the SDRAM PS2 combo board. Sorry it is not as clean as the SdramTest package I posted. I'll make it pretty and more readable later.
The demo only supports wheel-mouse types. I may work on the older mouse type later when I have time. Only the "MOUSE" port is supported for now. Do not connect anything into the "KEYBOAD" port until the atTiny85 ships with the bootloader.
It is possible to use a keyboard in the "MOUSE" port with a Propeller software change. I'll release a version of that next week.
Cheers.
--Steve
.
The 32MB SDRAM board is GadgetGangster PropellerPlatform compatible and designed for prototyping flexibility.
Assembled variations of the basic board are available now in limited quantities.
SDRAM only
SDRAM+VGA
SDRAM+TV+SDCARD+I2C-AVR-PS2
The current feature set is described in the top post of page 4 here http://forums.parallax.com/showthread.php?t=124418&page=4
The summary is shown here for convenience.
The pin-out for the board is like this:
{{ ===================================================================== Any memory interface can be used given enough pins; a parallel bus interface is challenging since Propeller only has 32 pins. An 8 bit data bus is a reasonable trade for pin use/performance. With cache a bus width > 8 bits is best if possible. This SDRAM solution uses 20 propeller pins. for A0-12, BA0-1, CS*, CLK, RAS*, CAS*, D0-7 (CKE is pulled high). The CS* and DQM pins are permanently pulled low for a 32Mx8 memory. D0-7 on P0-7 A0-7 on P0-7 via ALE on P15 A8-14 on P8-14 SDRAM ALE on P15 SDRAM CLK on P24 SDRAM RAS on P25 SDRAM CAS on P26 SDRAM WE* on P27 With this design, there are 8 Propeller pins (P16-23) free for other IO. Current pin usage: P0-15 & P24-27 SDRAM, P28-29 I2C, P30-31 Serial Port. ===================================================================== }}I don't have pictures of a stuffed board right now. Nick is working on that. Here is an example of the bare board:
I believe Nick is working on a GadgetGangster project page. The URL on the board's silkscreen exists but is not populated just yet.
These boards 'could' be used with another microcontroller, but I think it's a fair amount of work to get them working & the effort has been on the Prop. They fit on the Propeller Platform, but you could use them with something else, they use standard spacing & fit on a breadboard.
@Ray & others - I can take no credit for the design, this is jazzed's genius. I'm excited about it, though - the objects he showed me for using it were simple enough even for me. Having a ton of ram available opens up a lot of new possibilities. Maybe even nethack!
@Nick...SO this particular batch of SDRAM modules are a limited supply? When do you guys expect a full production run???
However, from your explanation, you are not meaning OSes but rather large programs. There are many of these using Bill's various RAM cache methods as well as the two C compilers which can handle large memory. Of course once you require large resolution graphics this complicates things, which is why Bill and I have concentrated more on using 2 props. I think you may find this could happen with Steve's boards too, even though that is not where he is starting from. It is just that this year we have really discovered what a prop or two can do.
Be warned... Never say the Prop cannot do something on this forum because you are likely to be eating prop chips!
I am not even certain the PropII will solve this because we will push it to it's limits too! So with PropII we will have nice HD graphics and memory and a main program but I bet we run out of cogs to add all the other things that will be required with this. Anyway, a second prop to do the slower I/O will be fine when it can be loaded by the PropII and no doubt we can also supply the clock too, so it could be a bare Prop (no eeprom & xtal).
It still hasn't lead me to a working solution to my empty beer can powered lawnmower project.
(40 DIPS, please)
edit
(84 PLCC P1.5s, PPPPLLLLLEEEEEAAAAASSSSSEEEE)
I just wanted to clear up your apparent misunderstanding that large memory programs will "finally" be possible ... Cluso and I have had products capable of doing that for a LONG time, Dr_Acula has Dracblade, there is a three-prop design in Germany, Steve is bringing out a 32MB board... and Andre had Hydra+memory card and now C3
As for graphics, Morpheus has been doing high resolution bitmapped VGA graphics for about 2.5 years now (and has been available for sale since June '09 UPEW)
I am afraid that single-bit wide SPI ram does not have the bandwidth to do high resolution VGA graphics, however bitmapped TV graphics from SPI ram is barely possible on C3, PropCade, and other SPI-ram utilizing designs.
UPDATE: After gulping down some coffee, I just spent some quality time with a calculator - actually 2 color 320x200 TV or VGA bitmap graphics with the frame buffer being in two single channel SPI ram's running at 10Mbps IS possible, if you are willing to put up with very slow screen updates. Actually four colors per pixel is possible if you are willing to give up updating the screen.
If the SPI ram could be read at 20Mbps, 320x200 4 colors per pixel would be possible with very slow updates, using four chips. This would probably need two cogs and using counters just for reading the memory.
Steve's board should allow for 4 pin high res VGA :-)
FYI, high-res graphics should be possible on 8-bit wide SPI ram board using 8 chips and 10 pins, however updating the screen would be very slow.