Hi there,

My project is based on LPC2368 which has 512kB in built Flash memory.
My final code size will be within 16kByte so i want to make use of the remainder Flash memory space to store certain CAN data.
Please suggest me a way for storing data in the Flash memory .
Are there any special routines available to do it ? Start a New Thread

What sort of CAN data? Do you mean the setup values such as the acceptance
filter id's? If so surely defining them as 'const' should do the trick - as
your compiler should see they're read only and plonk them in flash
accordingly?

Andy

-----Original Message-----
From: l... [mailto:l...]On Behalf Of
c...@gmail.com
Sent: 06 August 2007 11:36
To: l...
Subject: [lpc2000] Storing data in Flash memory
Hi there,

My project is based on LPC2368 which has 512kB in built Flash memory.
My final code size will be within 16kByte so i want to make use of the
remainder Flash memory space to store certain CAN data.
Please suggest me a way for storing data in the Flash memory .
Are there any special routines available to do it ? Start a New Thread

Look at the "IAP commands" section of the "Flash Memory Programming
Firmware" chapter of the LPC23xx User Manual. Using IAP commands you
can write data to a specific sector of the flash.

--- In l..., chetanrp@... wrote:
>
> Hi there,
>
> My project is based on LPC2368 which has 512kB in built Flash memory.
> My final code size will be within 16kByte so i want to make use of
the remainder Flash memory space to store certain CAN data.
> Please suggest me a way for storing data in the Flash memory .
> Are there any special routines available to do it ?
> Start a New Thread

--- In l..., "Andy Berney" wrote:
>
> What sort of CAN data? Do you mean the setup values such as the
acceptance
> filter id's? If so surely defining them as 'const' should do the
trick - as
> your compiler should see they're read only and plonk them in flash
> accordingly?
>
> Andy
>
> -----Original Message-----
> From: l... [mailto:l...]On
Behalf Of
> chetanrp@...
> Sent: 06 August 2007 11:36
> To: l...
> Subject: [lpc2000] Storing data in Flash memory
> Hi there,
>
> My project is based on LPC2368 which has 512kB in built Flash memory.
> My final code size will be within 16kByte so i want to make use of the
> remainder Flash memory space to store certain CAN data.
> Please suggest me a way for storing data in the Flash memory .
> Are there any special routines available to do it ?
>
>
>
Hi Andy,
I mean the data byte in the CAN frame received by the device Iam
designing (node) not the filter id. Start a New Thread

Hi,

I think someone else has already pointed you at the IAP calls to use the
internal flash on the micro, however you may well be constrained by the
limitations of this functionality and end up looking at external flash etc.
It depends very much on what you plan on doing with the data and the nature
of speed and size of the data exchange.

Andy

-----Original Message-----
From: l... [mailto:l...]On Behalf Of
chetan_r_prabhu
Sent: 06 August 2007 15:29
To: l...
Subject: [lpc2000] Re: Storing data in Flash memory
--- In l..., "Andy Berney" wrote:
>
> What sort of CAN data? Do you mean the setup values such as the
acceptance
> filter id's? If so surely defining them as 'const' should do the
trick - as
> your compiler should see they're read only and plonk them in flash
> accordingly?
>
> Andy
>
> -----Original Message-----
> From: l... [mailto:l...]On
Behalf Of
> chetanrp@...
> Sent: 06 August 2007 11:36
> To: l...
> Subject: [lpc2000] Storing data in Flash memory
>
>
> Hi there,
>
> My project is based on LPC2368 which has 512kB in built Flash memory.
> My final code size will be within 16kByte so i want to make use of the
> remainder Flash memory space to store certain CAN data.
> Please suggest me a way for storing data in the Flash memory .
> Are there any special routines available to do it ?
>
>
>
>
>
>
>
Hi Andy,
I mean the data byte in the CAN frame received by the device Iam
designing (node) not the filter id. Start a New Thread

