• @stephaneAG, ...the K was a low-hanging-fat-finger-of-a-lame-hand accident on the keyboard... it should just read HLHLHL. Thanks for pointing that out. I have though other crazy sequences used, where shorts and longs - SLSLSLS are mixed with R and G and B: see http://forum.espruino.com/comments/14358­074/ - lines 237..259 where I create red and green Morse code blinking when no other logging is available...

  • Do you have in mind a F4 board

    Not really. However http://www.espruino.com/STM32L496GDISCOV­ERY has a bunch of pins, is fast, and has loads of RAM.

    I was wondering if there's any USB stack on the nRF boards or the MDBT42Q ?

    No, there's no USB at all on the nRF52832. There is on the nRF52840, but apart from a few test builds I have nothing targeting those, and while I had a USB serial test, USB HID gamepad support is miles off.

    how to know if padding is allowed by GCC ?

    You could just print sizeof(your_struct)?

  • @allObjects haha ^^, it seemed so ;P
    On the link you posted, nice Morse code logging ! ( although it was a little cryptic for me at first ;) )

    @Gordon I just had a look at the beast .. indeed, but so sad that it doesn't offer every pins it provides on connectors :/ For my current needs & considering the price I guess an STM32F4DISCOVERY 'd be a nice fit if fully supported by Espruino :)

    On the nRF side, I just saw these & they seem quite neat ;)

    Since I don't know at all the nRF platform, I currently can't be of any help on these :/
    But hey, if the stack doesn't change ( too much ? ) between the kit I have yet to try & the said one, I'll be glad to digg the subject & try things out ;)

    For the struct size stuff, I tried the following quick test ( on laptop since I don't know yet how to get logs .. using stg else than leds now ;p ) and the result is the expected 6 ..

    // gcc test.c -Wall -o test.a
    // nb: could the makefile used  set some padding ?
    [#include](http://forum.espruino.com/sea­rch/?q=%23include) <stdio.h>
    [#include](http://forum.espruino.com/sea­rch/?q=%23include) <stdint.h> /* to use uint16_t & cie */
    int main(void){
    //int main(int argc, char *argv[]){
      struct gamepadHID_t
      {
        uint16_t buttons;
        //uint8_t buttons1;
        //uint8_t buttons2;
        int8_t left_x;
        int8_t left_y;
        int8_t right_x;
        int8_t right_y;
      };
      struct gamepadHID_t gamepadHID;
      gamepadHID.buttons = 0b0000000000000000;
      //gamepadHID.buttons1 = 0b00000000;
      //gamepadHID.buttons2 = 0b00000000;
      gamepadHID.left_x = 0b00000000;
      gamepadHID.left_y = 0b00000000;
      gamepadHID.right_x = 0b00000000;
      gamepadHID.right_y = 0b00000000;
    
      // debug
      printf("struct size (unsigned long): %lu \n", sizeof(gamepadHID) );
    
      return 0;
    }
    

    I'll try things out later today & report back :)

    & before I forget, I saw these links on some way to flash the HM-10 for custom HID stuff if I'm correct :)
    https://geekhack.org/index.php?topic=622­36.0

  • All right, I checked some things out, but it seems the F4 discovery board has been replaced by the STM32F407VG
    Looking for it online, I guess the following is fully ok with Espruino ? https://www.ebay.fr/itm/Stm32f4-Discover­y-Stm32f407-Cortex-m4-Development-Board-­st-link-V2/263287563871?hash=item3d4d296­65f:g:EsEAAOSwhUtbUwub:rk:3:pf:0

    Also, do you think the following could work ok ( maybe with some tweaks* ? ) https://www.ebay.fr/itm/STM32F407VGT6-AR­M-Cortex-M4-32-bit-MCU-Core-Discovery-De­velopment-Board-STM32F4/263106386751

    *reading the following's 1st page, is seems that the onboard chip is the same ? https://ucilnica.fri.uni-lj.si/pluginfil­e.php/21843/mod_resource/content/0/user_­manual_stm_discovery.pdf
    If so, I guess the latter would just require using another board ST-LINK embed programmer or USB-FTDI adapter to get things ready for dev, right ? ( I found this on the topic: https://www.stm32duino.com/viewtopic.php­?f=39&t=2666)

    I 'll have to check the diffs between the former & the latter ( don't know yet what 'T6' stands for ), but the 2nd one's pricing sparks my interest .. ;)
    On this, do you have the formulas to calculate how many jsvars 'd fit for a particular board's flash size ? ( I'd hugely prefer to Digg by myself & not take someone else's time for further investigations )

    thanks :)

  • I think the STM32F407VG discovery is probably just renamed? The one I linked to earlier (the L4) is something ST actually did some work on the Espruino port for though.

    I have no idea if the other board will work - you could try it, but you're on your own.

    For the vars, check out: https://github.com/espruino/Espruino/blo­b/master/README_BuildProcess.md#info

    And for the 52840, there are some posts on it already under the Porting to New Boards section: http://forum.espruino.com/microcosms/767­/

    Porting to other boards is interesting, but I'm afraid I'm super busy and I just can't afford to spend time helping in the porting process.

    Also even if you do get a port, I'm afraid I'm not taking the new board files into Espruino at the moment. I currently have over 50 board files which I have to maintain if anything in the build changes, and I just can't manage any more - even as-is it means I'm dissuaded from making changes to the build process that would improve Espruino.

  • Hi there !

    Thanks for all that :)

    Good to know for the L4 ( I bet the ST guys find Espruino very neat ;p )

    Understood ( for "on my own" on the other board ): so I'll have that kind of fun if trying to do so ;)

    For the 52840, I just checked the topic you linked to: this is pretty cool ( can't wait to test/help on that subject .. & get fully custom HID over USB/bluetooth :D ) !!

    For porting to other boards, I bet you're more than busy hence I'll rely on digging myself & the community to sort things out ;)

    On the build process / build changes / improving Espruino side of things, I wish I had a solution to this but aside from more people full time I have no clues on how to help that ( other than digging & helping myself when I can afford to do so :) ) :/

    On the "xbox360 passthrough" side of things, it seems the Teensy 3.6 offers usb host capability, so I'll try that as well as a tacky transistors+diodes setup ( just to see HOW it fails ;) )
    ( related post on dedicated forum: https://forum.pjrc.com/threads/54026-Tee­nsy-3-6-Xbox360-USB-Passthrough?p=189233­#post189233)

    I'll give back updates as I go :)
    Keep up the good work ++

  • stephaneAG,

    Still interested in xbox360 passthrough? I added xbox360 USB support to the Teensy 3.6 USB host stack. MSF-XINPUT has been updated by others for the latest Teensyduino.

    https://github.com/PaulStoffregen/USBHos­t_t36/pull/22

    I can try an xbox360 pass through. Controller authentication is unlikely since I do not have a console. Should work on PC though. Is the Espruino adaptive controller different from the xbox360 passthrough project? Or are you running Espruino on the Teensy 3.6? I am confused.

  • @gdsports Hi there ! -> Kinda-still-very-much-interested indeed :D

    I was coming here for a quick update & few questions, and your intervention is unexpected & full of hope ^^

    If you want some more infos on controller authentication, I can provide you the links I used while digging the subject :)
    And yes, If you do manage to get an xbox360 passthrough, it should work as expected ( allowing buttons to be either really pressed or "simulated" by the MitM code & gamepad updates to be received (rumble, leds, ..) ).
    Although I bet you could produce code that 'd work as expected to bypass the auth part only from enough infos on the way the gamepad responds once it has been fully authenticated, what about a "little" helper" ? -> as I resurrected my 1st xbox360 & until I send it to my cousin as a gift, what about sending it to you so that you can better work on that hack & have some fun doing so ? :P

    Sorry for the confusion:

    The "Xbox360 passthrough" project would be a very neat addition to the "Espruino adaptive controller" project, since it could allow using it on ALL consoles ( additionally to a computer whatever the operating system its running, as appearing as standard HID peripheral ).

    Once of the reasons I'm digging a board other than the standard Espruino ones while keeping stuff on stm32 platform is:

    • to have more pins available to be used as GPIOs, for bluetooth (hc-05) & for wifi (esp8266) without using an expander/shift register/mux & cie
    • to be able to support a "USB Host" mode with an additional USB connector
    • to be able to reuse code on official Espruino boards

    Hence, two ways to achieve the desired goal(s):

    • have a Teensy + an Espruino ( or run Espruino on the Teensy ? not my case currently .. )
    • have Espruino running on an STM32 board than provides USB Host capability & handling such feature in C++ while providing wrapper(s)/callback(s) in js

    The project is also intended as a rough template for other Espruino-based gamepads & cie ;)

    I successfully achieved HID gamepad on the STM32F407VGT6diymrOE board running only ST's code ( not Espruino ) when connecting to Windows, but for some reason it doesn't appear on Mac OS ( even with the external pull-up resistor trick, and even when pressing the btn prior to connecting the board :/ .. )

    I also had success running an Espruino build meant for the STM32F4DISCOVERY on the STM32F407VGT6diymrOE board & connecting to it via Bluetooth using an hc-05, but not via USB :/

    I'm currently digging ST's USB Host stuff & it's wayyyy over my head tight now :| ( too bad, gotta have to Digg more & harder :p )

    I recently ( yesterday actually ) created a board.py to be able to better match the STM32F407VGT6diymrOE onboard components, but for some reason I can't use 'setUSBHID()' nor the related 'send()' fcn :/ ( I guessed this comes from a flag that isn't set when building - 'USEUSBHID' if I remember correcly, but I didn't intend a custom build yet, as this was one of my questions ;) )

    On the same subject, I wonder if there's a way to set some pins as high by default within the board.py file ? ( I now know it's done in CubeMX or ST's main.c via stuff like HAL_GPIO_WritePin(EXTLED_GPIO_Port, EXTLED_Pin, GPIO_PIN_RESET); ) but I'm not sure how this is handled in the board.py file ..

    I received some necessary parts ( TRRS & TRS connectors, USB connectors ) today & since I can't find the footprints of those, I just finished digging how to do custom footprints on Eagle to "port" my Illustrator drawings as soon as I finish reporting the dimensions & pinouts & go further on this part of the project
    ( I'll post those as well as a link to where they can be purchased in few mins or tomorrow ;) )

    This being said, the following is the board.py file I intend to use for building Espruino from the latest source ( same as the F4discovery but with less stuff / different on it ): I'm still unsure if this 'll work & the exact procedure to produce a clean build but I bet digging the "building" section won't hurt ( should be one of the easier methods since this is a stm32 board .. hoping so ;) )

    #!/bin/false
    # This file is part of Espruino, a JavaScript interpreter for Microcontrollers
    #
    # Copyright (C) 2013 Gordon Williams <gw@pur3.co.uk>
    #
    # This Source Code Form is subject to the terms of the Mozilla Public
    # License, v. 2.0. If a copy of the MPL was not distributed with this
    # file, You can obtain one at http://mozilla.org/MPL/2.0/.
    #
    # ----------------------------------------­----------------------------------------­--------
    # This file contains information for a specific board - the available pins, and where LEDs,
    # Buttons, and other in-built peripherals are. It is used to build documentation as well
    # as various source and header files for Espruino.
    # ----------------------------------------­----------------------------------------­--------
    
    import pinutils;
    info = {
     'name' : "STM32 F407VGT6 diymroe",
     'link' :  [ "https://edoc.site/diy-more-stm32f407vgt­6-boar1-pdf-free.html" ],
     'default_console' : "EV_SERIAL2", # FIXME: This was S2 because of pin conflict. Not sure if it's really an issue? - seemed to work for me for now ..
     'variables' : 5450,
     'binary_name' : 'espruino_%v_stm32f407vgt6diymroe.bin',
     'build' : {
       'optimizeflags' : '-O3',
       'libraries' : [
         'NET',
         'GRAPHICS',
         'NEOPIXEL'
       ],
       'makefile' : [
         [#DEFINES](http://forum.espruino.com/sea­rch/?q=%23DEFINES)+=-DUSE_USB_OTG_FS=1',­
         'DEFINES+=-DUSE_USB_OTG_FS=1 -DUSE_USB_HID=1', # trying to do USB HID stuff on the STM32F4 .. 'd be AWESOME considering the number of pins available
         'STLIB=STM32F407xx',
         'PRECOMPILED_OBJS+=$(ROOT)/targetlibs/st­m32f4/lib/startup_stm32f40_41xxx.o'
       ]
      }
    };
    
    chip = {
      'part' : "STM32F407VGT6",
      'family' : "STM32F4",
      'package' : "LQFP100",
      'ram' : 192,
      'flash' : 1024,
      'speed' : 168,
      'usart' : 6,
      'spi' : 3,
      'i2c' : 3,
      'adc' : 3,
      'dac' : 2,
    };
    
    devices = {
      'OSC' : { 'pin_1' : 'H0',
                'pin_2' : 'H1' },
      'OSC_RTC' : { 'pin_1' : 'C14',
                    'pin_2' : 'C15' },
      'LED1' : { 'pin' : 'E0', 'pinstate' : 'IN_PULLDOWN' }, # may have to be changed to IN_PULLUP ( R: LED goes on when E0 is low - uC sinks it on )
      'BTN1' : { 'pin' : 'D15', 'pinstate' : 'IN_PULLDOWN' }, 1 should be ok ?
      'USB' : { 'pin_otg_pwr' : 'C0',
                'pin_dm' : 'A11',
                'pin_dp' : 'A12',
                'pin_vbus' : 'A9',
                'pin_id' : 'A10', },
      'JTAG' : {
            'pin_MS' : 'A13',
            'pin_CK' : 'A14',
            'pin_DI' : 'A15'
              },
    };
    
    # left-right, or top-bottom order - TODO: find a way to accomodate that ? ( ex: loading my svg with static stuff for now ? )
    board = {
      'left' : [ 'GND', 'VDD', 'GND', 'C1','C3','A1','A3','A5','A7','C5','B1',­'GND','E7','E9','E11','E13','E15','B11',­'B13','B15','D9','D11','D13','D15','GND'­],
      'left2' : [ 'GND', 'VDD', 'NRST', 'C0','C2','A0','A2','A4','A6','C4','B0',­'B2','E8','E10','E12','E14','B10','B12',­'B14','D8','D10','D12','D14','NC','GND']­,
      'right2' : [ 'GND', '5V', '3V3', 'H0', 'C14','E6','E4','E2','E0','B8','BOOT0','­B6','B4','D7','D5','D3','D1','C12','C10'­,'A14','A10','A8','C8','C6','GND'],
      'right' : [ 'GND', '5V', '3V3', 'H1', 'C15','C13','E5','E3','E1','B9','VDD','B­7','B5','B3','D6','D4','D2','D0','C11','­A15','A13','A9','C9','C7','GND'],
    };
    board["_css"] = """
    [#board](http://forum.espruino.com/searc­h/?q=%23board) {
      width: 680px;
      height: 1020px;
      left: 200px;
      background-image: url(img/STM32F407VGT6diymroe.jpg);
    }
    [#boardcontainer](http://forum.espruino.­com/search/?q=%23boardcontainer) {
      height: 1020px;
    }
    [#left](http://forum.espruino.com/search­/?q=%23left) {
      top: 375px;
      right: 590px;
    }
    [#left2](http://forum.espruino.com/searc­h/?q=%23left2) {
      top: 375px;
      left: 105px;
    }
    [#right](http://forum.espruino.com/searc­h/?q=%23right)  {
      top: 375px;
      left: 550px;
    }
    [#right2](http://forum.espruino.com/sear­ch/?q=%23right2)  {
      top: 375px;
      right: 145px;
    }
    """;
    
    def get_pins():
      pins = pinutils.scan_pin_file([], 'stm32f40x.csv', 6, 9, 10)
      return pinutils.only_from_package(pinutils.fill­_gaps_in_pin_list(pins), chip["package"])
    
    

    The attached file ( if upload works ) is the pinout for the board + few handy wip notes ( I didn't take/have the time to do a proper "background-image" for the doc part, but this is incredibly handy as is as well ;P )


    2 Attachments

  • all right, I still hope to find the footprints corresponding to those connectors, but at least now I have something to start with :) ( fingers crossed I won't have any troubles on Eagle side .. ) :)


    2 Attachments

  • @stephaneAG
    I think an open source adaptive controller (compare with Microsoft Xbox Adaptive Controller) is a great idea and have been working on using the Teensy 3.6 as a USB pass through for this.

    In pass through mode, buttons and sticks work. Rumble and LEDs TBD. No support for console authentication. Tested on Linux running jstest-gtk and Windows 10 gamepad properties test. Also tested on the Steam/Valve network using the controller settings window.

    More than one controller may be connected at the same time using a USB hub. All controller output is combined to the XBOX360/Xinput emulator output. This is similar to the Xbox co-pilot feature because more than one controller can used to play one person in a game.

    Since the pass through is based on the PJRC joystick/gamepad example program, Xbox 360, Xbox One, PS3, and PS4 (?) controllers are supported. PS4 controller is still flaky. Mostly it comes down to remapping buttons from the PS4 to the corresponding buttons on the Xbox360.

    Hold on to the Xbox 360 console. I do not think I will have time to look at controller auth. Perhaps some one else would like to tackle that part. Same for Espruino and ESP8266. A Teensy 3.6 XBOX360 adaptive controller for Windows, Linux, and Steam games seems useful on its own. I do not know if it works on Mac since I do not have one.

    Twenty digital inputs all on the same side of the Teensy 3.6 board are set as INPUT with internal pull ups. A switch or button that grounds the input is detected as a button activation. I think assistive tech buttons/switches connect ground when pressed so this should work. The first eleven inputs map to the eleven buttons on the XBOX360 controller. The four more could be mapped to D pad inputs (TBD).

  • Hi there :)

    nice work !

    For the rumble & LEDs, this could be really cool since we could update onboard stuff to reflect that ;)

    For the "more than one controller connect" / Xbox co-pilot feature, it's also pretty cool ( I actually didn't know Microsoft offered such functionality ).

    I didn't took the time to test the PJRC Joystick/gamepad example, only dogged through it among many other files to get an overview of how things were implemented ( I was planning to mod MSF-XINPUT to not auto-release stuff & press stuff received over serial as latest test using a teensy & the xbox360 part of things )

    If mapping it all that's needed to get rid of the flakiness of the PS4 controller, I'd be happy to Digg that part when having time to doing so :)

    On the controller auth part, I honestly am still way too weak to produce it by myself, but I plan to continue digging the USB Host stack on the smt32 as well as figuring out how to handle that kind of event ( I guess the author of MSF-XINPUT may know or have some hints, since this boils down to knowing when a "led event" is received for the first time ( providing visual feedback of connection & on which player number is assigned to which controller ) & passing stuff through a different pipe when receiving some from the host console )

    If you say so, I guess I'll then hold on to it for later ..

    For the usefulness of an adaptive controller ( Teensy or Espruino based ) for Windows/Linux/Steam/Mac, I totally agree, and I guess this will be the first version released ( able to connect over bluetooth or usb as HID since Windows/Linux/Mac need no drivers whatsoever & Steam surely can use HID-compliant devices )

    On the way assistive tech devices works, I'll have to investigate too, and was indeed planning for such implementation ( the joystick connected to the sides of the adaptive controller will get 4 lines though, +V, X, Y & Gnd )

    Last but not least, I'd be happy to fiddle with your code if you were to drop by some zip file ;)

  • Hi there !

    I finally took the time to write a "little" helper after digging stuff online & not finding exactly what I was after ..

    .. "tadaa": https://github.com/stephaneAG/EAGLE-stuf­f/blob/master/Protographer/README.MD

    The above, while not yet supporting "pads", was indeed quite useful to quickly draw stuff Eagle side :)

    The below image shows the footprints created by it ( the one with the pads had the pads added manually )

    I'll have to add the needed buttons to the schematic ( as well as battery charging & cie ) & the footprint for an HC-05 & an XS3868

    For the uC part, I guess I'll prepare a "breakout" embedding all the necessary & then provide declinations offering different uC pins ( or the pads for directly soldering a uC - I wonder if I'll be precise enough to solder some SMD parts, since I only practiced that while switching memory ICs on ESP8266 :| .. so wayyy not confident on drag soldering a stm32f407VGT6 myself .. ;p )


    3 Attachments

    • illustratorToEagle_PolygonsMadeOfFakeCurvesWithManyAnchorPts.png
    • eagleFullSch_buttonsToBeAdded.png
    • partDrawingInIlustrator1.png
  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino USB HID GamePad - v0.1a ready ! ( may also be Bluetooth & RN42 ready .. )

Posted by Avatar for stephaneAG @stephaneAG

Actions