Page 1 of 1
Message filtering (hardware filter)
Posted: Fri 4. Mar 2011, 10:45
by expor
Hello,
First of all thanks for the help on my stuff error. After adding 120ohm resistors at both my self-made cable ends data transfer goes perfect.
I now have a question regarding adding masks for filtering. By default the filter is off and can I manually filter messages by making if statements (like the one in the example project for CAN flashing) that check for received id's. However, as I understood the CAN_AddFilter() function allows me to set a 11/29bit id check
before it's read into the RxQueue. When I add a filter (both single id and ranges) the devices no longer registers any received data (atleast not by using the regular queue reading).
Code: Select all
#define USEHARDWAREFILTER = 1
....
#if USEHARDWAREFILTER == 1
CAN_FilterAdd(CanIf1, CanFilterAdd11Bit, 0x150, 0x0);
CAN_FilterOn();
#else
...
The getMsg function uses the GetNext/ReadNext sequence (tested with Read aswell, no difference).
Do filtered messages go somewhere else or should they be in this queue like they usually are?
Re: Message filtering (hardware filter)
Posted: Fri 4. Mar 2011, 11:41
by S.Michaelsen
Hello expor,
there is a minor Bug in the library function CAN_FilterAdd(...). The number of the CAN-interface is wrongly increased by one. So if you try to add a filter rule to the interface CanIf0 it will be added to interface CanIf1 instead.
We will fix this in the next version of the library. Until there you have to call this function with interface number decremented by one instead of the real interface number.
In your case
Code: Select all
...
CAN_FilterAdd((CanIf1-1), CanFilterAdd11Bit, 0x150, 0x0);
...
for example.
The messages are filtered by the hardware CAN-Engine so you will never see a filtered message. The filter rules you define stand for the messages that you want to receive (white list) so if you enable the filter and don’t define a rule for an interface all messages should be blocked.
Regards
Stephan
Re: Message filtering (hardware filter)
Posted: Mon 7. Mar 2011, 12:16
by expor
Thanks for the reply, this indeed solved my problem and hardware filtering does it's job.
Is there a list (if there's more) of known bugs you could share? I'm doing a graduation project with this system (if it fits the requirements when I'm done with my research) and this kind of stuff would be nice to know beforehand to speed up developing.
Also the supplied API does seem to lack explanation at points, is it correct that only FMS/DTCO/OBDII data is logged to a file with the latest firmware? I know there is FAT32 support so I can write my own functions to log CAN data in general, but it's a waste of time to code something that's been done before (something with a weel and reinventing it) because I missed something in the API.
PS. If I'm not mistaking you are the one that replied to my mail earlier answering the latest firmware is 1.6.0 and that my other questions would be answered by mr. Hessemer when he'd be back (last week). Is there any ETA on that?
Thanks again!
Re: Message filtering (hardware filter)
Posted: Mon 7. Mar 2011, 13:36
by S.Michaelsen
Fine. I’m glad that I could help you.
The only other known Problem is that the GPS-Task could produce a stack overflow in some special cases. This will be fixed in the next version too.
The only function that logs data is the library function log_Task(). It will store some information from the OBDII- and/or FMS-bus into a .kml-file if the module has a valid GPS-position. It is not intended for logging a huge amount of data.
Yes, I think I replied your mail. Mr. Hessemer is right back and will answer your residual questions within this week.
Regards
Stephan