Hi Andy,
Actually, i would like to store the CAN data byte in the Flash memory so
that it can be
accessed by a PC based application through the USB port.
The PC based application should be able to read/modify/write the CAN data
byte stored in the
Flash memory location.
Hope iam going in the right direction.

On 8/6/07, Andy Berney wrote:
>
> Hi,
>
> I think someone else has already pointed you at the IAP calls to use the
> internal flash on the micro, however you may well be constrained by the
> limitations of this functionality and end up looking at external flash
> etc.
> It depends very much on what you plan on doing with the data and the
> nature
> of speed and size of the data exchange.
>
> Andy
>
> -----Original Message-----
> From: l... [mailto:
> l... ]On Behalf Of
> chetan_r_prabhu
> Sent: 06 August 2007 15:29
> To: l...
> Subject: [lpc2000] Re: Storing data in Flash memory
>
> --- In l... , "Andy Berney"
> wrote:
> >
> > What sort of CAN data? Do you mean the setup values such as the
> acceptance
> > filter id's? If so surely defining them as 'const' should do the
> trick - as
> > your compiler should see they're read only and plonk them in flash
> > accordingly?
> >
> > Andy
> >
> > -----Original Message-----
> > From: l... [mailto:
> l... ]On
> Behalf Of
> > chetanrp@...
> > Sent: 06 August 2007 11:36
> > To: l...
> > Subject: [lpc2000] Storing data in Flash memory
> >
> >
> > Hi there,
> >
> > My project is based on LPC2368 which has 512kB in built Flash memory.
> > My final code size will be within 16kByte so i want to make use of the
> > remainder Flash memory space to store certain CAN data.
> > Please suggest me a way for storing data in the Flash memory .
> > Are there any special routines available to do it ?
> >
> >
> >
> >
> >
> >
> >
> Hi Andy,
> I mean the data byte in the CAN frame received by the device Iam
> designing (node) not the filter id.
>
>
>
>
> Start a New Thread

You're not going into specifics here, however just from the sounds of it
Flash doesn't strike me as a particularly good memory medium for doing what
you're proposing for a few reasons.

1) The flash is good for 100,000 write cycles so depending on the speed of
interchange of data and modification you could easily exceed this.

2) The IAP calls don't allow you to address a single byte in terms of
writing. If my memory serves the minimum data size for IAP is something like
512 bytes, although you could write you're own flash handler to reduce this.

3) The slow speed of the IAP calls and the fact they require you to
potentially remove use of the PLL and FIQ's/IRQ's is prohibitive to large
numbers of other peripherals... UART etc...

In short, you may well be better off looking at a different solution however
you'd probably be best served by proposing what you want to try and achieve
on here first so that people can throw in ideas as to a mechanism to do it.
The previous e-mail gives the basics but we'd need to know a little more in
terms of the amount and speed of data transfer required etc.

Andy

-----Original Message-----
From: l... [mailto:l...]On Behalf Of
C RP
Sent: 07 August 2007 05:03
To: l...
Subject: Re: [lpc2000] Re: Storing data in Flash memory
Hi Andy,
Actually, i would like to store the CAN data byte in the Flash memory so
that it can be
accessed by a PC based application through the USB port.
The PC based application should be able to read/modify/write the CAN data
byte stored in the
Flash memory location.
Hope iam going in the right direction.

