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

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
USER_BUTTON_GPIO_Port, USER_BUTTON_Pin
// are now
B1_GPIO_Port, B1_Pin
// same goes for LEDS - some consts are kept ( fcn name, GPIO_PIN_SET, GPIO_PIN_RESET, ..)
HAL_GPIO_WritePin(USER_LED_9_GPIO_Port, USER_LED_9_Pin, GPIO_PIN_SET);
// 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

@Gordon:

.. 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));
    HAL_Delay(50);

    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_Delay(200);
    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 ..

@Gordon:

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