Avatar for stephaneAG


Member since Jun 2014 • Last active Dec 2018
  • 14 conversations

'love hackety trick

Most recent activity

  • in Projects
    Avatar for stephaneAG

    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 )

  • in Projects
    Avatar for stephaneAG

    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 ;)

  • in Projects
    Avatar for stephaneAG

    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 .. ) :)

  • in Projects
    Avatar for stephaneAG

    @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 ;) )

    # 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' : [
       'makefile' : [
         '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
    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 )

  • in News
    Avatar for stephaneAG

    nice !

    especially the graphics & storage stuff ;)

    keep it up :)

  • in Projects
    Avatar for stephaneAG

    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 ++

  • in Projects
    Avatar for stephaneAG

    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 :)

  • in Projects
    Avatar for stephaneAG

    @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 :)

  • in Projects
    Avatar for stephaneAG

    Back ;)

    @allObjects thanks for the confirmation, I guessed so but wasn't quite sure ;)
    This being said, in your 'HLHKLHL' chunk, does 'K' stands for tri-state/floating ? ( or is it just that you typed quite fast & that the 'K' keystroke was not meant to happen ? ^^ )
    I read so for the 'bundle auto configured pins' & cie in the pinMode ref, but didn't actually do tests on pinMode to consider it a resource hog ;)
    If theres' no need to 'force' it by using pinMode ( as Gordon says ) I guess I can consider this 'solved' ('d be better actually test 1st, but the logic is validated :) )

    @Gordon I don't know enough yet on the F3 USB stack to even consider being able to see the differences between it & the F1's / F4's so yup, switching boards is 'd be indeed a 'faster & safer' way ( although I could acquire quite a - not that useful afterward- knowledge on their particular implm changes ..)
    Digging how to do stuff directly on the F3 already showed me some changes that did happen

    // basic example of changes in namings of constants
    // are now
    B1_GPIO_Port, B1_Pin
    // same goes for LEDS - some consts are kept ( fcn name, GPIO_PIN_SET, GPIO_PIN_RESET, ..)
    // is now
    HAL_GPIO_WritePin(LD9_GPIO_Port, LD9_Pin, GPIO_PIN_SET);

    If I recall coreectly, I noticed some Espruino files you pointed me to use 'stdPeriph' stuff & not HAL ? ( I may be incorrect on this, I'm still getting my head around the stm32f platform ..)

    On the examples I'm currently trying, I gotta switch from HID to CDC* ( then try the combo ;p ) & implement the xbox360 controller on that. If I manage to do so, adding its functionnality to Espruino builds would then 'just' be some js wrappers for C++ calls ( but this is a part I have yet to discover & cover ;P )

    *to try an example doing UART communication with either a laptop or another uC. next on the list is I2C, then SPI ;)

    Do you have in mind a F4 board that would be a kick ass with many pins ? I plan ( & 'd love ) to use Espruino on a client project but I have to use something reliable ( so not my own mess around the F3 .. ), and since it focuses on an 'Escape Game' room, having plenty of pins is quite handy :D

    On the "Espruino Open Adaptive gamepad' topic, I was wondering if there's any USB stack on the nRF boards or the MDBT42Q ?

    My reasons:

    • I really wished a flashed HC-05 allowed custom HID over bluetooth, but it doesn't ( only presets )
    • I need something that can appear as a custom periph( HID or xbox360controller ) over USB
    • having embed WiFi is a plus, allowing realtime buttons mapping changes through an app on laptop/tablet/smartphone when connecting the uC as either a server or client while acting as a bluetooth or usb device

    Currently, I'm using an Espruino WiFi for the wifi part & the usb HID part, & a teensy for the xbox360controller part
    Once I achieve an xbox360controller on the Espruino WiFi over USB, I won't need the teensy anymore, but 'd still need a platform to do custom HID ( & more ? ) over bluetooth ..
    The best 'd be a board that offers both & works fully with Espruino with plenty of pins :p


    .. GCC/whatever is padding the elements inside gamepadHID_t to 4 byte boundaries* ..
    .. ooks like it's 6 bytes but it may get reported as 8**. ..
    I'll have to digg those, yet it seems the Gamepad HID I implemented on the f3 acts as expected using the following:

    // while(1)
    if(HAL_GPIO_ReadPin(B1_GPIO_Port, B1_Pin) == GPIO_PIN_SET){
        HAL_GPIO_WritePin(LD9_GPIO_Port, LD9_Pin, GPIO_PIN_SET);
        // stuff is set above in code, whatever the 'actual' state of the button press ..
        USBD_HID_SendReport(&hUsbDeviceFS, &gamepadHID, sizeof(struct gamepadHID_t));
        gamepadHID.buttons = 0;
        gamepadHID.left_x = 0;
        gamepadHID.left_y = 0;
        gamepadHID.right_x = 0;
        gamepadHID.right_y = 0;
        USBD_HID_SendReport(&hUsbDeviceFS, &gamepadHID, sizeof(struct gamepadHID_t));
        HAL_GPIO_WritePin(LD9_GPIO_Port, LD9_Pin, GPIO_PIN_RESET);

    *, ** how to know if padding is allowed by GCC ? do you have a quick way to log the size of a report being sent ? ( I'm windering how much I'd need to mod the HID code I'm using to be able to use one of the available uarts to print debig stuff .. since I don't know gdb yet :/ .. )
    From my tests on another little program, using the struct with on uint16_t or 2 uint8t led, quite logically, to 6 bytes, but I wonder how to get the 'final' report size before its gets sent over ..


    RN42 links and code
    -> my pleasure ;P

    ps: I plan to produce 3ds for the 'espruino_OpenAdaptiveController.pdf ' at the end of the week :)
    ps2: I wonder how much more 'd be involved to get a 'modified' Espruino WiFi board with more broken out pins ( fro the datasheet, 35/50/81 ? :D )

    I'll be back with updates as soon as can do, as usual :)

    Big thanks for the hints ;)