On 8/6/07, Andy Berney wrote:
>
> Hi,
>
> I think someone else has already pointed you at the IAP calls to use the
> internal flash on the micro, however you may well be constrained by the
> limitations of this functionality and end up looking at external flash
> etc.
> It depends very much on what you plan on doing with the data and the
> nature
> of speed and size of the data exchange.
>
> Andy
>
> -----Original Message-----
> From: l... [mailto:
> l... ]On Behalf Of
> chetan_r_prabhu
> Sent: 06 August 2007 15:29
> To: l...
> Subject: [lpc2000] Re: Storing data in Flash memory
>
> --- In l... , "Andy
Berney"
> wrote:
> >
> > What sort of CAN data? Do you mean the setup values such as the
> acceptance
> > filter id's? If so surely defining them as 'const' should do the
> trick - as
> > your compiler should see they're read only and plonk them in flash
> > accordingly?
> >
> > Andy
> >
> > -----Original Message-----
> > From: l... [mailto:
> l... ]On
> Behalf Of
> > chetanrp@...
> > Sent: 06 August 2007 11:36
> > To: l...
> > Subject: [lpc2000] Storing data in Flash memory
> >
> >
> > Hi there,
> >
> > My project is based on LPC2368 which has 512kB in built Flash memory.
> > My final code size will be within 16kByte so i want to make use of the
> > remainder Flash memory space to store certain CAN data.
> > Please suggest me a way for storing data in the Flash memory .
> > Are there any special routines available to do it ?
> >
> >
> >
> >
> >
> >
> >
> Hi Andy,
> I mean the data byte in the CAN frame received by the device Iam
> designing (node) not the filter id.
>
>
>
>
> Start a New Thread

Andy Berney Wrote
>You're not going into specifics here, however just from the sounds of it
>Flash doesn't strike me as a particularly good memory medium for doing what
>you're proposing for a few reasons.

I think you are right and I'll add a few points to consider.

>1) The flash is good for 100,000 write cycles so depending on the speed of
>interchange of data and modification you could easily exceed this.

Yes, although if this is a consideration this is starting to look like FRAM
or battery backed RAM rather than EE or Flash.

>2) The IAP calls don't allow you to address a single byte in terms of
>writing. If my memory serves the minimum data size for IAP is something
like
>512 bytes, although you could write you're own flash handler to reduce
this.

Only somewhat, there are still limitations in how small you can make the
write due to the ECC nature of the flash. And since this means bypassing
the IAP and using a reverse engineered flash algorithm your engineering
costs just jumped.

>3) The slow speed of the IAP calls and the fact they require you to
>potentially remove use of the PLL and FIQ's/IRQ's is prohibitive to large
>numbers of other peripherals... UART etc...

yep, Now let me add

4) Engineering cost. External memory is cheap and easy to set up (cheap
again) so you really have to have high volumes to justify using internal
flash instead of some external memory. Quite frankly this application
sounds like a low volume application. Even if it is high volume you might
be better off using an external memory to start and consider eliminating it
as a cost reduction on a working selling product. I suspect the OP has
already spent more engineering time cost considering the issue than would
have been spent if an external device had been used from the start.

5) I haven't looked at the variants but you might even be able to absorb
the cost of the external memory by using a smaller memory micro. It's
likely to offset part of the cost if there are smaller memory variants.
Robert
--------------------------------
mail2web.com Enhanced email for the mobile individual based on Microsoft
Exchange - http://link.mail2web.com/Personal/EnhancedEmail Start a New Thread

Dear Andy/Robert ,

Thanks for you valuable suggestions.

I still need to collect information regarding amount of information and
speed of data.
Actually, i need to store the both the RAW CAN data and the filtered CAN
data to the memory.
If the memory overflows then, it should start overwriting the old CAN data.
Also the filtered CAN data needs to be sent to the UART.
A PC based application needs to be written which can allow the user to view
both RAW and Filtered CAN datas through the USB port.
I have 2 queries based on the this
1. Since Iam not using an RTOS for my project. Is it possible do
the task of
Saving the filtered CAN data to memory and sending the same to the UART
and
if USB is plugged in during this time, the PC based application should
allow the user to view this filtered
CAN data.
I just thought of doing the following. Save the filtered CAN data to
memory and
then send the same to UART. Also store the filtered CAN data to the USB
RAM which is 8kB so that the
PC based application can access it from there.
Is this possible or do i need to go for an RTOS ?

