Re: [Simulavr-devel] ATmega328 Emulation

[Petr Hluzín]

On 17 February 2011 17:23, David Madden <address@hidden> wrote:
> On 02/17/2011 07:57 AM, Petr Hluzín wrote:
>
>> Actually this is a bug in simulavr. In file src/cmd/gdbserver.cpp in
>> function GdbServer::gdb_read_memory(const char *pkt) change these
>> lines:
>
> Thanks, Petr.  (I had started looking at the GDB debugging output from
> Simulavr, and it appeared that the problem was in there -- GDB was asking
> for reasonable things, but the simulator was reporting things wrong.  I was
> going to start debugging Simulavr tonight.)

Also good! I am having good mood - I might do some work on simulavr
during weekend. If you report some issues I will try to fix them.

> I'll make your changes and see what happens.
>
>> Simulavr also eats 100% CPU when waiting for GDB. What a shame, I
>> should fix that before anyone notices. :) (But I did not write the
>> crappy function.)
>
> That would be great -- I had noticed that problem too, but I thought maybe
> the simulator was in "Run" state except when GDB tells it to stop at a
> breakpoint?  But this sounds like a busy-waiting loop in the read() from
> GDB.

It should not burn CPU unless GDB is "executing" the program (i.e.
waiting for a breakpoint to be hit). I am not sure about the modes
when GDB is not connected.

People, in what situations does simulavr "wait" for input when not
controlled by GDB?

> Who writes code like that?  :-)

Busy-waiting/polling is easy to write, needs no thinking ahead. F/OSS
software usually starts because someone needs to scratch an itch.

Simulavr can receive bytes from multiple TCP connections (gdb,
value-change dumps, status display, perhaps more). That would need
some sort of select() call and centralized dispatch. I plant to fix
that.

Folks, any objections or preferences how should I do that?
(I think I will solve that myself, I must accommodate for Windows
unusual sockets.)

-- 
Petr Hluzin