Hi to all,
We are facing an issue nothing technical but affecting the development task.
That is we have two serial Flashes on our product interfaced using SPI and SSP,
one is used to store the firmware using file system another stores a raw memory
which is the user settings and some editable data.
Then we have another SD card to store firmware using file system as an
alternative option.
We are not able to produce no of boards as many as we want because ATMEL 4MB SF
is under huge demand from many places. we are one of them.
We found a 4MB SF, that was SST. but writing in that flash needs the chip should
be erase state, means cant edit the page without erasing that particular page.
So is there any alternative to get rid of ATMEL and use that as permanent
solution? and PCB's are made so pin compatibility also as big issue.
Another doubt is that can we create partial filesystem on SD card and can the
remaining memory be used as a raw memory?
So that i can store my firmware using file system and i can use that file system
for some other purpose also.
And in raw memory i can write my data without much worry...
Can anyone please give some clue to come out of this issue?
and
Need a replacement for 4MB serial flash from ATMEL
Started by ●October 14, 2010
Reply by ●October 14, 20102010-10-14
We have just done this for exactly the same reason
We are using a micro-SD card in SPI mode to replace the Atmel Flash.
I am just using the whole thing as raw memory, but if you have control of the filesystem you could split it.
Getting the micro-SD card initialised is not a trivial task. Writing can be a lot slower than serial flash. Also they are all slightly different, the "standard" is not very standard.
On the other hand you suddenly have 2GB of flash rather than 4MB!
--
Tim Mitchell
We are using a micro-SD card in SPI mode to replace the Atmel Flash.
I am just using the whole thing as raw memory, but if you have control of the filesystem you could split it.
Getting the micro-SD card initialised is not a trivial task. Writing can be a lot slower than serial flash. Also they are all slightly different, the "standard" is not very standard.
On the other hand you suddenly have 2GB of flash rather than 4MB!
--
Tim Mitchell
Reply by ●October 14, 20102010-10-14
On Thu, Oct 14, 2010 at 5:20 PM, wrote:
> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
Check this out http://semicon.sanyo.com/en/memory/list.php?c2=1, it think
they have up to 1MB but not 4MB. Unlike the atmel parts these are NOR flash
but they do offer 256 byte page writes
--
Warm regards
Ashwin
NGX Technologies Pvt. Ltd.
> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
Check this out http://semicon.sanyo.com/en/memory/list.php?c2=1, it think
they have up to 1MB but not 4MB. Unlike the atmel parts these are NOR flash
but they do offer 256 byte page writes
--
Warm regards
Ashwin
NGX Technologies Pvt. Ltd.
Reply by ●October 14, 20102010-10-14
On Thu, 14 Oct 2010 07:50:25 -0400, you wrote:
>Hi to all,
>
>We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.
>
>Then we have another SD card to store firmware using file system as an alternative option.
>
>We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.
>
>We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.
>
>So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.
>
>Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?
>
>So that i can store my firmware using file system and i can use that file system for some other purpose also.
>And in raw memory i can write my data without much worry...
>
>Can anyone please give some clue to come out of this issue?
>and
Almost all SPI flash chips need erase before write - if you can set your system up to deal with this
it will give you a wide range of possible chips, e.g. doing a read-erase-write to write partial
erase blocks.
Amic are the cheapest I've found.
Note there are slight differences between makes, e.g. SST doesn't have page write (WTF?), Atmel
needs a status register write before writes can be enabled, and also erase granularity varies
between manufacturers.
>Hi to all,
>
>We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.
>
>Then we have another SD card to store firmware using file system as an alternative option.
>
>We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.
>
>We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.
>
>So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.
>
>Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?
>
>So that i can store my firmware using file system and i can use that file system for some other purpose also.
>And in raw memory i can write my data without much worry...
>
>Can anyone please give some clue to come out of this issue?
>and
Almost all SPI flash chips need erase before write - if you can set your system up to deal with this
it will give you a wide range of possible chips, e.g. doing a read-erase-write to write partial
erase blocks.
Amic are the cheapest I've found.
Note there are slight differences between makes, e.g. SST doesn't have page write (WTF?), Atmel
needs a status register write before writes can be enabled, and also erase granularity varies
between manufacturers.
Reply by ●October 14, 20102010-10-14
Part numbers would be helpful
DaveS
On Thu, Oct 14, 2010 at 4:50 AM, wrote:
> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
>
>
DaveS
On Thu, Oct 14, 2010 at 4:50 AM, wrote:
> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
>
>
Reply by ●October 15, 20102010-10-15
Thanks to all,
None of the remaining serial Flashes are nither pin compatible nor available
in market. and most of them for code storage. So nothing different from SST.
I think i am correct.
So one thing i can do is, implementing Chan's FATFs will be a solution.
In that i may have to try implementing file system and raw memory access.
Tell me if there is any big challenge in that..
Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
card..
Any more suggestions??
On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
>
> Part numbers would be helpful
>
> DaveS
>
> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>
>> Hi to all,
>>
>> We are facing an issue nothing technical but affecting the development
>> task. That is we have two serial Flashes on our product interfaced using SPI
>> and SSP, one is used to store the firmware using file system another stores
>> a raw memory which is the user settings and some editable data.
>>
>> Then we have another SD card to store firmware using file system as an
>> alternative option.
>>
>> We are not able to produce no of boards as many as we want because ATMEL
>> 4MB SF is under huge demand from many places. we are one of them.
>>
>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>> should be erase state, means cant edit the page without erasing that
>> particular page.
>>
>> So is there any alternative to get rid of ATMEL and use that as permanent
>> solution? and PCB's are made so pin compatibility also as big issue.
>>
>> Another doubt is that can we create partial filesystem on SD card and can
>> the remaining memory be used as a raw memory?
>>
>> So that i can store my firmware using file system and i can use that file
>> system for some other purpose also.
>> And in raw memory i can write my data without much worry...
>>
>> Can anyone please give some clue to come out of this issue?
>> and
>>
>
--
Thanks And Regards
--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd.
Mob: +919739075574
Email: d...@solus.co.in | Web: www.solus.co.in
None of the remaining serial Flashes are nither pin compatible nor available
in market. and most of them for code storage. So nothing different from SST.
I think i am correct.
So one thing i can do is, implementing Chan's FATFs will be a solution.
In that i may have to try implementing file system and raw memory access.
Tell me if there is any big challenge in that..
Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
card..
Any more suggestions??
On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
>
> Part numbers would be helpful
>
> DaveS
>
> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>
>> Hi to all,
>>
>> We are facing an issue nothing technical but affecting the development
>> task. That is we have two serial Flashes on our product interfaced using SPI
>> and SSP, one is used to store the firmware using file system another stores
>> a raw memory which is the user settings and some editable data.
>>
>> Then we have another SD card to store firmware using file system as an
>> alternative option.
>>
>> We are not able to produce no of boards as many as we want because ATMEL
>> 4MB SF is under huge demand from many places. we are one of them.
>>
>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>> should be erase state, means cant edit the page without erasing that
>> particular page.
>>
>> So is there any alternative to get rid of ATMEL and use that as permanent
>> solution? and PCB's are made so pin compatibility also as big issue.
>>
>> Another doubt is that can we create partial filesystem on SD card and can
>> the remaining memory be used as a raw memory?
>>
>> So that i can store my firmware using file system and i can use that file
>> system for some other purpose also.
>> And in raw memory i can write my data without much worry...
>>
>> Can anyone please give some clue to come out of this issue?
>> and
>>
>
--
Thanks And Regards
--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd.
Mob: +919739075574
Email: d...@solus.co.in | Web: www.solus.co.in
Reply by ●October 15, 20102010-10-15
User programmable parameters can be stored in FRAM, which has unlimited
write cycles. Yes,
it's more expensive per bit, but with high speed R/W and no wear out factor,
it's a reasonable option.
See www.ramtron.com
DaveS
On Thu, Oct 14, 2010 at 10:01 PM, Dhanaraj S wrote:
> Thanks to all,
>
> None of the remaining serial Flashes are nither pin compatible nor
> available in market. and most of them for code storage. So nothing different
> from SST. I think i am correct.
>
> So one thing i can do is, implementing Chan's FATFs will be a solution.
>
> In that i may have to try implementing file system and raw memory access.
> Tell me if there is any big challenge in that..
>
> Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
> card..
>
> Any more suggestions??
>
> On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
>
>>
>> Part numbers would be helpful
>>
>> DaveS
>>
>> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>>
>>>
>>>
>>> Hi to all,
>>>
>>> We are facing an issue nothing technical but affecting the development
>>> task. That is we have two serial Flashes on our product interfaced using SPI
>>> and SSP, one is used to store the firmware using file system another stores
>>> a raw memory which is the user settings and some editable data.
>>>
>>> Then we have another SD card to store firmware using file system as an
>>> alternative option.
>>>
>>> We are not able to produce no of boards as many as we want because ATMEL
>>> 4MB SF is under huge demand from many places. we are one of them.
>>>
>>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>>> should be erase state, means cant edit the page without erasing that
>>> particular page.
>>>
>>> So is there any alternative to get rid of ATMEL and use that as permanent
>>> solution? and PCB's are made so pin compatibility also as big issue.
>>>
>>> Another doubt is that can we create partial filesystem on SD card and can
>>> the remaining memory be used as a raw memory?
>>>
>>> So that i can store my firmware using file system and i can use that file
>>> system for some other purpose also.
>>> And in raw memory i can write my data without much worry...
>>>
>>> Can anyone please give some clue to come out of this issue?
>>> and
>>>
> --
> Thanks And Regards
>
> --
> Dhanaraj S
> Embedded development,
> Solus Security Systems Pvt. Ltd.
> Mob: +919739075574
>
> Email: d...@solus.co.in | Web: www.solus.co.in
>
>
>
write cycles. Yes,
it's more expensive per bit, but with high speed R/W and no wear out factor,
it's a reasonable option.
See www.ramtron.com
DaveS
On Thu, Oct 14, 2010 at 10:01 PM, Dhanaraj S wrote:
> Thanks to all,
>
> None of the remaining serial Flashes are nither pin compatible nor
> available in market. and most of them for code storage. So nothing different
> from SST. I think i am correct.
>
> So one thing i can do is, implementing Chan's FATFs will be a solution.
>
> In that i may have to try implementing file system and raw memory access.
> Tell me if there is any big challenge in that..
>
> Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
> card..
>
> Any more suggestions??
>
> On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
>
>>
>> Part numbers would be helpful
>>
>> DaveS
>>
>> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>>
>>>
>>>
>>> Hi to all,
>>>
>>> We are facing an issue nothing technical but affecting the development
>>> task. That is we have two serial Flashes on our product interfaced using SPI
>>> and SSP, one is used to store the firmware using file system another stores
>>> a raw memory which is the user settings and some editable data.
>>>
>>> Then we have another SD card to store firmware using file system as an
>>> alternative option.
>>>
>>> We are not able to produce no of boards as many as we want because ATMEL
>>> 4MB SF is under huge demand from many places. we are one of them.
>>>
>>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>>> should be erase state, means cant edit the page without erasing that
>>> particular page.
>>>
>>> So is there any alternative to get rid of ATMEL and use that as permanent
>>> solution? and PCB's are made so pin compatibility also as big issue.
>>>
>>> Another doubt is that can we create partial filesystem on SD card and can
>>> the remaining memory be used as a raw memory?
>>>
>>> So that i can store my firmware using file system and i can use that file
>>> system for some other purpose also.
>>> And in raw memory i can write my data without much worry...
>>>
>>> Can anyone please give some clue to come out of this issue?
>>> and
>>>
> --
> Thanks And Regards
>
> --
> Dhanaraj S
> Embedded development,
> Solus Security Systems Pvt. Ltd.
> Mob: +919739075574
>
> Email: d...@solus.co.in | Web: www.solus.co.in
>
>
>
Reply by ●October 15, 20102010-10-15
I Have with me a stock of 2 k pcs of
SST25VF016BSST25VF016B-50-4C-S2AF-T
Please contact me if you find it suitable
MohitMobile :- 919216592131 India
--- On Fri, 10/15/10, Dhanaraj S wrote:
From: Dhanaraj S
Subject: Re: [lpc2000] Need a replacement for 4MB serial flash from ATMEL
To: l...
Date: Friday, October 15, 2010, 10:31 AM
Thanks to all,
None of the remaining serial Flashes are nither pin compatible nor available in market. and most of them for code storage. So nothing different from SST. I think i am correct.
So one thing i can do is, implementing Chan's FATFs will be a solution.
In that i may have to try implementing file system and raw memory access. Tell me if there is any big challenge in that..
Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD card..
Any more suggestions??
On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
Part numbers would be helpful
DaveS
On Thu, Oct 14, 2010 at 4:50 AM, wrote:
Hi to all,
We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.
Then we have another SD card to store firmware using file system as an alternative option.
We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.
We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.
So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.
Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?
So that i can store my firmware using file system and i can use that file system for some other purpose also.
And in raw memory i can write my data without much worry...
Can anyone please give some clue to come out of this issue?
and
--
Thanks And Regards
--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd.
Mob: +919739075574
Email: d...@solus.co.in | Web: www.solus.co.in
Please contact me if you find it suitable
MohitMobile :- 919216592131 India
--- On Fri, 10/15/10, Dhanaraj S wrote:
From: Dhanaraj S
Subject: Re: [lpc2000] Need a replacement for 4MB serial flash from ATMEL
To: l...
Date: Friday, October 15, 2010, 10:31 AM
Thanks to all,
None of the remaining serial Flashes are nither pin compatible nor available in market. and most of them for code storage. So nothing different from SST. I think i am correct.
So one thing i can do is, implementing Chan's FATFs will be a solution.
In that i may have to try implementing file system and raw memory access. Tell me if there is any big challenge in that..
Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD card..
Any more suggestions??
On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
Part numbers would be helpful
DaveS
On Thu, Oct 14, 2010 at 4:50 AM, wrote:
Hi to all,
We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.
Then we have another SD card to store firmware using file system as an alternative option.
We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.
We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.
So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.
Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?
So that i can store my firmware using file system and i can use that file system for some other purpose also.
And in raw memory i can write my data without much worry...
Can anyone please give some clue to come out of this issue?
and
--
Thanks And Regards
--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd.
Mob: +919739075574
Email: d...@solus.co.in | Web: www.solus.co.in
Reply by ●October 15, 20102010-10-15
Because of the non-availablity of Atmel flash, XMOS now supports the
Winbond W25X40BV for use with their chips. I bought several from
Digi-Key recently.
Leon
--
Leon Heller
G1HSM
Winbond W25X40BV for use with their chips. I bought several from
Digi-Key recently.
Leon
--
Leon Heller
G1HSM
Reply by ●October 15, 20102010-10-15
On 10/15/2010 3:10 AM, David Smead wrote:
> User programmable parameters can be stored in FRAM, which has unlimited
> write cycles. Yes,
> it's more expensive per bit, but with high speed R/W and no wear out factor,
> it's a reasonable option.
That's my preferred solution as well. Not only is fast nice in its own
right (no waiting for write commands to finish) it dramatically reduces
the window during which the memory is vulnerable to disturbances that
will mess up it's data store.
The no wear out makes implementing data logs and counters a lot easier
and more effective as well.
Robert
--
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
> User programmable parameters can be stored in FRAM, which has unlimited
> write cycles. Yes,
> it's more expensive per bit, but with high speed R/W and no wear out factor,
> it's a reasonable option.
That's my preferred solution as well. Not only is fast nice in its own
right (no waiting for write commands to finish) it dramatically reduces
the window during which the memory is vulnerable to disturbances that
will mess up it's data store.
The no wear out makes implementing data logs and counters a lot easier
and more effective as well.
Robert
--
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
