Shop OBEX P1 Docs P2 Docs Learn Events
P2 Hosted USB Keyboard/Mouse - Page 2 — Parallax Forums

P2 Hosted USB Keyboard/Mouse

24567

Comments

  • RossHRossH Posts: 5,336
    garryj wrote: »
    I don't yet have revb silicon to test with but, as @RossH said, the demo code does have commented out code that sets the revb smart pin mode. Switching to the alternate wrpin and wxpin settings should satisfy the revb USB NCO configuration

    ...
    Here is also a link to Chip's post regarding an additional step he had to implement to get it working:
    https://forums.parallax.com/discussion/comment/1475565/#Comment_1475565

    Thanks Garry. Tried all that. No luck. I'm actually beginning to wonder whether my RevB board might be faulty. :(

    Hopefully someone else will try it for us.
  • jmgjmg Posts: 15,140
    RossH wrote: »
    garryj wrote: »
    I don't yet have revb silicon to test with but, as @RossH said, the demo code does have commented out code that sets the revb smart pin mode. Switching to the alternate wrpin and wxpin settings should satisfy the revb USB NCO configuration

    ...
    Here is also a link to Chip's post regarding an additional step he had to implement to get it working:
    https://forums.parallax.com/discussion/comment/1475565/#Comment_1475565

    Thanks Garry. Tried all that. No luck. I'm actually beginning to wonder whether my RevB board might be faulty. :(

    Hopefully someone else will try it for us.

    If Chip has verified P2 ES2 code, maybe he can post that for you to check ?

    Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)
  • RossHRossH Posts: 5,336
    jmg wrote: »
    Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)

    I think you are probably talking about the on-board USB ports. I am using the 64006-ES USB Host adaptor board, and this works on the RevA board. I have also tried it on different pins on both boards, in case some individual pins were faulty. So I don't think that would be it.

    If Chip could post his modified code (which apparently works) that might help identify the problem. Very likely there is some other change he has made to Garry's code that he forgot to mention.

    Ross.
  • cgraceycgracey Posts: 14,133
    RossH wrote: »
    jmg wrote: »
    Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)

    I think you are probably talking about the on-board USB ports. I am using the 64006-ES USB Host adaptor board, and this works on the RevA board. I have also tried it on different pins on both boards, in case some individual pins were faulty. So I don't think that would be it.

    If Chip could post his modified code (which apparently works) that might help identify the problem. Very likely there is some other change he has made to Garry's code that he forgot to mention.

    Ross.

    I've looked and I can't find it. I must have deleted it after I mod'd it and proved it. One problem was that the version of PNut that I'm using has different operators, like |< is now DECOD, and >< is now REV. I remember that all I had to do was change the operators and comment or uncomment some line that selected the Rev B silicon. Once I did those things, it worked fine.
  • RossHRossH Posts: 5,336
    cgracey wrote: »
    I've looked and I can't find it. I must have deleted it after I mod'd it and proved it. One problem was that the version of PNut that I'm using has different operators, like |< is now DECOD, and >< is now REV. I remember that all I had to do was change the operators and comment or uncomment some line that selected the Rev B silicon. Once I did those things, it worked fine.

    I don't think it can be because of the operators, because the same operators (which are not used in the Rev B specific code sections anyway) work on the Rev A board when compiled by PNut_v33k.

    Perhaps your internal version of PNut has another difference?

    Otherwise, I'm a bit stumped :(
  • evanhevanh Posts: 15,126
    edited 2019-11-03 05:02
    I've just given the fastspin compiled version with dual port support a run up on both revA and revB Eval boards. On revA I can plug a mouse in either port and get a readout of position no issue.

    Swapping the commented section and change from -2a to -2b compile option in fastspin, on revB I get the following:
    Sysclock: 160000000, baudrate: 115200
    Tiny client + USB low/full speed keyboard/mouse v0.02.
    USB1 cogID: 1, event pin#: 16, version: v0.05
    USB2 cogID: 2, event pin#: 17, version: v0.05
    
    Which is the same initial messages as revA ... but revA has more, reporting a mouse connected and so on.

  • RossHRossH Posts: 5,336
    edited 2019-11-03 05:08
    evanh wrote: »
    I've just given the fastspin compiled version with dual port support a run up on both revA and revB Eval boards. On revA I can plug a mouse in either port and get a readout of position no issue.

    Swapping the commented section and change from -2a to -2b compile option in fastspin, on revB I get the following:
    Sysclock: 160000000, baudrate: 115200
    Tiny client + USB low/full speed keyboard/mouse v0.02.
    USB1 cogID: 1, event pin#: 16, version: v0.05
    USB2 cogID: 2, event pin#: 17, version: v0.05
    
    Which is the same initial messages as revA ... but revA has more, reporting a mouse connected and so on.

    I haven't tried the dual port version on Rev B. I'll do that now.

    Done: Same result :(
  • evanhevanh Posts: 15,126
    edited 2019-11-03 05:09
    I edited the baud down to 115200 and had to go find the SmartSerial source code ... found it in spin2cpp include files.

  • RossHRossH Posts: 5,336
    evanh wrote: »
    I edited the baud down to 115200 and had to go find the SmartSerial source code ... found it in spin2cpp include files.

    Yes, I had to get a copy of that file as well.

    I am somewhat relieved that it doesn't seem to be just my board! :)

    Ross.
  • RossHRossH Posts: 5,336
    Solved!

    The RevB board has a jumper that says ACC HDR 5V. I never noticed that the jumper was not actually installed - D'oh! :(

    USB drivers (both one and two port) now working as advertised on both RevA and RevB boards!

    Thanks, Garry!
  • cgraceycgracey Posts: 14,133
    Whew!
  • Oh yeah removing that 5v jumper *would* do that. Its a feature : )
  • evanhevanh Posts: 15,126
    Ha! Good find. That jumper is off, for good reason, by default on the revB boards.
  • RossHRossH Posts: 5,336
    evanh wrote: »
    Ha! Good find. That jumper is off, for good reason, by default on the revB boards.

    Under what circumstances would you not want it installed?
  • When you are probing around the board near the breakout board pins and are worried you might short the 5V to a signal pin. It would be an easy thing to do by mistake. It's handy to have this jumper as a protection, but you do need to remember to install it when you want the 5V.
  • Yahoo! ! It was a bit of a bummer being mostly helpless in trying to get this solved.
  • roglohrogloh Posts: 5,122
    edited 2019-12-15 04:43
    @garryj and (perhaps @ersmith ). It appears there is some type of memory bug in the USB code using Fastspin. I am seeing X,Y mouse delta values being written to a structure in a VAR block outside of the USB spin module. I found it when adding the mouse to my video driver. In my own top level driver I have a structure in the VAR block that defines the screen/mode etc and when I was moving the USB mouse the screen would go haywire. Turned out that it was because it was being overwritten. If I move a dummy array to be the first element of the VAR block in my driver it protects the driver as that array is then overwritten instead and the screen was stable. I shouldn't need to do this however.

    Perhaps VAR blocks from different SPIN modules can somehow overlap in FastSpin, or somehow the USB driver is writing into an area it shouldn't be? Hopefully it is just the latter case and can be fixed.

    My video driver uses these VARs:
    VAR
            long dummy[100] ' <--- only put in to protect my critical video structures below from USB mouse data overwrite
    	long region[13]  ' <--- gets corrupted when the dummy array is not present above
    	long display[15]
            long region2[13]
    
    The USB mouse polling example Spin code was taken from KbMObjTest.spin2 and altered slightly to allow me to compute X,Y values and retrieve them (code attached below). It still only uses one VAR.
    VAR
      long usbA
    
    Finally the underlying low level USB driver (1CogKbM.spin2 with revB smartpins) uses these VARs.
    VAR
      long usbcog
    ' Paramter block start address passed to the USB cog via COGNEW parameter
      long mouseData
      long itemAddr
      long itemCount
      long dataVals[32]                                   ' Contiguous cog/lut register/cell values
    ' Parameter block end
    
    When I run my video driver to debug this I dumped the content of the added dummy array before USB is started, and it starts with zeroes.

    00074C94 : 00000000 00000000
    00074C9C : 00000000 00000000
    00074CA4 : 00000000 00000000
    00074CAC : 00000000 00000000
    00074CB4 : 00000000 00000000
    00074CBC : 00000000 00000000
    00074CC4 : 00000000 00000000
    00074CCC : 00000000 00000000
    00074CD4 : 00000000 00000000
    00074CDC : 00000000 00000000
    00074CE4 : 00000000 00000000
    00074CEC : 00000000 00000000
    00074CF4 : 00000000 00000000
    00074CFC : 00000000 00000000
    00074D04 : 00000000 00000000
    00074D0C : 00000000 00000000
    00074D14 : 00000000 00000000
    00074D1C : 00000000 00000000
    00074D24 : 00000000 00000000

    Debug code for doing that is this:
            ser.start(63, 62, 0, baud)       
            waitcnt(cnt+252000000*1)
    
            ser.printf("Hello world\n")
            printhex(@dummy, 100, 4)
            mouse.start(640-1,480-1)  ' <- starts the mouse polling + USB
    
            repeat
              waitcnt(cnt + 252000000)
              ser.printf("-----\n")
              printhex(@dummy, 100, 4)
    
    Then I start the USB mouse driver and continuously display the contents of dummy array after USB is started and when the USB mouse is moved it shows overwritten memory.

    00074C94 : 00000005 00FE0100 <<-- second long is mouse +x/-y deltas, values change as I move the mouse.
    00074C9C : 00000000 00000000
    00074CA4 : 00000000 00000000
    00074CAC : 00000000 00000000
    00074CB4 : 00000000 00000000
    00074CBC : 00000000 00000000
    00074CC4 : 00000000 00000000
    00074CCC : 00000000 00000000
    00074CD4 : 00000000 00000000
    00074CDC : 00000000 00000000
    00074CE4 : 00000000 00000000
    00074CEC : 00000000 00000000
    00074CF4 : 00000000 00000000
    00074CFC : 00000000 00000000
    00074D04 : 00000000 00000000
    00074D0C : 00000000 00000000
    00074D14 : 00000000 00000000
    00074D1C : 00000000 00000000
    00074D24 : 01003005 00000000 <- not sure what this value is but it is affected too

    So something is clobbering memory where it shouldn't. Do you know why @garryj? Should the USB driver write to the very start of the VAR block?

  • Looks like the lowest line in red is the usbA var from the usbmouse.spin2 driver and the data values line up (last byte is COG ID, top byte is mouse connected). The question then becomes why do the different top level + lowest level VAR blocks overlap. Perhaps this is actually a question for @ersmith if it is Fastspin related?

    Hierarchy is this:

    hypvga.spin2
    |-p2videodrv.spin2
    |-SmartSerial.spin
    |-Hyper.spin2
    |-usbmouse.spin2
    |-|-1CogKbM.spin2
  • I also had problems with including Sub-Objects with FastSpin, in my case I had some offset of 52 longs, but that is a couple of month ago and I had to pass the needed value from the top object down to my PASM code in a sub object.

    Mike
  • @rogloh : I know of no reason that addresses in sub-objects would come out wrong in fastspin, and in the simple tests I've performed they work fine. That said, of course I cannot rule out a bug without having the full source code; are you able to share it?

    @msrobots : the bug you described with sub-objects was fixed a long time ago, as far as I know. If you're still having problems, could you please post a bug report with an example? If there is an issue I would like to fix it.
  • evanhevanh Posts: 15,126
    edited 2019-12-17 13:50
  • evanh wrote: »

    Thanks Evan but I don't want to go flailing about trying to reconstruct Roger's problem by piecing together old versions. I'm hoping to get exactly the code that gave him the error he reported on this thread so that I can try to debug it.

  • ersmith wrote: »
    @rogloh : I know of no reason that addresses in sub-objects would come out wrong in fastspin, and in the simple tests I've performed they work fine. That said, of course I cannot rule out a bug without having the full source code; are you able to share it?

    @msrobots : the bug you described with sub-objects was fixed a long time ago, as far as I know. If you're still having problems, could you please post a bug report with an example? If there is an issue I would like to fix it.

    Thank Eric. It's been a few days and my app changed a bit, but I will try to resurrect it back to have the bug back again (shouldn't be hard) and get your the source and listing file etc. Will get to it shortly.
  • Thanks Eric, same with me, I found a workaround and do not have the old code anymore, had to do with TAQOZ driver and since you put that serial scripting in I see a complete new way to use TAQOZ ROM.

    I can start TAQOZ, send serial the mailbox words, TAQOZ mutes its serial and listen to the mailbox at say $10000. And the last command will start a COG at $10008.

    And I compile a FastSpin binary at Org $10008 leaving space for the two long mailbox for TAQOZ.

    One way or the other, but the TAQOZ in ROM needs to be accessible as Object, I have a couple of more Ideas, just not the time.

    Mike
  • roglohrogloh Posts: 5,122
    edited 2019-12-18 01:57
    @ersmith here is the code that reproduces this USB bug on my system, plus binary, plus listing etc. Top level source file is bugtest.spin2.

    You can make the VAR corruption problem happen with or without the mouse present, or with/without VGA breakout fitted etc. If you actually want to see this simple little demo working, fit the VGA breakout on pins 8-15 and dual USB breakout on pins 48-55 (lower port used for mouse), and comment out the infinite serial dump loop that showed the error. You should see the USB mouse moving on the screen and some region scrolling if you click the buttons.

    Also if you remove the dummy VAR that protects the important region structure from being clobbered in bugtest.spin2 you can get the VGA to crash when you move the mouse.

    This might still be a USB driver problem, or a Fastspin problem, or how the USB code is using Fastspin. I am not sure.

    One possibility of why you may not have encountered it before if this turns out to be a Fastspin problem, is that this code uses multi-level deep nesting of spin files and the deepest module's VAR blocks data seems to overlap with the first VAR block. That just might be a special case perhaps.
  • Thanks, Roger. I'll see what I can find out.
  • I got it working on rev B with custom PCB.
    But I see another problem: slew rate of data pins.
    For USB low speed, it is ok. not great, ok.
    For high speed, it doesn't work. The pins of P2 are too slow. I measured 600ns to get a high signal.
    The connected USB keyboard gives a near perfect signal back after 1m of questionable logitech cable.
    On the hardware I have a capacitor on every power supply pin and I don't measure any drop of voltage.
    I think I saw something of a slew rate limiter in the P2, but I can't find it.
    Does anyone else has this problem?
  • cgraceycgracey Posts: 14,133
    The I/O pin should transition in 250ps, unloaded. 600ns indicates it's capacitively loaded somehow. "Full-speed" is the top end of what is possible on the P2, and that signals at 12MHz. So, that needs faster than ~30ns transitions, I think.
  • I just wanted to send you some pictures from scope and PCB.
    Then I saw the fault. I put 100R resistors in series with the pin as protection. But somehow 1k was used.
    swapped it with 100R and it all came to live.
    Full speed USB. I love propeller!
  • ersmith wrote: »
    Thanks, Roger. I'll see what I can find out.

    @ersmith Did you get a chance to take a look yet? It is definitely a bug and reproducable. At times the USB code is writing its output to the wrong location which crashes the code. I can't tell yet whether it is a bug in Fastspin or the USB code, but it could be in Fastspin and I'm leaning towards that now. The USB code is not using the address it is being configured to use but something different. I am sort of wondering if it might be alignment related given it can go away when I change the length of the SPIN code when I add debug code to return an address...
    PUB start(mx, my)
       maxx:=mx
       maxy:=my
       cognew(mouseinit, @usbstack)
       return @usbA  ' <--- when I included this line to debug the code and let me print addresses etc, it wouldn't fail and it would write to the correct VAR address etc, but when I remove it it does fail by writing to the wrong location of the first VAR in a different (and top level) module.  
    
Sign In or Register to comment.