2. This application will be always powered by the automotive battery.
Also, a backup battery will be
provided for the controller.
The LPC2368 has 32kB SRAM (i.e.on chip RAM).
So, is it correct to store the RAW and Filtered CAN data's to the 32KB
SRAM instead of the Flash
memory.
The LPC2368 also has a SD/MMC card interface.

Please give me your suggestions.

On 8/7/07, s...@aeolusdevelopment.com <
s...@aeolusdevelopment.com> wrote:
>
> Andy Berney Wrote
> >You're not going into specifics here, however just from the sounds of it
> >Flash doesn't strike me as a particularly good memory medium for doing
> what
> >you're proposing for a few reasons.
>
> I think you are right and I'll add a few points to consider.
>
> >1) The flash is good for 100,000 write cycles so depending on the speed
> of
> >interchange of data and modification you could easily exceed this.
>
> Yes, although if this is a consideration this is starting to look like
> FRAM
> or battery backed RAM rather than EE or Flash.
>
> >2) The IAP calls don't allow you to address a single byte in terms of
> >writing. If my memory serves the minimum data size for IAP is something
> like
> >512 bytes, although you could write you're own flash handler to reduce
> this.
>
> Only somewhat, there are still limitations in how small you can make the
> write due to the ECC nature of the flash. And since this means bypassing
> the IAP and using a reverse engineered flash algorithm your engineering
> costs just jumped.
>
> >3) The slow speed of the IAP calls and the fact they require you to
> >potentially remove use of the PLL and FIQ's/IRQ's is prohibitive to large
> >numbers of other peripherals... UART etc...
>
> yep, Now let me add
>
> 4) Engineering cost. External memory is cheap and easy to set up (cheap
> again) so you really have to have high volumes to justify using internal
> flash instead of some external memory. Quite frankly this application
> sounds like a low volume application. Even if it is high volume you might
> be better off using an external memory to start and consider eliminating
> it
> as a cost reduction on a working selling product. I suspect the OP has
> already spent more engineering time cost considering the issue than would
> have been spent if an external device had been used from the start.
>
> 5) I haven't looked at the variants but you might even be able to absorb
> the cost of the external memory by using a smaller memory micro. It's
> likely to offset part of the cost if there are smaller memory variants.
>
> Robert
>
> ----------------------
> mail2web.com Enhanced email for the mobile individual based on
> Microsoft(r)
> Exchange - http://link.mail2web.com/Personal/EnhancedEmail
>
>
>




Start a New Thread

Hi,

from the sounds of it your program should be relatively simple to achieve.
You're reading data in via the CAN bus, storing it in memory somewhere and
delivering that data to a PC via USB.

My first question would be: Do you need to be able to save historical data
or is this application purely to give real time output? If it needs to save
historical data then you'll need some form of non-volatile memory, flash,
fram etc. If it purely acts in real time then you could simply use ram.

Assuming you need to store this info in some form of volatile memory you
then have to work out the duty cycle of the application to see what best
fits the purpose. For high volume or high frequency data storage /
modification, Flash becomes of limited use due to the relatively low number
of garaunteed write cycles - 100K to 1Million typically. Alternatively
though looking at FRAM you can get round these general issues. There are a
myriad of interfaces available although SPI/I2C are very simple to implement
quickly and would give you a huge selection of parts to choose from.

The above assumptions however may prove false if as you suggest you will
always have backup power to the unit, as in this situation you could
theoretically use a volatile memory solution and simply keep the data in ram
(be it internal or externally fitted). Personally having dealt with a number
of problems over the years I dislike and generally distrust backup battery
solutions in embedded products as quite often engineers rely too heavily on
this design feature which can lead to catastrophic failure of a product when
for example a battery leaks... (especially if your product happens to be
stuck up several thousand telegraph poles in the Thai jungle - but thats
another story...)

