Bernhard Walle wrote:
Hello,
IMO the documentation of tdm_event_timedwait is a bit unclear. There
are two timeout values: the timeout and the timeout sequence. After
reading the source code the behaviour is clear but from documentation
I would have expected following behaviour:
- the
Bernhard Walle wrote:
Hello,
sorry for the late reply.
* Jan Kiszka [EMAIL PROTECTED] [2006-09-06 15:52]:
Bernhard Walle wrote:
Hello,
,
| int rtdm_task_sleep (uint64_t delay);
| int rtdm_task_sleep_until (uint64_t wakeup_time);
`
wouldn't it make sense to return 0 on
Jan Kiszka wrote:
Hi Wolfgang,
as one result of a hacking session on a PPC405 with SJA1000 on board I
applied two minor fixes to rtcan_isa.c to SVN, see end of mail for
reference. The first one gave an interesting effect on big-endian
because irq is an integer, the second one reveals that we
* Jan Kiszka [EMAIL PROTECTED] [2006-09-09 12:28]:
Because the missing information can be easily gathered from outside,
it would be only worth changing if you plan some other changes in
these functions so that this can be done in one in one step.
You exactly hit the point. :-
Yes, I
* Jan Kiszka [EMAIL PROTECTED] [2006-09-09 12:28]:
This overwriting only takes place if timeout_seq is non-NULL. Otherwise,
we are in usual timeout mode.
Yes, of course, you're right. It was too late when I wrote this mail.
I oversaw the NULL case.
Maybe
* @param[in] timeout Relative
Hi Wolfgang,
Wolfgang Grandegger wrote:
You have to define the real CAN system clock, which is 16/2 = 8 Mhz for
most SJA 1000 hardware even if the oscillator is running at 16 MHz. I
will add some reasonable note to rtcan_dev.h
Is there any special reason for this? Wouldn't it be more
Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
You have to define the real CAN system clock, which is 16/2 = 8 Mhz for
most SJA 1000 hardware even if the oscillator is running at 16 MHz. I
will add some reasonable note to rtcan_dev.h
Is