I thought the standard fix for C++ and threads is to use the gdbserver in
the toolchain, not the one in the distro. (Of course, that assumes that
your toolchain includes it!)
I don't understand.
I assume for NIOS the tool chain and the distr is quite the same thing
(the installation of
But, it turns out to be moot. The kernel hangs when HZ is 1000
and resets immediately when HZ is 250 or 300. It could be that
the system tick timer isn't configurable and is hard-wired to
generate a 100Hz interrupt.
IMHO: if we are to fix any bugs in the system timer functions, we should
Xin Xie wrote:
The standard way to decrease the latency for embedded system is using a
real-time kernel running alongside with uClinux and keeping the
real-time task inside the real-time kernel. Not too sure if that already
supported in the NIOS uClinux.
Yes, although nowadays the RT-PREEMPT
On 2008-11-21, Michael Schnell [EMAIL PROTECTED] wrote:
How did you test the latency ?
I monitor the Ethernet traffic using a second computer running
wireshark (which uses libpcap) and then I look at the
difference between the timestamps on the packet going to the
NIOS board and the reply
Grant Edwards wrote:
My guess is that the latency is due to delays in the user
thread being woken.
It would be great to know if that is true by creating a test case that
wakes the user thread by some other event.
If the latency is mainly imposed by the network stack, a great
improvement
