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 Start a New Thread

--- 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 Start a New Thread

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 Start a New Thread