Please investigate Atmel Dataflash 16Mbit AT45DB161D for 2.95 and Ramtron 128k X 8 FM25V10-G for 9.00.
RAMTRON prices have fallen 40% in the past year and a half. Phase-change memory will become the dominating type
for new memory, superseding FLASH.
I will be using both in new designs. That's all the freebies that I'm willing to pass along today
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/17/2010 9:15:43 AM GMT
The TriBlade is designed for the DIP8 W25X80 1MByte SPI Flash or W25X32 4MByte Flash although I see both are no longer stock items at DigiKey. I think Mike Green is the only one who has this working.
The Ramtron FM25V10-G is SPI and runs at 40MHz max. That means more than 250nS access time per byte providing the cog can clock at this rate. It just isn't going to cut the ice for me. And $9.00 is expensive too. May as well have another prop on the pcb and get the speed!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The Ramtron info was posted to illustrate the falling prices. Next year (NOW + 6 months), the cost will be half. My industry buddies all agree - Phase-Change is the way to go.
I included the FM25V10-G as a point of reference. Parallel memory is MUCH faster, as well as non-volatile. I guess the ease of managing ONE type of memory versus EEPROM, RAM, FLASH, etc for all purposes and uses is attractive to me.
No reflection on your thinking - apples and oranges here, I suppose.
Ramtron will not dominate until their prices are comparable, on a per bit basis, with Flash.
RAMBUS died due to exorbitant pricing, and if they don't learn, so will FRAM.
I am staying far away from FRAM until its price is within 5%-10% of FLASH and FRAM.
Using your example, you can buy more than 48Mbits of flash for the cost of 1Mbit of FRAM - which is not competitive.
There are even cheaper (per bit) Flash devices - for example, one can buy a 16Gbit (2GB) SD card for less than the cost of one Ramtron FM25V10-G
This makes the FRAM 16384 times as expensive as the SD card.
Mike Huselton said...
Cluso99,
Please investigate Atmel Dataflash 16Mbit AT45DB161D for 2.95 and Ramtron 128k X 8 FM25V10-G for 9.00.
RAMTRON prices have fallen 40% in the past year and a half. Phase-change memory will become the dominating type
for new memory, superseding FLASH.
I will be using both in new designs. That's all the freebies that I'm willing to pass along today
Bill,
Flash and FRAM are not the same thing. Of course flash memories will continue to dominate the market for flash memory until the prices are essentially equal. FRAM has some advantages and disadvantages and, where the advantages are sufficient for the price differential, it will dominate. Flash in the form of SD cards is still the cheapest form of semiconductor bulk memory, but its write speed is variable and unpredictable. Where that's an inconvenience, FRAM may well win out. With the prices of FRAM continuing to drop, it will take over more of the market currently filled with flash memory. FRAM still doesn't have the capacities of devices like Atmel's Dataflash, but I suspect that's not far off
I can see some places where even I'd use FRAM - but I can't see it competing with and replacing FLASH for a long time, and I did not want readers to think that was imminent.
Mike Green said...
Bill,
Flash and FRAM are not the same thing. Of course flash memories will continue to dominate the market for flash memory until the prices are essentially equal. FRAM has some advantages and disadvantages and, where the advantages are sufficient for the price differential, it will dominate. Flash in the form of SD cards is still the cheapest form of semiconductor bulk memory, but its write speed is variable and unpredictable. Where that's an inconvenience, FRAM may well win out. With the prices of FRAM continuing to drop, it will take over more of the market currently filled with flash memory. FRAM still doesn't have the capacities of devices like Atmel's Dataflash, but I suspect that's not far off
FRAM lifetime is in the order of tens of trillions of read-write cycles per device. Certainly about 10 years at nanosecond speeds. Flash isn't in this ballpark.
And, the point is, the devices are non-volatile. Data retention is forever over the device lifetime.
I guess I like the idea of stocking a universal device for all of my needs. The decision tree narrows to one technology choice with variants (I2C, Parallel, SPI).
Cost is not the deciding issue for me. I probably will last 10 years, same as FRAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/19/2010 3:14:28 AM GMT
I think we have the data to resolve this issue: What is the BEST method for transcieving data between the RamBlade and a software-compatible routine for:
A. Full Duplex
B. Half Duplex
C. Burst
I have an idea for all three, but I would like a consensus. Ideally, it should resolve itself into one choice.
Don't forget the higher clock (crystal) speeds needed at each end for testing (i.e. 80 mhz <> 100 mhz on send/receive).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/19/2010 3:36:48 AM GMT
Do you mean communicating to another prop? And an extension to this, meaning multiple devices, such as VGA, Keyboard, serial, etc?
Just for normal comms, you cannot go past FDX (FullDuplexSerial). However, if you want more than a single device (being 1 input and 1 output) then you need addressing info to be passed as well. This is where I thought about Beau's method, using 12 bits where the upper 4 were an address of the device you are communicating with. However, for streaming data (like passing an SD sector or something, it might be preferable to use 32 bits or even 36 bits).
Is this what you are getting at???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The first page of this thread has full details including description, block diagram, connections for various other boards, etc. Also how to use a TV and Keyboard using 1-pin each, etc.
There are a couple of points to mention again...
The normal prop pins for programming (P31,30) are used by the sram and cannot be connected when running, and are marked on the pcb as pI & pO. The connector will take a normal propplug.
The serial connection when running are on P23,22 and are marked I & O on the pcb (2 places). On the lower connections if you connect a propplug upside down it will work since the reset line is not connected.
The code in the eeprom is preloaded before shipping and should not need to be reprogrammed. To reprogram you will need to link the WE link to enable the eeprom to be written. This can be done by the normal download method from the propplug connected to P31,30 as mentioned above.
The eprom has code to boot a program directly from the SD card. Information about this is elsewhere in this thread and the code is published in the first few posts.
The microSD files are available from my website www.cluso.bluemagic.biz and should be copied to a freshly formatted SD card in FAT16 with 32KB clusters (the default). This is because the files MUST be contiguous (sequential).
The SD contains a self test program for the RamBlade. It reports files missing - that is OK.
The SD contains an AUTOEXEC.BAT file which has ZICOG.BIN as the program to automatically run. However this is not on the SD, but ZICOG150.BIN is. If you want Zicog to run automatically, copy or rename ZICOG150.BIN to ZICOG.BIN or modify AUTOEXEC.BAT to ZICOG.BIN. Alternately, use the next step to run zicog.
When the RamBlade boots it expects a terminal connected to P23,22 and you will see a repeated (slow) loop being executed. Hitting "esc" on your keyboard will exit this loop and give you a prompt (in PropCMD) where you can enter "SPIN ZICOG150" (".BIN" is automatically appended) to run zicog.
Don't forget, if you are applying 3V3 from an external source, you must solder a link on the pcb across the optional regulator (see the first few posts for a picture).
If you have any further questions, please ask here so everyone can see the answers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
To help get a RamBlade running (asked by PM)...
D'OH! A classic case of RTFM on my side. It works like a charm now. I need to buy a box of matches to impress my visitors who will be coming to me tomorrow [noparse]:)[/noparse]
So to try any of my code I would download it to the SD card and then spin mycode.bin.
I suppose there is no X/Y/Zmodem binary that would receive a file and save it to the SD card?
Juergen
PS: When I look at that picture I think my desktop could use a little cleansing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yes you can copy straight to the sd card and run from there. I was working on a FTP based on what mpark did for SphinxOS that will do file transfer simply for us so we can use the protocol from other micros as well. There are partly done xmodem protocols for the prop but I have not followed them up (lack of time).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Yes you can copy straight to the sd card and run from there. I was working on a FTP based on what mpark did for SphinxOS that will do file transfer simply for us so we can use the protocol from other micros as well. There are partly done xmodem protocols for the prop but I have not followed them up (lack of time).
Edit: I tried that now and the file (yaz80.bin) won't run. It's 22016 bytes and I compiled it with BSTC using the -b option to generate a binary image.
What would be nice was a RAM boot loader like the one that is in the ROM. It should be possible to stop all cogs and run it on one cog to load the RAM from serial pins 22, 23. It should of course wait much longer for a transmission to start, because you don't necessarily have DTR/reset connected.
That way you could run say "spin bootram.bin" and then compile your project, upload it to RAM and go.
Since the code doing the transfer to RAM is already available, that sholdn't be too hard!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 11:17:16 AM GMT
pullmoll: I wanted to do something semi-standard that could do more than just download code which is why I was following the SphinxOS idea. But yes, it is doable and quite easy as we have the source for the prop rom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: I wanted to do something semi-standard that could do more than just download code which is why I was following the SphinxOS idea. But yes, it is doable and quite easy as we have the source for the prop rom.
I tried it, but the binary doesn't seem to run either. I used the boot.spin official source and just ripped out the boot from EEPROM, replacing it with a cogstop self. I increased the delay for waiting on RX to 30 seconds, but it didn't help. Modified boot is attached, perhaps you can try it?
D'OH! Now that I attached it, I see my fault. I should have changed the mask_rx and mask_tx [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll: The write code is not exactly the same (I don't have my code on this laptop). The mov dira, ram_dir_write needs to be followed by mov dira,ram_dir_read. What you have done is left a conflict on the data bus (dira for data = output). Now, if you perform an SD access it will have a problem. The read will self-correct.
IIRC there were only 8 instructions in the write.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: The write code is not exactly the same (I don't have my code on this laptop). The mov dira, ram_dir_write needs to be followed by mov dira,ram_dir_read. What you have done is left a conflict on the data bus (dira for data = output). Now, if you perform an SD access it will have a problem. The read will self-correct.
IIRC there were only 8 instructions in the write.
Ok, I tried that without luck. The 9th instruction in my code is the masking of the address' lower 16 bits only. The ea in my case may contain set bits in the upper half. Actually I should check if that can really happen - this is more of a safety measure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Here is how you can compile and run code on the RamBlade using a propplug without having to copy it to the microSD card.
Place a 10 second wait in your code near the start... waitcnt(clkfreq*10+cnt). This is to allow you time to swap the propplug from the download pins on the RamBlade to the serial I/O pins on the RamBlade.
Connect the PropPlug to the centre 4 pins on the RamBlade edge (G,R,pI,pO)
Compile and download your code
Disconnect the PropPlug and reconnect (upside down) to the lower 4 pins on the RamBlade (G,nc,I,O)
Run PST (Parallax Serial Terminal) or equivalent.
Note 1: If you do not need access to the SRAM you can use the P30/31 serial port with the PropPlug without moving the plug. Only the SRAM conflicts with the P30/31 pins so you can access the microSD using the PropPlug connected to the standard P30/31 pins.
Note 2: If you want to overwrite the Eeprom, use the PropPlug as above to download into eeprom. You will need to place a wire link across the 2 pins labelled WE. You can spring a wire across these without soldering as a temporary solution. Remember, if you do this, you will overwrite the code that I have loaded to boot from the microSD automatically. This code is posted at the top of this thread for reprogramming.
I am aiming to have SphinxOS to be able to transfer files to/from the microSD in the near future.
Shameless plug: I have assembled RamBlade pcbs in stock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just ran into some trouble with the test program. It reported pin 24 collisions (i.e. SD DO). After some digging and re-reading some posts in here it occurred to me that only the EEPROM boot loader would take care of the DO issue (release -> reboot). As I sneek my stuff in through an XLINK style connection I may or may not end up with an SD card in a funny state (if inserted). Apart from that everything works as expected.
Kuroneko said "Just ran into some trouble with the test program. It reported pin 24 collisions (i.e. SD DO). After some digging and re-reading some posts in here it occurred to me that only the EEPROM boot loader would take care of the DO issue (release -> reboot)."
I am not sure what you are saying here. What has the eeprom bootloader got to do with it?
I suspect a problem with the SD driver (fsrw2.6) being marginal somewhere, perhaps not releasing DO properly.
Do you mean rebooting by software and then running the test program?? This could perhaps occur if the SD driver was not correctly closed down I suppose. I need more info please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
I am not sure what you are saying here. What has the eeprom bootloader got to do with it?
The EEPROM boot loader (I assume it's PropBootSD_V1_00) fires up fsrw with the DO release fix, which you applied. So if this boot loader is used then DO is released properly before the new image is booted (e.g. RamBlade_Tests). So the pin tests will most certainly succeed (given that nothing else is wrong).
However, I skip the bootloader and upload the RamBlade_Tests directly from the DemoBoard. So the only SD card involvement here is it being part of the test sequence. Which means in my startup sequence the DO release isn't happening. My guess is that the EEPROM bootloader (104Mhz) gets halfway through mounting the card before the demo board (80MHz) catches up and kills it. Hence the occasional test failure.
This wasn't a complaint, just thought I mention this in the unlikely case someone else falls into that trap [noparse]:)[/noparse]
So what you are saying is that after running something on the RamBlade, you reset the RamBlade and download from the DemoBoard to the RamBlade which is the RamBlade Test code and it fails. Is this correct?
Yes, you could be correct that the eeprom bootloader is getting part way through and therefore leaving the SD card in a sequence (it could be a valid sequence) but it is not forced to release DO.
If what I have summised, then I can correct it. It is just necessary to output some clocks on the SD CLK pin with CS held high (pulled up by a 10K). I am unsure how many clocks but DO could be tested while outputting clocks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
So what you are saying is that after running something on the RamBlade, you reset the RamBlade and download from the DemoBoard to the RamBlade which is the RamBlade Test code and it fails. Is this correct?
Yes, that sums it up nicely. However, I'm not entirely sure that test-while-clocking works. I had both types of stuck DO lines, low (1st test) and high (2nd test). So maybe we can establish a safe cycle count and leave it at that. Don't worry so much about it. I know why it happens and can avoid it. For the normal use-case - booting from SD - you shouldn't have this issue at all.
I am suspicious that the fsrw2.6 does not allow enough clocks as sometimes it fails, especially on some cards more than others.
It is easy to test if the line is stuck low. If it is stuck high then it is a case of allowing a short term conflict to output low. I expect the prop may override the SD high, so it may be necessary to test reading the sram.
Kuroneko, thanks for identifying the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I've just added RamBlade support to Catalina. I'm not quite ready to do a release yet, but I have posted a set of demo executables (which use a VT100 terminal emulator as HMI) in the Catalyst thread (see here). Since I can't fit any more binaries in the first post of the thread, you will find the RamBlade ones on the second page of the thread.
I currently support the XMM RAM and SD Card. I plan to add support for Cluso's 1-pin TV and Keyboard drivers in the next release of Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
Please investigate Atmel Dataflash 16Mbit AT45DB161D for 2.95 and Ramtron 128k X 8 FM25V10-G for 9.00.
RAMTRON prices have fallen 40% in the past year and a half. Phase-change memory will become the dominating type
for new memory, superseding FLASH.
I will be using both in new designs. That's all the freebies that I'm willing to pass along today
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/17/2010 9:15:43 AM GMT
The Ramtron FM25V10-G is SPI and runs at 40MHz max. That means more than 250nS access time per byte providing the cog can clock at this rate. It just isn't going to cut the ice for me. And $9.00 is expensive too. May as well have another prop on the pcb and get the speed!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I included the FM25V10-G as a point of reference. Parallel memory is MUCH faster, as well as non-volatile. I guess the ease of managing ONE type of memory versus EEPROM, RAM, FLASH, etc for all purposes and uses is attractive to me.
No reflection on your thinking - apples and oranges here, I suppose.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Ramtron will not dominate until their prices are comparable, on a per bit basis, with Flash.
RAMBUS died due to exorbitant pricing, and if they don't learn, so will FRAM.
I am staying far away from FRAM until its price is within 5%-10% of FLASH and FRAM.
Using your example, you can buy more than 48Mbits of flash for the cost of 1Mbit of FRAM - which is not competitive.
There are even cheaper (per bit) Flash devices - for example, one can buy a 16Gbit (2GB) SD card for less than the cost of one Ramtron FM25V10-G
This makes the FRAM 16384 times as expensive as the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Flash and FRAM are not the same thing. Of course flash memories will continue to dominate the market for flash memory until the prices are essentially equal. FRAM has some advantages and disadvantages and, where the advantages are sufficient for the price differential, it will dominate. Flash in the form of SD cards is still the cheapest form of semiconductor bulk memory, but its write speed is variable and unpredictable. Where that's an inconvenience, FRAM may well win out. With the prices of FRAM continuing to drop, it will take over more of the market currently filled with flash memory. FRAM still doesn't have the capacities of devices like Atmel's Dataflash, but I suspect that's not far off
I can see some places where even I'd use FRAM - but I can't see it competing with and replacing FLASH for a long time, and I did not want readers to think that was imminent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
And, the point is, the devices are non-volatile. Data retention is forever over the device lifetime.
I guess I like the idea of stocking a universal device for all of my needs. The decision tree narrows to one technology choice with variants (I2C, Parallel, SPI).
Cost is not the deciding issue for me. I probably will last 10 years, same as FRAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/19/2010 3:14:28 AM GMT
A. Full Duplex
B. Half Duplex
C. Burst
I have an idea for all three, but I would like a consensus. Ideally, it should resolve itself into one choice.
Don't forget the higher clock (crystal) speeds needed at each end for testing (i.e. 80 mhz <> 100 mhz on send/receive).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/19/2010 3:36:48 AM GMT
Do you mean communicating to another prop? And an extension to this, meaning multiple devices, such as VGA, Keyboard, serial, etc?
Just for normal comms, you cannot go past FDX (FullDuplexSerial). However, if you want more than a single device (being 1 input and 1 output) then you need addressing info to be passed as well. This is where I thought about Beau's method, using 12 bits where the upper 4 were an address of the device you are communicating with. However, for streaming data (like passing an SD sector or something, it might be preferable to use 32 bits or even 36 bits).
Is this what you are getting at???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 2/19/2010 3:40:52 AM GMT
Enjoy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The first page of this thread has full details including description, block diagram, connections for various other boards, etc. Also how to use a TV and Keyboard using 1-pin each, etc.
If you have any further questions, please ask here so everyone can see the answers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
D'OH! A classic case of RTFM on my side. It works like a charm now. I need to buy a box of matches to impress my visitors who will be coming to me tomorrow [noparse]:)[/noparse]
So to try any of my code I would download it to the SD card and then spin mycode.bin.
I suppose there is no X/Y/Zmodem binary that would receive a file and save it to the SD card?
Juergen
PS: When I look at that picture I think my desktop could use a little cleansing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 6:51:45 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Edit: I tried that now and the file (yaz80.bin) won't run. It's 22016 bytes and I compiled it with BSTC using the -b option to generate a binary image.
What would be nice was a RAM boot loader like the one that is in the ROM. It should be possible to stop all cogs and run it on one cog to load the RAM from serial pins 22, 23. It should of course wait much longer for a transmission to start, because you don't necessarily have DTR/reset connected.
That way you could run say "spin bootram.bin" and then compile your project, upload it to RAM and go.
Since the code doing the transfer to RAM is already available, that sholdn't be too hard!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 11:17:16 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I tried it, but the binary doesn't seem to run either. I used the boot.spin official source and just ripped out the boot from EEPROM, replacing it with a cogstop self. I increased the delay for waiting on RX to 30 seconds, but it didn't help. Modified boot is attached, perhaps you can try it?
D'OH! Now that I attached it, I see my fault. I should have changed the mask_rx and mask_tx [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/26/2010 6:24:54 AM GMT
'****************************************************************************** ' ' Memory access functions (RamBladeProp) ' '****************************************************************************** #ifdef RamBladeProp ' RamBlade Hardware Access: ' P0-18 = A0-18 SRAM address ' P19 = -CS microSD ' P20 = -CE SRAM & enable eeprom ' P21 = -WE SRAM & enable eeprom ' P22 = SO \ not used by this driver ' P23 = SI / ' P24-31 = D0-7 SRAM \ * see below ' | P28 = SCL eeprom ' | P29 = SDA eeprom ' | P30 = prog SO ' / P31 = prog SI ' ' (microSD) DO ---------+ ' (microSD) DI --------+| +-------- SI (P23) ' (microSD) CLK-------+|| |+------- SO (P22) ' ||| || ' (P28) SCL ----+ ||| ||+------ -WE (SRAM & enable eeprom) ' (P29) SDA ---+| ||| |||+----- -CE (SRAM & enable eeprom) ' (P30) SO ---+|| ||| ||||+---- -CS (microSD) ' (P31) SI --+||| ||| ||||| ' |||| ||| ||||| ' P31...P0 --> %xxxxxxxx_00xxx_xxxxxxxxxxxxxxxxxxx ' 10K pullups --> ** *** *** ' +------+ +-----------------+ ' D7....D0 A18..............A0 ram_dir_read long %00000000_00010_1111111111111111111 ' outputs CE, A0-18 (sram read) ram_dir_write long %11111111_00000_1111111111111111111 ' outputs A0-18, D0-7 (sram disabled) ram_dir_wstrobe long %11111111_00110_1111111111111111111 ' outputs CE, WE, A0-19, D0-7 (write strobe) ' '******************************************************* ' Read a byte from RAM[noparse][[/noparse]ea] into the alu ' rd_byte and ea, low_word mov outa, ea ' apply the read address incl -CE=0 -WE=0 mov dira, ram_dir_read ' set outputs A0-18, CE nop ' sram delay required mov alu, ina ' read byte from SRAM shr alu, #24 ' bits 31..24 to 7..0 rd_byte_ret ret '******************************************************* ' Write a byte from the alu into RAM[noparse][[/noparse]ea] ' wr_byte and ea, low_word mov dira, ram_dir_write ' set outputs A0-18, CE mov outx, alu shl outx, #24 ' data byte in bits 31..24 or outx, ea ' address in 15..0 mov outa, outx ' apply the read address incl -CE=0 -WE=0 mov dira, ram_dir_wstrobe ' -CE=-WE= 1 -> 0 \ ce + we pulse nop ' sram delay | mov dira, ram_dir_write ' address + data only / wr_byte_ret retAm I doing something wrong here? To me it looks like the code in RamBlade_0203_002.spin...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
IIRC there were only 8 instructions in the write.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Ok, I tried that without luck. The 9th instruction in my code is the masking of the address' lower 16 bits only. The ea in my case may contain set bits in the upper half. Actually I should check if that can really happen - this is more of a safety measure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Note 1: If you do not need access to the SRAM you can use the P30/31 serial port with the PropPlug without moving the plug. Only the SRAM conflicts with the P30/31 pins so you can access the microSD using the PropPlug connected to the standard P30/31 pins.
Note 2: If you want to overwrite the Eeprom, use the PropPlug as above to download into eeprom. You will need to place a wire link across the 2 pins labelled WE. You can spring a wire across these without soldering as a temporary solution. Remember, if you do this, you will overwrite the code that I have loaded to boot from the microSD automatically. This code is posted at the top of this thread for reprogramming.
I am aiming to have SphinxOS to be able to transfer files to/from the microSD in the near future.
Shameless plug: I have assembled RamBlade pcbs in stock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Just wanted to let you all know that Catalina support for the RamBlade should be included in the next release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I am not sure what you are saying here. What has the eeprom bootloader got to do with it?
I suspect a problem with the SD driver (fsrw2.6) being marginal somewhere, perhaps not releasing DO properly.
Do you mean rebooting by software and then running the test program?? This could perhaps occur if the SD driver was not correctly closed down I suppose. I need more info please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 4/16/2010 7:35:12 AM GMT
However, I skip the bootloader and upload the RamBlade_Tests directly from the DemoBoard. So the only SD card involvement here is it being part of the test sequence. Which means in my startup sequence the DO release isn't happening. My guess is that the EEPROM bootloader (104Mhz) gets halfway through mounting the card before the demo board (80MHz) catches up and kills it. Hence the occasional test failure.
This wasn't a complaint, just thought I mention this in the unlikely case someone else falls into that trap [noparse]:)[/noparse]
Post Edited (kuroneko) : 4/16/2010 7:51:48 AM GMT
So what you are saying is that after running something on the RamBlade, you reset the RamBlade and download from the DemoBoard to the RamBlade which is the RamBlade Test code and it fails. Is this correct?
Yes, you could be correct that the eeprom bootloader is getting part way through and therefore leaving the SD card in a sequence (it could be a valid sequence) but it is not forced to release DO.
If what I have summised, then I can correct it. It is just necessary to output some clocks on the SD CLK pin with CS held high (pulled up by a 10K). I am unsure how many clocks but DO could be tested while outputting clocks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
It is easy to test if the line is stuck low. If it is stuck high then it is a case of allowing a short term conflict to output low. I expect the prop may override the SD high, so it may be necessary to test reading the sram.
Kuroneko, thanks for identifying the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I've just added RamBlade support to Catalina. I'm not quite ready to do a release yet, but I have posted a set of demo executables (which use a VT100 terminal emulator as HMI) in the Catalyst thread (see here). Since I can't fit any more binaries in the first post of the thread, you will find the RamBlade ones on the second page of the thread.
I currently support the XMM RAM and SD Card. I plan to add support for Cluso's 1-pin TV and Keyboard drivers in the next release of Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
What VT100 commands are required? I am ready to add some more of them to the 1pinTV since I have just squashed the code some more
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz