Shop OBEX P1 Docs P2 Docs Learn Events
Atmel Dataflash — Parallax Forums

Atmel Dataflash

DarrenYDarrenY Posts: 61
edited 2008-07-01 21:46 in Propeller 1
Rather surprisingly, after a few forum searches I haven't been able to find anyone who has used Atmel Dataflash with the prop?
Anyone successfully done this and willing to share details?
I'm presuming I will need all 4 SPI lines into the prop, i.e. SI, SO, SCLK and CS
Anyone have any clever file'ish based storage solutions?

Comments

  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-07-01 19:28
    The primary reason you haven't seen specific use of the dataflash chips is that the physical interface it is almost identical to SD cards which are ubiquitous and cheaper. Dataflash chips provide a more streamlined method for accessing data than SD cards do, but with the SD card library availible on the Obex (which supports fat16 formating), most people choose to use SD cards.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • DarrenYDarrenY Posts: 61
    edited 2008-07-01 19:34
    Thats cool, but I have to use a permanent solution as my design must be made secure - using removable SD cards isn't an option for me.
    So, are you saying that I could hook a Dataflash up the same way as I would an SD card, and use the same objects?
  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-07-01 20:03
    Not necessarily, the base driver (SPI) can be used, the fat file system can be used, but the mid-level driver concerned with the SD card specification will likely need to be rewritten for the dataflash.

    Depending on your setup, it is possible to use a SD card in a permanent installation: just don't expose the card in the enclosure.

    For non-enclosure setups, you can still permanently install an SD card: layout the sd card so that there is some room between the edge of the board and where the card would come to, place a component which is taller than the socket and lay it out on the board so it would mechanically interfere with removing the card. Solder the socket, insert the card, then solder the "blocking" component in and the card cannot be removed. This alternate method can still be done using production assembly, you just need to omit placing the blocking part and have an after step of installing the card and hand soldering the blocking component.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • DarrenYDarrenY Posts: 61
    edited 2008-07-01 20:23
    Hmmm, interesting option. My design will be enclosed and have a tamper detect on the lid so I might be able to get away with it - i'll have to check with the regulators.
    Thanks for the idea.

    Are MicroSd cards identical in operation to SD cards - in that respect I could actual SAVE board space smile.gif
  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-07-01 20:35
    Yes they are compatable.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • BasilBasil Posts: 380
    edited 2008-07-01 20:40
    Hello [noparse]:)[/noparse]

    I use the dataflash to record data from a rocket flight. Doesn't take up too much board space, and you can SI and SO can share the same pins so you will never use both at the same time, so you really only need 3 pins.

    I have attached a crop of the schematic I use, and heres a link to a photo of the bottom of my board. The DF is the IC to the bottom left of the prop. (Scuse the messy soldering!)


    DSC00484_small.JPG

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    -Alec

    My our page
    DF_Sch.JPG
    375 x 292 - 19K
  • DarrenYDarrenY Posts: 61
    edited 2008-07-01 21:26
    Thats great!

    Do you use a bespoke object or do you use one from the object exchange?

    Thankyou smile.gif
  • BasilBasil Posts: 380
    edited 2008-07-01 21:46
    Hi [noparse]:)[/noparse]

    I just made my own object.

    Its not terribly versitile.
    There are a few things to watch out for.

    1) Outputs from each COg are OR'd together. I was initialising the pins in Cog 0, and writing to the DF in Cog x. This meant that those pins which were set to '1' in Cog 0 would stay as '1' even if another cog changed them (or tried to at least).

    Heres how I got around it.

    In cog 0, loaded a Cog (cog 1) to format, calc etc data in preparation for logging to DF.
    In cog 1:
    '**********************************************************************
'Init ports
'**********************************************************************
  dira[noparse][[/noparse]DF_CS]~~
  outa[noparse][[/noparse]DF_CS]~~
  dira[noparse][[/noparse]DF_SCK]~~
  outa[noparse][[/noparse]DF_SCK]~



    In Cog 1 logging loop:
    Call the following function (in same cog)
    PRI DF_Send(data, bits)

  dira[noparse][[/noparse]DF_DATA]~~
  outa[noparse][[/noparse]DF_SCK]~ 'SCK low for mode 0 
  repeat 1    
  outa[noparse][[/noparse]DF_CS]~ 'CS low

  data <<= (32-bits)

  repeat bits
    outa[noparse][[/noparse]DF_DATA] := (Data <-= 1) & 1
    outa[noparse][[/noparse]DF_SCK]~~ 
    outa[noparse][[/noparse]DF_SCK]~


    Thats it.

    Quite rudimentary but it works [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    -Alec

    My our page
Sign In or Register to comment.