I've pursued the matter of the virtual IR tower further and it's not as
easy as it appears. The problem is that (in the Unix version, for
example) isatty() is called to verify that data can be sent to the
device. It seems that serial/USB behaviour is not formally specified so
each OS does it differently.
So for now it looks like I'm going to have to hack around with the
download code. I can create a generic firmware downloader fairly easily,
but it becomes more difficult with the actual program download. As far
as I'm aware each RCX firmware handles this in its own way, so I'd need
to come up with code for each one.
I'm still hoping inspiration strikes and I figure out a way of doing it
like I originally intended.
> Well, there hasn't been too much in the last few weeks. I'm
> officially on vacation, so I'm attempting to spend time on
> boring things like relaxation. ;)
>
> However, I've got network comms sorted with the emulator. It
> will listen on port 6561 (for now) and when it receives a
> datagram packet, it will print it to the screen (along with
> the IP address of the originator). It only checks every 250
> iterations (I'm planning on working out a better value for
> this - I've tested with 2500 and the messages still get
> through) and uses the Unix select() function, so only blocks
> for a given time (10ms in my case - it's about as low as it
> goes). Hopefully it won't create too much of a performance hit.
>
> The next thing to do is to create a virtual IR tower to act
> as a relay between the firmware download application. I would
> like to do this without modifying the download code in any
> way... This way I can assure that any firmware can be downloaded.
>
> However, I have no clue how to do this in C! I'm working with
> the cygwin environment, so Unix rules apply. If anyone knows
> how I can do this, I would appreciate any help I can get!
>
> That's about it for now, apart from a consistent crash I'm
> getting when stepping through code. I'm working on fixing
> that, but for the moment I've disabled this feature. I also
> need to change the interrupt routines so that only the high
> priority interrupts are accepted when in sleep mode.
>
> Dave.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Rcxemul-discussion mailing list
> Rcx...@li...
> https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
>
|
