Re: [Xenomai] CAN ISA support

[Wolfgang Grandegger <wg@grandegger.com>]

On 02/25/2014 05:23 PM, Wayne Ross wrote:
> On Thursday, February 20, 2014 3:19 AM Gilles Chanteperdrix wrote:
> 
>> On 02/20/2014 08:47 AM, Wolfgang Grandegger wrote:
>>> Am Mi, 19.02.2014, 23:05 schrieb Wayne Ross:
>>>> On Wednesday, February 19, 2014 3:16 AM Wolfgang Grandegger wrote:
>>>>> - What does "/proc/xenomai/irq" list after you have sent a message?
>>>>>
>>>> # cat /proc/xenomai/irq
>>>> IRQ         CPU0        CPU1        CPU2        CPU3
>>>>   12:           0           0           0           0         SJA1000
>>>>   15:           0           0           0           0         SJA1000
>>>
>>> ... the problem is here. No interrupts are triggered. Are your sure
>>> that the IRQ numbers are correct (check jumpers on the card/board)?>
>> You can also check cat /proc/interrupts when using the Linux driver.
>>
>> -- 
>>                                                                 Gilles.
> 
> 
> Thanks for all the in-sight.  Tracing down this lack of interrupts led me to the following solution:
> - the Advantech driver *transmits* without the aid of IRQs, so I "thought" it was working, when indeed no IRQs were seen.

It works for just one message.

> - I had never tried to receive CAN with the Advantech driver: when I did so, it would not (no IRQs)

You mean you only sent messages with the Advantech driver?

> - I found the setting in my v2.61 American Megatrends BIOS that allows "Legacy IRQs" to be "Reserved" (not allowed to be used by PCIPnP).

BIOS settings may need the be adjusted but I understood that the device
was already working with another driver.

> - I also had to select different IRQs that all components (BIOS, CAN card, 4 16550A UARTs & some ata/acpi Linux drivers) agree were unused and I could tag as "Reserved"

> - In hindsight, all of this should have been done first, but such is the lesson learned when venturing down a new road.  I'm not used to dealing with a BIOS that gets between the chips on my board and the software I write.

Does it now work (with IRQs)?

> I intend to look more at the btr1 register "issue".  As Wolfgang mentions, it *should* be 0x1c, so only sometimes do I get the correct value.  I think the 0x9c means "3 samples" (instead of 1) -- at least when I put these register settings into my Windows driver, that is how that software decodes the meaning.  But it does indeed transmit and receive thousands of messages without a problem.

Yes, that's weird.  Maybe there are register access problems.

Wolfgang.