christian pellegrin wrote:
> On Mon, Feb 1, 2010 at 9:22 PM, Wolfgang Grandegger <[email protected]>
> wrote:
>> Is that really true. The manual states that an interrupt is generated
>> when the TXREQ bit will be cleared, which is the case for OSM after the
>> message has been sent. Otherwise it's a bad design flaw. But I might
>> have misinterpreted chapter 3.3. It would make sense to contact National
>> Instruments.
>>
>
> I think you meant Microchip instead of NS. If you check the flowchart
Yep.
> on page in the pdf 21801e.pdf ("FIGURE 3-1: TRANSMIT MESSAGE
> FLOWCHART") the MLOA path has no interrupt generated. This explains
> what Paul is seeing. Unfortunately right now I have just a mcp2510
> available (I should get a design with two mcp2515 soon, but soon is a
> relative concept for hardwerists ;-) ), so I cannot check.
The flow chart does not show how OSM is exactly handled. This could be
check with a few printk's. Not hurry, though.
>>>> Then i would tend to remove the OSM functionality as long as the driver is
>>>> not
>>>> able to handle the descibed problem in OSM mode on the bus.
>> Yes, or at least do not add additional code. We need some more
>> experience with one-shot mode ..
>>
>
> exactly, as soon I have the needed hardware I will give it a try. For
> now I'll keep a separate patch that has the ugly loop as the workqueue
> that reschedules itself.
Thanks,
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
