I have no problem with mctrivia's layout being public, and I'll leave it up to him to post here or send to you.
My desire is to end up with code objects that work to help make a completed product marketable. After discussing this yesterday, we have somewhat decided that the long term route will be to develop a complete propeller based board solution. He actually already did a layout similar to mctrivia's to help him brainstorm and kept thinking it would be better to make a propeller based board that could completely utilize NAND and provide a full solution at the same time. A board similar to the GGPPSD with locations underneath for up to four NAND chips has been discussed.
jazzed/mctriva, I am sending you both messages on some chips
My order for 5 boards is submitted and accepted for production. I expect delivery June 4th.
I'll be free before then to work on a driver. Of course I'll need some chips to start testing.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
mctrivia said...
Good ideam. Will move the control lines.
We 12
Re 13
Ale 14
Cle 15
May swap cle and ale. I places headers so ce can be jumpered if hard coding not desired.
I see these are card edge pins and not Propeller pin P assignments. So P8-11 are not usable for TV DAC.
Thanks for the gerbers anyway.
mctrivia said...
One of the advantages to living in the us. Costs me more in shipping and custums to order 5 proto from us then to pay for 100 boards from China
That is simply amazing. No Canadian FABs? What is your typical turn around time?
There is 1 in calgary and I used them when I lived there. They will do 6 for about 70% of the price in 2 days. Shipping though makes up 20% so now that I can't pick up I might as well wait 10 days including shipping time vs the 4 to 5 from calgary.
So, I was a little shocked (after misreading the specification) that it can take up to 15us for a page
to be transferred from the NAND array to the Flash read buffer. This is a little disappointing, but
there is a consolation prize.
It seems we can use Ready/Busy* bit on P8 for loading time advantage. When Busy* is asserted
this makes it easy to detect an end of buffer transfer condition (data bits go tri-state at Busy*
time and must be pulled down). In other words P[noparse][[/noparse]0:8] will read at least $100 when getting data
and 0 when transfer is complete.
So the per byte HUB transfer loop can go from this:
'' direct REN manipulation ... any length 2.5MB/s burst
:loop andn outa, renmask ' set read enable
nop ' allow setup if clkfreq > 80MHz
mov data, ina
wrbyte data, tp ' do simple read first
or outa, renmask ' toggle read enable low/high to get data
cmp tp, bp wz
if_ne djnz tp, #:loop
To this loop for block reads:
'' Gated REN clock manipulation with rdy on Prop P8 ... 5MB/s burst
'' Requires pulldown on data lines and min 256 byte read
'' Relies on fact that data goes tri-state when rdy is busy
''
mov data, #0
mov ctra, _ctra
mov frqa, _frqa
mov phsa, _phsa
andn outa, renmask ' enable read strobe from counter
:loop movs data, ina wz ' ren should be solid low by sample time
wrbyte data, tp
if_nz djnz tp, #:loop
or outa, renmask ' disable read strobe
Throughput* Busy Time (us) Byte Hub Time (ns) Bytes/Load Byte Load Time(ns) Total Time (ns)
1.7MB/s 8 200 256 51200 59200
1.5MB/s 15 200 256 51200 66200
Throughput does not account for address setup cycle time which is near 1us. Sequential 528
block reads only need one address setup cycle. Typical throughput should be > 1.5MB/s.
Other read strategies such as the one I co-authored with Phil and Lonesock can use long hub
data transfers on burst reads, but the end of transfer has to be controlled by a loop such as
in the first code fragment and the symmetry for the read strobe clock is lost.
What good is this?
The burst size is compatible with VMCOG which allows embedded flash program fetch/execute.
The pin-out can coexist with a byte wide external memory or 2nd Propeller communications.
With a file-system, this would be N times faster than SD card [noparse]:)[/noparse] with wear leveling.
What products does this enable?
Embedded Flash Propeller based Javelin
Embedded Flash + External RAM Propeller Platform and others
Embedded Flash + 2nd Propeller (for rich Video and other peripherals)
Embedded Flash + LCD for rich and textured GUI graphics
May I know if this driver is being posted? I could not find it in OBEX either.
I have code to read the flash, but not to write it. I stopped working on the driver after realizing the access startup time was 15us. You're probably better off using SDCARD if possible.
I am currently using Kye's SD2.0 driver. Though the read speed is very good but the opening of file is slow as I'm sharing this SD object with multiple objects trying to read/write to uSD card. Tried running a 2nd SD object but ran out of Cogs for other objects.
Comments
My desire is to end up with code objects that work to help make a completed product marketable. After discussing this yesterday, we have somewhat decided that the long term route will be to develop a complete propeller based board solution. He actually already did a layout similar to mctrivia's to help him brainstorm and kept thinking it would be better to make a propeller based board that could completely utilize NAND and provide a full solution at the same time. A board similar to the GGPPSD with locations underneath for up to four NAND chips has been discussed.
jazzed/mctriva, I am sending you both messages on some chips
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
WBA-TH1M Sensirion SHT11 Module
My Prop projects: Reverse Geo-Cache Box, Custom Metronome, Micro Plunge Logger
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.
My order for 5 boards is submitted and accepted for production. I expect delivery June 4th.
I'll be free before then to work on a driver. Of course I'll need some chips to start testing.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Thanks for the gerbers anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lots of propeller based products in stock at affordable prices.
to be transferred from the NAND array to the Flash read buffer. This is a little disappointing, but
there is a consolation prize.
It seems we can use Ready/Busy* bit on P8 for loading time advantage. When Busy* is asserted
this makes it easy to detect an end of buffer transfer condition (data bits go tri-state at Busy*
time and must be pulled down). In other words P[noparse][[/noparse]0:8] will read at least $100 when getting data
and 0 when transfer is complete.
So the per byte HUB transfer loop can go from this:
'' direct REN manipulation ... any length 2.5MB/s burst :loop andn outa, renmask ' set read enable nop ' allow setup if clkfreq > 80MHz mov data, ina wrbyte data, tp ' do simple read first or outa, renmask ' toggle read enable low/high to get data cmp tp, bp wz if_ne djnz tp, #:loopTo this loop for block reads:
'' Gated REN clock manipulation with rdy on Prop P8 ... 5MB/s burst '' Requires pulldown on data lines and min 256 byte read '' Relies on fact that data goes tri-state when rdy is busy '' mov data, #0 mov ctra, _ctra mov frqa, _frqa mov phsa, _phsa andn outa, renmask ' enable read strobe from counter :loop movs data, ina wz ' ren should be solid low by sample time wrbyte data, tp if_nz djnz tp, #:loop or outa, renmask ' disable read strobeThroughput does not account for address setup cycle time which is near 1us. Sequential 528
block reads only need one address setup cycle. Typical throughput should be > 1.5MB/s.
Other read strategies such as the one I co-authored with Phil and Lonesock can use long hub
data transfers on burst reads, but the end of transfer has to be controlled by a loop such as
in the first code fragment and the symmetry for the read strobe clock is lost.
What good is this?
- The burst size is compatible with VMCOG which allows embedded flash program fetch/execute.
- The pin-out can coexist with a byte wide external memory or 2nd Propeller communications.
- With a file-system, this would be N times faster than SD card [noparse]:)[/noparse] with wear leveling.
What products does this enable?▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/8/2010 5:59:20 PM GMT
May I know if this driver is being posted? I could not find it in OBEX either.
Thanks.
I am currently using Kye's SD2.0 driver. Though the read speed is very good but the opening of file is slow as I'm sharing this SD object with multiple objects trying to read/write to uSD card. Tried running a 2nd SD object but ran out of Cogs for other objects.