To answer your question about RTOS's: There's nothing to stop you writing
your application such that it schedules the workload in a suitable manner
without the need of an RTOS. An RTOS however would give you this level of
abstraction by its nature - although you will perhaps have less control over
direct scheduling. Either way should work though and both have their pros
and cons. Given the simple nature of this application however I'd personally
just write it without using one.

Hope that helps some, I'm sure Richard and others will have comments as
well.

Andy

-----Original Message-----
From: l... [mailto:l...]On Behalf
Of C RP
Sent: 08 August 2007 05:55
To: l...
Subject: Re: [lpc2000] Re: Storing data in Flash memory
Dear Andy/Robert ,

Thanks for you valuable suggestions.

I still need to collect information regarding amount of information and
speed of data.
Actually, i need to store the both the RAW CAN data and the filtered CAN
data to the memory.
If the memory overflows then, it should start overwriting the old CAN data.
Also the filtered CAN data needs to be sent to the UART.
A PC based application needs to be written which can allow the user to view
both RAW and Filtered CAN datas through the USB port.
I have 2 queries based on the this
1. Since Iam not using an RTOS for my project. Is it possible do
the task of
Saving the filtered CAN data to memory and sending the same to the UART
and
if USB is plugged in during this time, the PC based application should
allow the user to view this filtered
CAN data.
I just thought of doing the following. Save the filtered CAN data to
memory and
then send the same to UART. Also store the filtered CAN data to the USB
RAM which is 8kB so that the
PC based application can access it from there.
Is this possible or do i need to go for an RTOS ?

2. This application will be always powered by the automotive battery.
Also, a backup battery will be
provided for the controller.
The LPC2368 has 32kB SRAM (i.e.on chip RAM).
So, is it correct to store the RAW and Filtered CAN data's to the 32KB
SRAM instead of the Flash
memory.
The LPC2368 also has a SD/MMC card interface.

Please give me your suggestions.

On 8/7/07, s...@aeolusdevelopment.com <
s...@aeolusdevelopment.com> wrote:
>
> Andy Berney Wrote
> >You're not going into specifics here, however just from the sounds of it
> >Flash doesn't strike me as a particularly good memory medium for doing
> what
> >you're proposing for a few reasons.
>
> I think you are right and I'll add a few points to consider.
>
> >1) The flash is good for 100,000 write cycles so depending on the speed
> of
> >interchange of data and modification you could easily exceed this.
>
> Yes, although if this is a consideration this is starting to look like
> FRAM
> or battery backed RAM rather than EE or Flash.
>
> >2) The IAP calls don't allow you to address a single byte in terms of
> >writing. If my memory serves the minimum data size for IAP is something
> like
> >512 bytes, although you could write you're own flash handler to reduce
> this.
>
> Only somewhat, there are still limitations in how small you can make the
> write due to the ECC nature of the flash. And since this means bypassing
> the IAP and using a reverse engineered flash algorithm your engineering
> costs just jumped.
>
> >3) The slow speed of the IAP calls and the fact they require you to
> >potentially remove use of the PLL and FIQ's/IRQ's is prohibitive to large
> >numbers of other peripherals... UART etc...
>
> yep, Now let me add
>
> 4) Engineering cost. External memory is cheap and easy to set up (cheap
> again) so you really have to have high volumes to justify using internal
> flash instead of some external memory. Quite frankly this application
> sounds like a low volume application. Even if it is high volume you might
> be better off using an external memory to start and consider eliminating
> it
> as a cost reduction on a working selling product. I suspect the OP has
> already spent more engineering time cost considering the issue than would
> have been spent if an external device had been used from the start.
>
> 5) I haven't looked at the variants but you might even be able to absorb
> the cost of the external memory by using a smaller memory micro. It's
> likely to offset part of the cost if there are smaller memory variants.
>
> Robert
>
> ----------------------
> mail2web.com Enhanced email for the mobile individual based on
> Microsoft(r)
> Exchange - http://link.mail2web.com/Personal/EnhancedEmail
>


Yahoo! Groups Links Start a New Thread