jerry.needell at unh.edu
Fri Jun 20 17:51:15 UTC 2003
On Friday, Jun 20, 2003, at 11:32 US/Eastern, Fabio Degiovanni - Eicas
> Dear Jerry Needell,
> thank you for your help. Some other
> questions: I have sis intalled, where can I find documentation about
> sis? When I use the target sim option in sparc-rtems-gdb do I use sis
> or another simulator?
the documentation is part of the gdb source distribution. I will send
you the README files on a separate message so they don't burden the
list. I "think" that the same code is used in gdb as in sis, just sis
has stand-alone wrapper. I have been digging through the code to verify
this, but it may take some time to figure out how it all fits together.
Mayby someone else can comment.
> Where can I find the limitation of sparc-rtems-gdb simulator? In the
> tsim site it is clearly stated the limit of 232 instruction, but I
> didn't find anything for my simulator. I think that you correctly
> deduce that the same limit exists, but is there a document stating
> clearly this limit?
I have not found this stated explicitly yet, but I'm still reading...
> Thank you very much again for you help
> Fabio Degiovanni
> Jerry Needell wrote:
>> On Friday, Jun 20, 2003, at 10:34 US/Eastern, Fabio Degiovanni -
>> Eicas wrote:
>>> Dear Jarry Needell,
>>> I think you were right: it is a
>>> problem of overflow. I tried with CONFIGURE_MICROSECONDS_PER_TICK
>>> 1000 and rtems_task_wake_after(1000). The problems is at the 305th
>>> iteration. I tried to put the directive rtems_clock_get(
>>> RTEMS_CLOCK_GET_TICKS_SINCE_BOOT, &inter ); to see at what time (in
>>> ticks this happens) and I found out at 305266 ticks.
>> I was just about to try that myself :-)
>>> I don't understand what variables is subjected to overflow. I'm used
>>> to Linux real-time: in that case there is a periodic interrupt timer
>>> that is loaded to the value of MICROSECONDS_PER_TICK 1000, it counts
>>> down till 0 then it gives an interrupt, the interrupt service
>>> routine increment the value of ticks an reset the PIT to the
>>> MICROSECONDS_PER_TICK value. If RTEMS follows nearly the same
>>> procedure I don't see any point in which an overflow can occur. How
>>> does RTEMS work? What the variable that is subject to overflow? Why?
>>> Thank you very much for your help
>> The problem is not in RTEMS, but in the simulator. On real hardware,
>> it does not crash and it runs in "real time" :-) .
>> - Jerry
>>> Fabio Degiovanni
>>> Dott. Ing. Degiovanni Fabio
>>> Eicas Automazione
>>> Via Vincenzo Vela, 27 10128 Torino (ITALIA)
>>> Telefoni +39-11-562.37.98/562.3088 Fax +39-11-436.06.79
> Dott. Ing. Degiovanni Fabio
> Eicas Automazione
> Via Vincenzo Vela, 27 10128 Torino (ITALIA)
> Telefoni +39-11-562.37.98/562.3088 Fax +39-11-436.06.79
More information about the users