HID Boot protocol is a generic message format for HID compliant mice and keyboards to enable compatibility for systems where the specific device drivers are not available.
It is implemented in this library because it is much simpler to develop and is compatible across all devices.
The limitation of HID boot protocol for mice is that it only supports x,y movement and 3 buttons.
To get mouse wheel support you would need to develop a full device driver for the Arduino that could decode report packets.
RE mouse scroll wheel support with "boot protocol":
I have six mice that I test with and five of them only send wheel button events and ignore scrolling. But one of them is a logitech M310 wireless, which does support scrolling. This one has four bytes in the mouse data packet instead of the three mandated by the boot protocol. That fourth byte is set to 01 on a forward scroll and FF on a back scroll, so there are outliers. I can pack that last byte into the mouse data long for the client if it's in the the USB data packet.
RE mouse scroll wheel support with "boot protocol":
I have six mice that I test with and five of them only send wheel button events and ignore scrolling. But one of them is a logitech M310 wireless, which does support scrolling. This one has four bytes in the mouse data packet instead of the three mandated by the boot protocol. That fourth byte is set to 01 on a forward scroll and FF on a back scroll, so there are outliers. I can pack that last byte into the mouse data long for the client if it's in the the USB data packet.
Well spotted, that could be nice to have, even if it means a 'list of supported mice' for scroll wheel extension.
Does the button on the scroll wheel map to the 3rd mouse button, or somewhere else ?
Well spotted, that could be nice to have, even if it means a 'list of supported mice' for scroll wheel extension.
Does the button on the scroll wheel map to the 3rd mouse button, or somewhere else ?
Yes, the scroll wheel maps to the middle/third button.
I’m not sure I’d use scroll wheel anyway...
It’s to easy to accidentally move for a control system.
I’m not even sure I’ll use right mouse button..
You could always pair the scroll wheel with the press of a keyboard button (eg CTRL + wheel) or one of the mouse buttons (I am using a trackball so perhaps I am biased in the sense that it is easy to keep pressed a trackball button and at the same time scroll the wheel without moving the pointer (not touching the ball)).
There was one more thing I needed to do...
Needed a way to generate 2bpp data from an image.
It's a shame that Microsoft doesn't support a 2bpp option in .bmp files.
I think you could specify 2bpp but nothing would work with it...
Anyway, I'm sticking with just raw data files for now.
I had a program to generate 2bpp data, but it was in scanline order, not the y-tile direction first way that graphics.spin uses.
So, made a new option there and also made it so that it can re-import the .dat files.
Now, can show images directly. Also, can then use graphics to draw on them...
Here's an example showing the P2 pinout. I should have made it a bit bigger, but you can make out a lot of the pin numbers...
I now have the USB driver updating the mouse position directly.
Turns out there was more than enough room in the USB cog left to add this in...
Also, I added a "Status" long to each element so I can flag them as invisible or disabled, etc.
This will probably be the last test version. Want to make something useful with it now...
It just occurred to me that with USB kb in it's own cog we could have the advantage that ctrl-alt-del (or some other sequence) could always work in any situation.
That is, compared to some other systems where you have to physically turn off power or remove battery to reboot.
True, but (devil/details), since there are none "hardware-enforceable locks" that could enable "isolating" any pin (or group of) from being cluttered/hammered/interfered by any other misbehaving Cog (due to hardware or bad-software-induced malfunction), one would have no warranty that this kind of "soft boot" would work under each and every condition/scenario/situation.
There is also no way to know what configuration some pin(s) were been settled to, including the one(s) your "kerberos", USB-enabled-Cog "believes" did just configured to work someway, thus, another chance for a misbehaving or malfunctioning Cog to interfere into USB (or any other kind of) comms.
Sure, there are other possible solutions, but they would involve some other logic-capable peer, that can be programmed to watch for "keep-alive" messages, exchanged by any other conceivable means, while, simultaneously, doing some "sniffing" at the USB lines, in order to be able to detect any suspicious misbehaviour; that peer them would need to be programmed to resort to generate a hard-reset signal, "trying" to recover for the unnexpected situation.
Under some "security" or "life support" speccs, there would be the need for at least a third peer, able to supervise the behaviour of the above depicted solution, or, at least, able to warn some "operator", about the system malfunction.
But (caveat), the third peer could also malfunction, by itself, warning "WOLF!!!" aloud, when there is no wolf at all...
That's not really what the prop, or any micro controller for that matter, is about. Once you head off in the direction of security it becomes a never-ending war of layers and complexity.
Ah, I realise now you are thinking more about reliable operation. Recovering from an electrical spike induced crash say. Well it's safe to say that at that point the machine is already out of order so there is lots of options an exceptional response can offer. But it depends on what level of reliability you require I guess. Certainly, the integrity of hubRAM cannot be guaranteed. There is no internal ECC.
Put in a lot of work on this GUI in the form of a Mixed Signal Oscilloscope as a working example.
There are still some things to add to the GUI, but it seems to be in pretty good shape.
Below is the source code and data files for the Mixed Signal Scope. Compiles with Fastspin 4.1.4.
Here's a version that plays the attached .wav file from uSD card on the scope .
You should set clocks/point to 2000 and set gain to midrange before playing.
This example uses all the cogs and almost all memory.
Compiles with FastSpin version 4.1.6 executable and 4.0.3 library (there's a bug in the 4.1.6 library that prevents it from compiling..)
When the "play wav file" button is pushed, it plays the included stereo sample from uSD card over both pins 6&7 (for A/V output) and on 14&15 for viewing on scope with jumpers to connect to pins 8&9 as shown in setup photo below.
Note: There are some limits here due to the fact that the main cog has to juggle updating the display and keeping the wav player buffers full. You cannot set the clocks/point to much past 5000. Also, it's best not to change any settings while file is playing. It'd be much better if we had one more cog!
@Rayman, thanks for posting your P2 scope application. My son is using it to trace signals on his DIY computer board. It is really very cool that after using a RIGOL scope with digital input options, we can have a P2 eval board do much the same thing and have flexibility to change if needed. Your help is much appreciated in getting the scope up and running.
I have loaded the app into flash and with the proper DIP settings the board boots /presents interface in seconds.
Gotta get another board so that the Forth will still be with me.
Comments
https://forum.arduino.cc/index.php?topic=91594.0
Number can be binary, hex or decimal.
Now, I think I'll see if I can use all this to do something interesting...
Attached is the source and binary in the zip...
I have six mice that I test with and five of them only send wheel button events and ignore scrolling. But one of them is a logitech M310 wireless, which does support scrolling. This one has four bytes in the mouse data packet instead of the three mandated by the boot protocol. That fourth byte is set to 01 on a forward scroll and FF on a back scroll, so there are outliers. I can pack that last byte into the mouse data long for the client if it's in the the USB data packet.
Well spotted, that could be nice to have, even if it means a 'list of supported mice' for scroll wheel extension.
Does the button on the scroll wheel map to the 3rd mouse button, or somewhere else ?
It’s to easy to accidentally move for a control system.
I’m not even sure I’ll use right mouse button..
I just looked, I misremembered how the scroll wheel is implemented: https://isdaman.com/alsos/hardware/mouse/ps2interface.htm
Indeed there is a real z axis in the intellimouse extensions. It's just a delta sent each packet.
You could always pair the scroll wheel with the press of a keyboard button (eg CTRL + wheel) or one of the mouse buttons (I am using a trackball so perhaps I am biased in the sense that it is easy to keep pressed a trackball button and at the same time scroll the wheel without moving the pointer (not touching the ball)).
Needed a way to generate 2bpp data from an image.
It's a shame that Microsoft doesn't support a 2bpp option in .bmp files.
I think you could specify 2bpp but nothing would work with it...
Anyway, I'm sticking with just raw data files for now.
I had a program to generate 2bpp data, but it was in scanline order, not the y-tile direction first way that graphics.spin uses.
So, made a new option there and also made it so that it can re-import the .dat files.
Now, can show images directly. Also, can then use graphics to draw on them...
Here's an example showing the P2 pinout. I should have made it a bit bigger, but you can make out a lot of the pin numbers...
That’s a good idea
It does. Nice work, IMHO
Turns out there was more than enough room in the USB cog left to add this in...
Also, I added a "Status" long to each element so I can flag them as invisible or disabled, etc.
This will probably be the last test version. Want to make something useful with it now...
something to do with base pointers... There's a hard limit set here:
repeat bases_ptr from 0 to x_tiles - 1 <# 31 'write bases bases[bases_ptr] := base_ptr + bases_ptr * y_tiles << 6If I remove the limit, there are about 32 pixels that it can't write to, but then works again out to at least 60 tiles...
All better now with this:
That is, compared to some other systems where you have to physically turn off power or remove battery to reboot.
There is also no way to know what configuration some pin(s) were been settled to, including the one(s) your "kerberos", USB-enabled-Cog "believes" did just configured to work someway, thus, another chance for a misbehaving or malfunctioning Cog to interfere into USB (or any other kind of) comms.
Sure, there are other possible solutions, but they would involve some other logic-capable peer, that can be programmed to watch for "keep-alive" messages, exchanged by any other conceivable means, while, simultaneously, doing some "sniffing" at the USB lines, in order to be able to detect any suspicious misbehaviour; that peer them would need to be programmed to resort to generate a hard-reset signal, "trying" to recover for the unnexpected situation.
Under some "security" or "life support" speccs, there would be the need for at least a third peer, able to supervise the behaviour of the above depicted solution, or, at least, able to warn some "operator", about the system malfunction.
But (caveat), the third peer could also malfunction, by itself, warning "WOLF!!!" aloud, when there is no wolf at all...
There are still some things to add to the GUI, but it seems to be in pretty good shape.
Below is the source code and data files for the Mixed Signal Scope. Compiles with Fastspin 4.1.4.
Link to thread on this: http://forums.parallax.com/discussion/171331/
You should set clocks/point to 2000 and set gain to midrange before playing.
There's a video of it working over here:
http://forums.parallax.com/discussion/171481/wav-audio-player
This example uses all the cogs and almost all memory.
Compiles with FastSpin version 4.1.6 executable and 4.0.3 library (there's a bug in the 4.1.6 library that prevents it from compiling..)
When the "play wav file" button is pushed, it plays the included stereo sample from uSD card over both pins 6&7 (for A/V output) and on 14&15 for viewing on scope with jumpers to connect to pins 8&9 as shown in setup photo below.
Note: There are some limits here due to the fact that the main cog has to juggle updating the display and keeping the wav player buffers full. You cannot set the clocks/point to much past 5000. Also, it's best not to change any settings while file is playing. It'd be much better if we had one more cog!
I have loaded the app into flash and with the proper DIP settings the board boots /presents interface in seconds.
Gotta get another board so that the Forth will still be with me.