C RP Wrote
> Thanks for you valuable suggestions.

Your quite welcome.

> 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.

It's not clear to me what you are trying to do. Whether it is a logging
application where you periodically retrieve a snapshot of the logged data
or a CAN <--> UART/USB protocol converter.

For the latter a FIFO will do.

>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 ?

An RTOS might make the task (so to speak) easier by splitting logically
separate tasks into separate units but it doesn't sound like it's reached
the point where it becomes a near requirement. As long as you don't spend
too long on any one item you can just switch from one to the other
continuously. In fact I suspect much of the I/O is simple enough to leave
to interrupt routines and the main application would just be left with
filtering and 'traffic management' between I/O ports.

>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.

If the 32K is enough for your application and buffering, it'll certainly
work and it'll be a lot easier than trying to get the flash to work.

> The LPC2368 also has a SD/MMC card interface.

An option if you need to record large amounts of data.

You might find it useful to sit down and draw out your data flows (Where
the data is coming from and going to). That exercise may clear up your
requirements or point out where they conflict or unclear. Right now your
description seems a little unclear as to exactly what you are trying to
achieve. One of the items you need to work out is what sort of bandwidths
you are dealing with on the various I/O ports.

Robert

--------------------------------
mail2web.com - Microsoft Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange

An Engineer's Guide to the LPC2100 Series

--- In l..., armand@... wrote:
>
> Hi,
>
> Although I am new to the list,
>
> > 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
>
> I would suggest you evaluate the option of the uart carefully.
Probably you
> know that CAN can ( :-) ) have a high bitrate and writing data to
the uart
> could
> potentially overflow a uart buffer (you might need this) if the uart has
> not high
> enough bandwidth.
> If you need a serial connection for any reason then please consider the
> SPI which
> can keep up far easier.
>
> Armand ten Doesschate
>

That was my first thought as well. If the average data input at the
CAN is greater than that output at the UART, there will be a problem
eventually no matter what storage is used for the data. This means
dumping some data if the buffer storage becomes full and that could be
easy or hard. If the incoming data is not a simple byte stream, it
could well mean parsing, classifying and managing the data so that
priority can be given to some data items over others.

Rgds,
Martin

Hi,

Although I am new to the list,

> 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

I would suggest you evaluate the option of the uart carefully. Probably you
know that CAN can ( :-) ) have a high bitrate and writing data to the uart
could
potentially overflow a uart buffer (you might need this) if the uart has
not high
enough bandwidth.
If you need a serial connection for any reason then please consider the
SPI which
can keep up far easier.

Armand ten Doesschate

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

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
>
>
>

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

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.
>
>
>
>
>

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.
>
>
>
>
>

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.