What you got there is not actually the raw report, it's what the HID parser gives out. The real raw report is only kept temporarily in urx_buffer to reduce memory usage. The raw report probably has a way to discriminate which touch point is which.
@pik33 said:
I tested again the new version of driver with the USB touch screen.
The device ID is 0EEF 0005
@rogloh said:
That's good news pik33. I have a HDMI/VGA + USB touchscreen (GT911 based) I should try out too when I can (perhaps tomorrow). Hopefully it might work in a similar way to yours l so I can put it to some good use on a P2.
After testing my touchscreen with your program I found have the same device ID. I can see co-ordinates changing as I touch the capacitive screen and get different values from 0-1023 and 0-599 (on a 1024x600 7 inch Waveshare touchscreen). It also reports multiple positions moving as you touch with other fingers in other longs in the report. NICE!
By the way if you add text.clear() at the start of your printing code like below it will keep all the data on one line and be easier to read...
if long[usb.get_hidpad_buffer+28*num+4]<>iii or long[usb.get_hidpad_buffer+28*num+8]<>jjj
iii:=long[usb.get_hidpad_buffer+28*num+4]
jjj:=long[usb.get_hidpad_buffer+28*num+8]
text.clear() ' add this line
text.hex(long[usb.get_hidpad_buffer+28*num],8)
text.printStr(@" ")
...
I wonder if I can push usable 1024x600 out of my HDMI driver. 1024x576x50 Hz has already its timing stretched way out of specification... These waveshare screens are not very expensive. My screen is also Waveshare, 5", 800x480
Edit: It seems I can. My 800x480 Waveshare touch screen and a 24" Philps monitor display this. Can you try the modified (to display 1024x600) player on your 1024x600 Waveshare screen? HDMI at p0. The player is for EC32, but the blank picture and a mouse cursor (USB at p16) is displayed even on the non-PSRAM Edge
Edit 2: text.clear makes all things displayed on the first line of text so they blink. I wanted this scrolling version to read more than one report.
Didn't work, got no output on screen at all. I ran the Eval (no PSRAM) and HDMI on P0, USB on P16 and also strapped 5V on the HDMI breakout in case that was needed.
Actually scratch that @pik33. After switching from VGA to HDMI I needed to power on the display again. Once I did that I do see a cursor and a cycling coloured row at the bottom of the screen. So it is working to some extent.
It is what it should be on a non-psram board. The cursor is displayed because the sprite data is kept in the hub.
I now consider to buy this 7" 1024x600 screen
@pik33 I am finding it tricky to get pixel perfect timing over its analog VGA input with this Waveshare screen. The timing is undocumented and I'm experimenting to see if I can get it perfectly showing at 1024x600 without any scaling. I'm getting a bit closer but not there yet. The HDMI input is probably easier to get right as people already use these LCDs with Raspi's and PC's etc and they seem to be able to do it. It's mainly VGA that is the issue. Been googling about and trying lots of suggested modelines etc but so far no dice. So YMMV.
Do these not have an OSD to adjust timing? Though from experience cheap LCDs with scaling capabilities are crud and can not correctly display even HDMI inputs coming in their native resolution.
That is why I asked you to test the HDMI: the native 1024x600 resolution is working as you can see the mouse cursor. I even don't know what is and where I can get a VGA cable for this "VGA" slot that looks like mini-HDMI.
The timings are stretched as much as possible.
' bf.hs,hs, bf.vis visible,up p., vsync, down p., cpl, total lines, clock, hubset scanlines ud bord mode reserved
timings long 8, 60, 8, 1024, 4, 4, 4, 128, 600, 336956522, %1_101101__11_0000_0110__1111_1011, 600, 0, 192, 0, 0
Having some major ISP access to Parallax forum problems right now (plus to some other international sites) so not able to respond much tonight or at all after this.
@Wuerfel_21 Yes it does have an OSD as you point out, I'd forgotten about that. Will need to mess about with that too.
This newest version starts with numlock on. While OK for the normal keyboard, it is not good for RPi keyboard as its num lock replaces several letters with the num pad.
Edit: this did the job...
mov kb_led_states, #0 '#LED_NUMLKF
.... maybe add this option to the configuration....
@pik33 said:
This newest version starts with numlock on. While OK for the normal keyboard, it is not good for RPi keyboard as its num lock replaces several letters with the num pad.
Well that's bizarro - that'd mean it changes the scancodes based on the LED state.
@pik33 said:
This newest version starts with numlock on. While OK for the normal keyboard, it is not good for RPi keyboard as its num lock replaces several letters with the num pad.
Well that's bizarro - that'd mean it changes the scancodes based on the LED state.
I guess I'll put a config value for that in.
Yes, it does. That was very annoying: you switch the system on, you press "u" and got '4".
Just merged in macca's work on making combo kb+mouse devices work. Also kicked up the poll rate to 1000 Hz because the combo mouse wasn't smooth without it (combo device as currently implemented polls at half rate, but 250 should've still been sufficent. IDK, but it seems fixed now).
Might need to re-test some device support with the 1000 Hz change, but chances are good that if it's ok at 500 Hz (which is already higher than the declared rate of most devices), it'll do 1000 Hz just fine. Also, input latency for non-combo devices is now <= 1ms, which is quite nice, too, isn't it?
PUB set_basepin(pin)
usb_event_pin := pin
dm := pin+2
dp := pin+3
...
' Handle Port protection enable and startup delay
mov htmp, usb_event_pin ' I/O + 1 pin is the Serial Host USB Protection enable/disable
add htmp, #1 ' Protection enable is a one-time operation
drvl htmp ' disable port
I know this pin mapping suits the Parallax breakout board HW but other systems may not wish to follow this exact pin sequence and it could be a bit limiting arbitrarily to always have this constraint. Would be good to have an API (or secondary API) to specify the three pins explicitly. I know the dm & dp pair must be sequential but the other two pins do not have to be nearby pins AFAIK. The PASM could be changed to include a protection enable pin rather than be computed the way it is.
Also if the USB code is not reentrant or is single instance only some/all of these pins numbers could possibly be (overridable) constants to save a few COGRAM storage longs. For example why not do
dirl #USB_EVENT_PIN
instead of
dirl usb_event_pin
if it can be done this way? Although you may not want to use pin constants if this driver will be multi-instance capable in the longer term. Is that even going to possible? Not sure...
@rogloh said:
I know this pin mapping suits the Parallax breakout board HW but other systems may not wish to follow this exact pin sequence and it could be a bit limiting arbitrarily to always have this constraint. Would be good to have an API (or secondary API) to specify the three pins explicitly. I know the dm & dp pair must be sequential but the other two pins do not have to be nearby pins AFAIK. The PASM could be changed to include a protection enable pin rather than be computed the way it is.
That's a good catch.
Also if the USB code is not reentrant or is single instance only some/all of these pins numbers could possibly be (overridable) constants to save a few COGRAM storage longs. For example why not do
dirl #USB_EVENT_PIN
instead of
dirl usb_event_pin
if it can be done this way? Although you may not want to use pin constants if this driver will be multi-instance capable in the longer term. Is that even going to possible? Not sure...
Using single constants would cause clutter and make runtime pin setting not work (unless I add even more clutter).
Multi-instance currently doesn't work (did it ever work? The original orignal driver could be loaded twice for mouse+keyboard, but that may just have worked because the buffers are separate to begin with???) and I don't really see the point as much. Just get a 7-port hub
(Also, if you instantiate two drivers with different configs, they'll work because the compiler duplicates the memory)
Actually, while I'm looking at this, I'll probably remove the event pin mechanism. It's not a good use of a pin. On the accessory board that pin has an LED so it's fine (but I hate random LED blinking so I always disabled that), but if you're doing a custom board you shouldn't have to mess with that.
OK, did all the changes. Also, port protection enable is now optional. You can also configure the offsets from the basepin now or set the pins at runtime explicitly.
@Wuerfel_21 said:
Actually, while I'm looking at this, I'll probably remove the event pin mechanism. It's not a good use of a pin.
Was the purpose of this to notify the client of USB device disconnects/reconnects and various device types being ready etc? That could be useful if you wanted to present something indicating that the user should plug in their devices now etc and to ensure you have what is required before you begin the application. If you now have or intend to make an alternative API mechanism for this type of state/presence information to be obtained it is probably okay to remove the original way.
The event pin mechanism never really worked to begin with for multiple devices. Either gamepad API has presence detection by polling. Mouse/keyboard do not because the accuracy of such would be dubious at best, see earlier.
Ok, I've also moved mouse scrolling into a separate function now (that returns two values so we can read H scroll values later). I think that's the API alright for now.
Comments
What you got there is not actually the raw report, it's what the HID parser gives out. The real raw report is only kept temporarily in
urx_bufferto reduce memory usage. The raw report probably has a way to discriminate which touch point is which.After testing my touchscreen with your program I found have the same device ID.
I can see co-ordinates changing as I touch the capacitive screen and get different values from 0-1023 and 0-599 (on a 1024x600 7 inch Waveshare touchscreen). It also reports multiple positions moving as you touch with other fingers in other longs in the report. NICE!
By the way if you add text.clear() at the start of your printing code like below it will keep all the data on one line and be easier to read...
if long[usb.get_hidpad_buffer+28*num+4]<>iii or long[usb.get_hidpad_buffer+28*num+8]<>jjj iii:=long[usb.get_hidpad_buffer+28*num+4] jjj:=long[usb.get_hidpad_buffer+28*num+8] text.clear() ' add this line text.hex(long[usb.get_hidpad_buffer+28*num],8) text.printStr(@" ") ...I wonder if I can push usable 1024x600 out of my HDMI driver. 1024x576x50 Hz has already its timing stretched way out of specification... These waveshare screens are not very expensive. My screen is also Waveshare, 5", 800x480
Edit: It seems I can. My 800x480 Waveshare touch screen and a 24" Philps monitor display this. Can you try the modified (to display 1024x600) player on your 1024x600 Waveshare screen? HDMI at p0. The player is for EC32, but the blank picture and a mouse cursor (USB at p16) is displayed even on the non-PSRAM Edge
Edit 2: text.clear makes all things displayed on the first line of text so they blink. I wanted this scrolling version to read more than one report.
Didn't work, got no output on screen at all. I ran the Eval (no PSRAM) and HDMI on P0, USB on P16 and also strapped 5V on the HDMI breakout in case that was needed.
Actually scratch that @pik33. After switching from VGA to HDMI I needed to power on the display again. Once I did that I do see a cursor and a cycling coloured row at the bottom of the screen. So it is working to some extent.
It is what it should be on a non-psram board. The cursor is displayed because the sprite data is kept in the hub.
I now consider to buy this 7" 1024x600 screen
@pik33 I am finding it tricky to get pixel perfect timing over its analog VGA input with this Waveshare screen. The timing is undocumented and I'm experimenting to see if I can get it perfectly showing at 1024x600 without any scaling. I'm getting a bit closer but not there yet. The HDMI input is probably easier to get right as people already use these LCDs with Raspi's and PC's etc and they seem to be able to do it. It's mainly VGA that is the issue. Been googling about and trying lots of suggested modelines etc but so far no dice. So YMMV.
Do these not have an OSD to adjust timing? Though from experience cheap LCDs with scaling capabilities are crud and can not correctly display even HDMI inputs coming in their native resolution.
That is why I asked you to test the HDMI: the native 1024x600 resolution is working as you can see the mouse cursor. I even don't know what is and where I can get a VGA cable for this "VGA" slot that looks like mini-HDMI.
The timings are stretched as much as possible.
Having some major ISP access to Parallax forum problems right now (plus to some other international sites) so not able to respond much tonight or at all after this.
@Wuerfel_21 Yes it does have an OSD as you point out, I'd forgotten about that. Will need to mess about with that too.
@pik33 I got a mini-HDMI to vga locally from here:
https://core-electronics.com.au/waveshare-mini-hdmi-to-vga-cable.html
I'll try out your timing with HDMI and VGA in my driver when I can and see if I can get it pixel perfect.
There are some comments and code in the driver about keyboard LEDs. Is there a way to control them using the driver?
Currently not. You can only check their state and they of course toggle when you press the associated key.
They don't toggle and that's why I asked
You sure you're on the latest version?
It seems it was not. I replaced what I have with the fresh copy from Github and the LEDs now work.
This newest version starts with numlock on. While OK for the normal keyboard, it is not good for RPi keyboard as its num lock replaces several letters with the num pad.
Edit: this did the job...
.... maybe add this option to the configuration....
Got a ingcool 7" cap touch display from Amazon, still in box. Good to know you figured out how to use these...
Well that's bizarro - that'd mean it changes the scancodes based on the LED state.
I guess I'll put a config value for that in.
Yes, it does. That was very annoying: you switch the system on, you press "u" and got '4".
Just merged in macca's work on making combo kb+mouse devices work. Also kicked up the poll rate to 1000 Hz because the combo mouse wasn't smooth without it (combo device as currently implemented polls at half rate, but 250 should've still been sufficent. IDK, but it seems fixed now).
Might need to re-test some device support with the 1000 Hz change, but chances are good that if it's ok at 500 Hz (which is already higher than the declared rate of most devices), it'll do 1000 Hz just fine. Also, input latency for non-combo devices is now <= 1ms, which is quite nice, too, isn't it?
I wanna stabilize (and then document) the API right now, any further wishes?
One thing I was wondering about was this...
PUB set_basepin(pin) usb_event_pin := pin dm := pin+2 dp := pin+3 ... ' Handle Port protection enable and startup delay mov htmp, usb_event_pin ' I/O + 1 pin is the Serial Host USB Protection enable/disable add htmp, #1 ' Protection enable is a one-time operation drvl htmp ' disable portI know this pin mapping suits the Parallax breakout board HW but other systems may not wish to follow this exact pin sequence and it could be a bit limiting arbitrarily to always have this constraint. Would be good to have an API (or secondary API) to specify the three pins explicitly. I know the dm & dp pair must be sequential but the other two pins do not have to be nearby pins AFAIK. The PASM could be changed to include a protection enable pin rather than be computed the way it is.
Also if the USB code is not reentrant or is single instance only some/all of these pins numbers could possibly be (overridable) constants to save a few COGRAM storage longs. For example why not do
instead of
if it can be done this way? Although you may not want to use pin constants if this driver will be multi-instance capable in the longer term. Is that even going to possible? Not sure...
That's a good catch.
Using single constants would cause clutter and make runtime pin setting not work (unless I add even more clutter).
Multi-instance currently doesn't work (did it ever work? The original orignal driver could be loaded twice for mouse+keyboard, but that may just have worked because the buffers are separate to begin with???) and I don't really see the point as much. Just get a 7-port hub
(Also, if you instantiate two drivers with different configs, they'll work because the compiler duplicates the memory)
Actually, while I'm looking at this, I'll probably remove the event pin mechanism. It's not a good use of a pin. On the accessory board that pin has an LED so it's fine (but I hate random LED blinking so I always disabled that), but if you're doing a custom board you shouldn't have to mess with that.
OK, did all the changes. Also, port protection enable is now optional. You can also configure the offsets from the basepin now or set the pins at runtime explicitly.
Was the purpose of this to notify the client of USB device disconnects/reconnects and various device types being ready etc? That could be useful if you wanted to present something indicating that the user should plug in their devices now etc and to ensure you have what is required before you begin the application. If you now have or intend to make an alternative API mechanism for this type of state/presence information to be obtained it is probably okay to remove the original way.
The event pin mechanism never really worked to begin with for multiple devices. Either gamepad API has presence detection by polling. Mouse/keyboard do not because the accuracy of such would be dubious at best, see earlier.
Ok, I've also moved mouse scrolling into a separate function now (that returns two values so we can read H scroll values later). I think that's the API alright for now.
I've written up a bunch of documentation now: https://github.com/Wuerfel21/usbnew/blob/master/README.MD
Also some more methods and constants changed a bit.
Okay, this is it, version 1.0.0-rc1, get it while it's hot: https://github.com/Wuerfel21/usbnew