[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] New to the list
From: |
Johan Karel Maria Dams |
Subject: |
Re: [Simulavr-devel] New to the list |
Date: |
Thu, 27 Oct 2005 12:55:21 +0300 (EEST) |
Hello.
Working on a server from remote workstaion could also be done with all the X
applications, if you have a X server installed on the client system.
Use cygwin or exceed or any other tool for that. The X data transfer could
be tunneld also on ssh connections simply with -X option on ssh (unix) or
with tunnel option on putty windows client.
I know, we do this inside the lab. We have a development server for our
Robotics projects on which all students compile their projects. This way
we know for sure everyone is using the same tools etc...
The problem is that our server is on our intranet without a public IP address.
The only way to get there from the outside is to ssh
into another server first (outside my control) and then ssh from there
into our server.
I did not have time yet to check out how to get X forwarded like that...
but I hope it can be done relatively easy.
simulavrxx provides a gui environment via a normal standard socket
connection. So you are also able to start a gui on local client and run the
simulator on a server anywhere. The connection could also be tunneld through
the ssh connection for security reasons (no idea why we need ssh for
connecting to a simulator :-).
This would, in our situation, require some port forwarding. I don't have
access to that server sadly. (Otherwise I would install simulavr there in
the first place :-)
All memory regions are transparent to the gdb protocol. So there is no
special io-registers side hack. I have never used info io-registers with gdb
but i looked inside the registers with the normal memory operations. I will
take a look for this item, if I could find any problem I will search for a
solution. Maybe this is a side hack in gdb, because no special io-registers
are implemented in simulavrxx. This memory region is used as any other!
ok.
I probably want to make an application like simulavr-disp of the old
version. I guess this should not be too difficult to interface with
simulavrxx?
simulavr is not maintained anymore. If there is anyone interested in, feel
free to help. But for my opinion it make more sense to complete simulavrxx
and port it to more platforms then invest time in the very old structure of
simulavr.
Agreed. Simulavrxx does seem to be better in the long run. Right now I'm
still using the old one, but I will try to move on to simulavrxx asap.
Nice to here :-) Feel free to ask for any technical aspects of the project.
But keep in mind: simulavr is not on my personal list, there
are a lot of reasons I wrote simulavrxx new from scratch. I cant give
you any information on the old implementation, sorry.
I was planning on adapting simulavrxx for our personal needs and further
develop it. I will not develop the old simulavr further, just using it
now until some issues are resolved.
Best regards,
Johan