1080p tiled GUI

13

Comments

  • RaymanRayman Posts: 11,372
    edited 2020-03-10 - 18:06:26
    Guess not... Don't see it in data and found this here:

    https://forum.arduino.cc/index.php?topic=91594.0
    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.
    
  • I think I've added the last thing I'm sure I'll need going forward: Number edit
    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...
  • Nice!
  • 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.
  • jmgjmg Posts: 14,495
    garryj wrote: »
    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 ?
  • Presumably that's an 8-bit signed delta value.
  • I believe it's buttons 4 and 5 that implement the z-axis.
  • An axis classed as a pair of buttons wouldn't make much sense. That would be a right proper nerf!
  • evanh wrote: »
    Presumably that's an 8-bit signed delta value.
    Yes and does emit velocity, too. With this particular mouse I had to spin like crazy to get the delta value to change.
    jmg wrote: »
    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.
  • RaymanRayman Posts: 11,372
    edited 2020-03-11 - 00:41:51
    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..
  • evanh wrote: »
    An axis classed as a pair of buttons wouldn't make much sense. That would be a right proper nerf!

    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.
  • Rayman wrote: »
    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)).
  • RaymanRayman Posts: 11,372
    edited 2020-03-22 - 21:30:40
    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...
  • This is getting nice. One thing SGI did with its knobs is allow keyboard arrow keys when it has focus.

  • That looks really clean!
  • potatohead wrote: »
    This is getting nice. One thing SGI did with its knobs is allow keyboard arrow keys when it has focus.

    That’s a good idea

  • cgracey wrote: »
    That looks really clean!

    It does. Nice work, IMHO
  • 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...
  • Seems the # of x tiles in Graphics.spin is limited to 31, not sure why yet...
    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 << 6
    

    If 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...
  • Feel dumb now... Was spending a lot of time on this, but the problem was just the size of the bases array...
    All better now with this:
      'word  bases[32]  'RJA  words aren't big enough for larger memory space
      long  bases[120] 'RJA:expanding this to max x tiles on 1080p screen
    
  • RaymanRayman Posts: 11,372
    edited 2020-04-02 - 02:19:54
    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.
  • YanomaniYanomani Posts: 1,058
    edited 2020-04-02 - 03:30:44
    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...
  • Ok right, the usb cog could be messed with by another cog. Good point.
  • 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.
  • RaymanRayman Posts: 11,372
    edited 2020-04-15 - 18:33:20
    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.

    Link to thread on this: http://forums.parallax.com/discussion/171331/
    4032 x 3024 - 2M
  • Great Ray! Can't wait to get my Eval board out of storage.
  • RaymanRayman Posts: 11,372
    edited 2020-04-28 - 18:05:57
    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.

    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!
    3024 x 4032 - 3M
    4032 x 3024 - 2M
  • Rayman wrote: »
    ... It'd be much better if we had one more cog!
    Roll on 130 nm fab. and 16 cogs. :)

  • @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.
    1492 x 990 - 264K
Sign In or Register to comment.