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.


_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to