interesting. which ibus adaptor do u use? I got the one from eedesignkits or similar.
Mine's a standard. That might be a good way to implement a reverse camera. I'll try to do some ibus event logging tonight. There's a couple other messages I need to sort out to get my screen switching perfect, anyway.
I think the independent message thing would be cool - then you could set two different scroll lengths! The scroll timers would probably need to be a little offset so that the bus doesn't get too crowded, though.
*** edit: see version 1..89 a couple posts down - this one had a problem!!! sorry.
Here's my addition to your 1.87 code.
I've enabled a crude version of hardware contention management in the ClearToSend sub. If you've set ContentionManagement to modes 3, 4, or 5 in the .ini, then the ClearToSend sub will check to see if there is traffic on the bus before returning a true value. Test your interface to see which line(s) are available to monitor. DSR, CTS, or CD = high, then the bus is clear. If low, then there is traffic. Not quite a full hardware handshake, but better than just the software method.
It probably won't work for you then. I originally bought mine from eedesignkits because it was the only USB solution at the time. Those clowns have taken the SEN/STA pin on the Melexis chip and grounded it. This forces the Tx line open and shuts off any bit comparison between the Tx line and the iBus - ie. no hardware collision detection and no method to monitor the bus activity. I've since switched to Rolf Resler's V5 USB version. It will allow you to monitor the DSR, CTS, or CD lines. I used a handy little program called COM Port Toolkit 3.6 to test both interfaces. Try it on the eekit and you'll see what I'm talking about - the status lines will all stay high no matter what kind of ibus activity is going on. They should take the 'hardware collision detection' bullet off their site, it's simply not true.
oh dear... wish I knew that then!
but I guess I'm doing alright for now. if it poses too big a problem, I'll sell this or eat it or something
Sorry guys, that last version was a turd. I put it together and didn't test it in the car first. I screwed up how I was handling the select case for the contention management. Here's a corrected version, I've removed the other one.
Hey Darth. could you try to fire up some visualisation in winamp from roadrunner whilst this ibuscomm (ibc hereforth) is on?
I've tried all the forceforground settings in the ini file, and have even removed all calls to the method "ForceForegroundWindow" in the ibc code, yet still focus is somehow being hogged when both rr and ibc are on. That is, if I minimise rr and try to use something like notepad, focus is lost after milliseconds. same for launching externall apps from rr, like vis and gps.
sama, I did a couple of different tests. First off, I do experience the same behavior when running RR and IBC at the same time. I guess I normally close RR when I'm doing some editing rather than just minimizing it so that's why I've never noticed before I guess. Just to confirm the problem, I ran the SDK Example that included with RR's source distribution - it has the same problem as well. So I think you were right to start with, the COM module in the SDK appears to be at fault for forcing RR to the foreground. I don't think I know enough about VB to fix this one. Maybe guino will be generous enough to provide an answer / possible soultion.
.rar? you tell me you guys all have winrar licenses? insert fart noise- now I have to d/l some generic app to unzip this gem!
winrar works forever with an annoying msg, try http://www.rarlab.com/ for a free command line version
here's a video of this working
Darth, I'm going to rewrite this app at some point. probably in Java as it's where my strength lies. I'll be able to speak to RR/other apps through Jacob (Java COM bridge).
I've got some new ideas. here are some of them:
- Since when the car goes off ibus activity dies. A software shutdown controller can be configured. this can still fall back on a hard shutdown by the main controller, if any.
- Support for steering wheel double clicks, pressing two buttons at once, and mode switching. The latter means that the up/down arrow can either control next/prev track, or up/down for selecting songs.
- Multiple tasks per event. So that more apps can be made to respond with functions, especially when switching modes.
any other ideas are welcome.