Fram????
rwgast_logicdesign
Posts: 1,464
Well this is super last minute but ive heard of some people using fram instead of eeprom. Now i did a little reading i know its faster, but is it faster than a 5mhz eeprom. Im thinking about doing a last minute change to my dev-board to use fram if its worth it. Does anyone have a digi key part of some fram anything. or maybe a ti free sample im gonna put that order in tonight too! Neways I think itd be a cool thing to set me apart that much more if its worth it.
I swear when im not in a huge rush im going to sit on here and answer everything I can, you guys are so helpfull this is a great community for the curious newb. Usually i do alot of research before I ask stuff but this time im in a rush just wanna try to squeeze a chip in and learn more about it when the box comes!
I swear when im not in a huge rush im going to sit on here and answer everything I can, you guys are so helpfull this is a great community for the curious newb. Usually i do alot of research before I ask stuff but this time im in a rush just wanna try to squeeze a chip in and learn more about it when the box comes!
Comments
FRAM do cost more, but have no need to wait for a WRITE time, but they often have a finite read maximum, check the fine print.
Besides FRAM, there is also MRAM, from Everspin.
Parallel SRAM can be found easily to 8-10ns, but parallel FLASH is maybe 45ns in a similar process.
Serial SRAM seems to be slow, simply because it uses an old/cheap process.
Serial FLASH is faster, because customers demand faster boot times, and more info is involved, so speed becomes something end users can notice.
One day, someone might make Serial SRAM, in QuadSPI with DDR clocking at 100MHz or above, or they may offer a mix of SRAM and
FLASH on a single QuadSPI DDR interface...
maybe those sram chips i saw were serial amd thats why they were like 70ns. But i remmber using 72 pin 70ns simms back in the day (those old sims are dram right?) if those were quick enough for a 486 playing avis at 800x600 on win 95 what would be a case where a prop benefits from 10ns sram over the slow stuff?
someone said that there were eeprom drivers that could get over 1mhz, the speed doesnt matter on boot though? like when the eeprom loads into hub ram on start the prop will only grab that 32k at 100khz? so how in the world can u get a little 32k into hub memmory quicker? im guessing this is basically imppssible? even if you write a quad spi loader in an amazing 2k the prop is gonna xfer 32k over that ttl serial line at 100khz?
sry speeds always the name of my game and after oc ability boot time and fast ram is gonna be the next huge boost. sometime down the line id like to get at least 8 16mB of ram. but for now i wanna just somehow speed up boot times. is there a way to get the boot loader out of the prop is it sofware stored some where? probably not guessing it acuall hard logic in the chip.
Just curious what the need for speed is versus added complexity and cost over EEPROM.
Actually it grabs at about 300kHz, which is why it takes about a second (32kB * 10-ish bits / 300,000 Hz). I guess the 300kHz allows some room in case the RCFAST clock was running faster, as common I2C EEPROMs are rated to 400 kHz.
Do you really need to shorten that boot time below 1 second? Can't the user just switch the power on a second earlier
DDR = Double Data Rate ( some call it Double Transfer rate), and yes, like DDR DRAM, it means you send new data on a CHANGE in clock,
and so can read faster, with less RFI. It also avoids needing to toggle pins well over 100MHz.
There are already some DDR QuadSPI Flash parts available, and it would be silly for new silicon like the Prop II to not support this.
True, but there are 1MHz(Fm+) and 3.4MHz (HSm) and even 5MHz (UFm) i2c speed standards out now, and a 5MHz capable boot, would occur in a tad under 60ms.
Google finds many LED drivers at 5MHz, but not so many memories yet...
On the other hand using a faster memory chip in conjunction with a driver program to support the available speed would make loading and saving data and programs much faster after the initial boot.
Acually reading the prop manual states that the prop trys to pull the 32k over the serial pins first and there is a whole protocall written to pull serial data on the props boot. Maybe you could send your boot data on pins 40 39 with the protocall mentioned. You would probably have to interface some kind of fast storage to a serial ttyl like ftdi or something, or is this still pointless and the prop pulls serial data on the tx rx lines as fast as it would an eeprom?
Whats the point? idk design the fastest prop board ever. seriously people like speed, if the serial solution would work its probably to costly and complicated for the little amount of time saved but theroretically id like to know if there is a possible way to do this. This is also why I asked if there was any kind of access to the props boot up code.. a way to get the bootloaders hex dump and reflash or something?
I think it was BradC who told me it was possible to load the prop with just the 1 RX pin (P31) + reset. We were discussing loading from an ipod or similar ((kind of a modern datasette). You can possibly also abort early - ie just load a 8kB bootloader which pages the rest from SD card or something. This all needs to be confirmed by someone who knows.
There is no flash to reflash... its a hard coded boot protocol (on the propellers ROM)
As kuroneko implied, you can change the boot process. The firmware can detect and use the "PC RAM load" protocol on boot. PC RAM load does not read the 32KB like the EEPROM boot. Experiment with this by testing the speed of using F10 in Propeller-Tool over hitting the reset button for small programs. A small loader can set the clock mode/frequency and download at much higher speeds than EEPROM.
Adding a micro like an AVR to speed up stand alone propeller boot would seem a little odd, but it could free up all 32 propeller pins. There are other benefits like built-in USB and/or I2C ADC, etc....
That's a definite possibility.
Anyone know how high a data rate the prop could handle from the PC end micro, and if it needs to download a full 32K?
I really should get in the habit of reading ALL the posts before responding. This seems to answer both of my previous questions. Thanks jazzed.
I'm looking at this http://search.digikey.com/us/en/products/ATMEGA32U4-AU/ATMEGA32U4-AU-ND/1914602
or one of these http://search.digikey.com/us/en/products/PIC32MX250F128B-I%2FSS/PIC32MX250F128B-I%2FSS-ND/3046658
Seems there are at least 2 ways to approach this. Use a small AVR and a memory chip of some kind for prop code, or a bigger AVR that can store the prop code as well as providing more I/O. Which is better really depends on the requirements of the application.
@jazzed
It would be nice if there was enough internal memory in the AVR to dispense with the external memory chip but I don't see it making much difference speed wise.
It takes about 4 seconds for Propeller to boot from 32KB of EEPROM. One of my target designs will usually have about a 4KB boot-loader to start the Propeller running and should take no more than a second to start after the ~150ms PC negotiation.
My target design (similar to the little box I passed around during my presentation at the EXPO) runs a program from external 8 bit Flash memory programmed by Propeller GCC or other language. In that case an AVR is fine. The other link I posted is to a cheaper PIC32 that has 128KB of flash with equivalent functions in a smaller SSOP28 footprint.
Honestly I'm more interested in the more peripherals for cheaper price and fewer component footprint, but the speedup is welcome too. Waiting 4 seconds for a micro to boot after power on reset can be tedious.
Regarding programming, any micro whether AVR, PIC32, or other that is the "boot micro" should be able to interpret and deliver the results on the Propeller load sequence. The loader can program code to the boot micro's storage when necessary (i.e. Burn EEPROM) and just send code to the propeller as a proxy for RAM mode. Some customization can be used with a loader and the boot micro if necessary.
Another candidate Loader device, that can also hold more than one boot image, is the VNC2 from FTDI
This comes down to TQFP32/QFN32 and has 256KF
It is likely to have a well supported library, and it has a 'free' USB host so you could have one USB for PC+power, and one for a Flash Drive....
Sorry, I should have made my comment about speed a little clearer. What I meant was that having the AVR download the data from it's own internal memory would not necessarily be much if any faster than having the AVR read from the external memory and then transfer the data to the prop. The higher transfer speed, reduction of the amount of data transferred, and reduction time of the check for PC communication would definitely make for a faster boot compared to booting 32K from eeprom.
If you want more I/O you also get more on chip memory that could be used to increase boot speed as well. A rare win/win case where you don't have to trade off one thing to gain another.
At this point though you are getting into a chip that may have more pins than the prop so you have to wonder if it is a case of the tail wagging the dog.