TMK support for ARM Teensies

[flabbergast]

2. clone chibios (I did it using https://github.com/ChibiOS/ChibiOS.git) into tmk_core/tool/chibios/chibios

Just a note - for kinetis devices (teensies, infinity, whitefox) you'll need my patches to chibios (which doesn't have enough of kinetis support in the main line yet) from https://github.com/flabbergast/ChibiOS.git, kinetis branch.

[nicstreet]

Hi Nic,
Nope I never tried, I don't even have a windows box
In order to compile you have to :
1. checkout flabbergast's repository at the chibios branch
2. clone chibios (I did it using https://github.com/ChibiOS/ChibiOS.git) into tmk_core/tool/chibios/chibios
3. configure stuff in your keyboard project, you can get started using the stm32_f103_onekey project

What are your errors/issues ?
Are you able to compile TMK for AVRs using the main repository, or do you also have issues ?
What board are you trying to compile for ?

Cheers keru

I've not had much time today so further diagnosis may have to wait until Friday evening or the weekend. I got a Debian VM stood-up earlier just in case. I'll also spend a bit of time trying to understand GIT a bit more, may help for the future.

[keru]

Just in case :
I'm not sure why yet but I had issues with the ADC.

While trying to update the tmk repo, I borked my chibios checkout.
So I cloned a clean new version, master is too new and too many things changed. I checkout the stable_3.0.x and I add OPT_DEFS += -DSTM32F10X_MD to my makefile (not sure why or even if I selected the right device, but so far it works )

compiled, and now my ADC works too. I still have to investigate if it was related to my code or the repo, but I thought that could help in case someone hase something similar.

commands I ran :

Code: Select all

# update tmk firmware with main and flabbergast's version
cd tmk_keyboard
git pull  https://github.com/tmk/tmk_keyboard.git master
git pull https://github.com/flabbergast/tmk_keyboard.git chibios
# go the right place this time
cd tmk_core/tool/chibios
# delete the borked chibios clone
rm -rf chibios
# fresh clone
git clone https://github.com/ChibiOS/ChibiOS.git chibios
cd chibios
# checkout stable version 3.0.x
git checkout stable_3.0.x

Now I 'just' have to finish coding my joystick-mouse
Apart from that, I find the firmware to work well, and debugging using print and hid_listen is really helpful, especially to figure out what thread is started or not and where something seems to break.

[flabbergast]

Very nice work!
(If you'd be willing to share your code, I can give you push access to my tmk fork.)
BTW the newest chibios *is* still 3.0.x line; but the author (Giovanni) has decided to change the release numbering to <year>.<month>.<release>. The changes since 3.0.2 haven't been fundamental, but a couple of them may require adjusting the app code (e.g. adding watchdog driver to HAL, which requires an extra #define in halconf.h).

[keru]

Thanks ! I think it's best if I make a pull request, as I'm not 100% sure I did things correctly, so a code review could help.

I still have a lot to fix and cleanup and then I'll send a PR.

Also, with the ADC, I'm reading a joystick in order to use it as a mouse. Do you know if I should try to make it fit the same way as ps2_mouse, in protocol, or should I keep it in my keyboard folder ?

For the chibios version, when I compiled the documentation from the master it was showing version 4, and it was missing a few things like usbPrepareTransmit. That's why I explicitly checked out the 3.0.x branch. I'll check the dated release branch, thanks for the information.

[flabbergast]

With joystick/ADC - if you could make it into a separate module (like the ps2 stuff), that would be best I think.

Ah, about the USB: Giovanni did make some changes to the STM32 USB driver recently: http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=3062 so perhaps it's related to that.
EDIT: Yes, it is this. I guess I tested compiling in the time between it was announced and the changes propagated into git, so that I thought it should be fine. This will require some fixing.

[keru]

I posted my code and my issues here https://geekhack.org/index.php?topic=78634.0

My branch is far from ready to merge as I want to make sure I can have some PS/2 at the same time.

[flabbergast]

I'll try to get a hold of some PS/2 mouse and help with testing. I'll ask for some code when I have some hardware to test.

At the moment I'm updating the code to the new USB API in chibios, so that we can use the most recent chibios code.

[flabbergast]

OK, so the code is updated for the new USB API. This means that the current git TMK code needs my current chibios/kinetis branch (for kinetis chips); for STM32 chips you can also use current official chibios git.
TL;DR: when you pull from git now, you need to pull all the projects.

[keru]

Thanks a lot, it does compile I'll investigate and report back when/if I get PS/2 to work.

[keru]

Here is a bit of debug I was able to do :
- I created a function to put my pins in different modes and alternate

Code: Select all

void debug_data_lines(void) {
  uint8_t rcv;
  data_init();
  clock_init();
  // Set Data and Clock low
  wait_ms(1);
  data_lo();
  clock_lo();
  wait_ms(1);
  // set clock input and data out, data low
  print("clock should read 0 ");
  phex(clock_in()); print("
");
  wait_ms(1);
  // set clock input and data out, data high
  data_hi();
  wait_ms(1);
  print("clock should read 1 ");
  phex(clock_in()); print("
");
  wait_ms(1);
  // set clock output and data input, clock low
  clock_lo();
  wait_ms(1);
  print("data should read 0 ");
  phex(data_in()); print("
");
  // set clock output and data input, clock high
  wait_ms(1);
  clock_hi();
  wait_ms(1);
  print("data should read 1 ");
  phex(data_in()); print("
");
  // set clock input and data out, data low
  wait_ms(1);
  data_lo();
  wait_ms(1);
  print("clock should read 0 ");
  phex(clock_in()); print("
");
  wait_ms(1);
  // set clock input and data out, data high
  data_hi();
  wait_ms(1);
  print("clock should read 1 ");
  phex(clock_in()); print("
");
}

- I connected the DATA pin and CLOCK pin that I defined in my config.h and looked at hid_listen's output : none of them were moving

Code: Select all

clock should read 0 00
clock should read 1 00
data should read 0 00
data should read 1 00
clock should read 0 00
clock should read 1 00

- so I tried different setups and found that I could get results by setting my outputs opendrain with pulldowns in tmk_core/protocol/ps2_io_chibios.c

Code: Select all

#define PAL_STM32_PUDR_PULLDOWN         (2U << 5U)
...
palSetPadMode(PS2_CLOCK_PORT, PS2_CLOCK_PIN, PAL_MODE_OUTPUT_OPENDRAIN|PAL_STM32_PUDR_PULLDOWN);
...

- now I get

Code: Select all

clock should read 0 00
clock should read 1 01
data should read 0 00
data should read 1 01
clock should read 0 00
clock should read 1 01

I'm not entirely sure why, maybe the fact that before that neither my output nor my input had a state made them impossible to read, but now at least I'm sure my *_in,*_lo,*_hi do what they are supposed to and I can try to debug further ...

Also, I forgot to say, but I always forget to do make clean before my make and that messed me up a lot

[keru]

I think my issue ... and that's going to seem obvious ... is that PS2 takes 5v, and the STM32's output are 3.3V ... Is there a way to output 5V from the MCU ?

[vinnycordeiro]

I think my issue ... and that's going to seem obvious ... is that PS2 takes 5v, and the STM32's output are 3.3V ... Is there a way to output 5V from the MCU ?

No, but what you are seeking is a level shifter circuit/IC. That can be made with MOSFETs or with a dedicated IC.

[flabbergast]

Ah shoot, forgot about that as well. No, the ARM chips can't pull anything higher than 3.3V. There are essentially two options:
1) Will work with any ARM chip. Use a transistor or a buffer or something like that. For instance Teensy LC has a buffer on board exactly for that reason (see the schematic for LC, pin 17). EDIT: I think this is what Vinny meant.
2) Some ARM chips have 5V tolerant inputs (usually it's a subset of the pins, not all). So, if the PS/2 lines can be externally pulled up to 5V, the chip will survive, and is able to pull them down. (This is a way to interface 5V devices/sensors with 3.3V MCUs for instance over I2C, where the communication happens from both sides by pulling down.)

EDIT2: Yes, PS/2 protocol works like that, lines are pulled up (can be with external pull-up resistors) and the MCU or device are supposed to pull them down. So 2) is viable, as long as the ARM can survive it.

[keru]

for the 2) There is something I think I'm missing ...
I see how it works when my pin is set as an output-opendrain with a 5V pull-up.

But when I set my pin as an input, should I also set some pull-something resistor ? or I just leave it floating, and when the PS/2 side sets 0, my MCU will read 0 else it will read 1 ?

Sorry if my question is not clear, but I didn't find anything explaining the setup when the pin mode changes from output to input ...

[flabbergast]

The pull-up resistor is always there, outside of the chip, so the line is always high, unless something (either MCU or PS/2 side) pulls it down. So exactly, if you need the pin as an output, you'd use open drain. For input, you should set it as input (floating). Since the line is pulled up externally, the MCU will read it high when nothing is going on; when something (PS/2 side) pulls it down, the MCU will read 0.

I think it's not a good idea to set that kind of pin as input-pull-something. Pull-down would just make the situation look like a classic voltage divider: a line with a resistor R1 to 5V and resistor R2 to GND, which is not what you're trying to achieve. Pull-up similarly, dividing between 3.3V (MCU) and 5V (external).

Two notes:
- really make sure that the pin is 5V tolerant before you try this (this should be in the datasheet), otherwise you may damage the chip. ARMs are way more fragile than AVRs.
- If you don't want to keep switch the modes, you can just wire the line to two pins (both 5V tolerant!), and use one as input and one as output (open-drain).

EDIT: I had a look at STM32F103x8/B, page 28 on, and the pins marked "FT" in the "I/O Level" column are 5V tolerant. That's good; because Kinetis KL2x line (e.g. Teensy LC) or the earlier K20x (Teensy 3.0) have *no* 5V tolerant pins.

[keru]

Thanks a lot, I tried the 5V pull-up, I seem to actually be able to have 5V on one of the pins, but my firmware still doesn't work.
The reset pin for example reads 3.3V but it is wired the same way, I wonder if it's because somewhere this pin is set as input with pull-something, but I don't find where.
Also my firmware seems to spend a long time before initializing the keyboard, I can't find a blocking wait that could be before, I'm thinking it's the mouse init that is waiting a long time to get a clock.

I connected each of my pins to a resistor tied to 5V, that's 3 resistors : Data, Clock and Reset. Would that make one line pull another one down ?

Finally, should I start a new thread for my PS/2 debugging so I don't pollute here ?

[flabbergast]

Not sure about the reset line (my googling shows PS/2 uses only 2 lines, clock and data; even hasu's TMK code seems to use only 2, based on the ascii picture in the README).

It would be probably good to start a new thread about this.

I'll try to get some PS/2 hardware so that I can try myself. I have STM32F072-DISCOVERY board, which has an integrated debugger, that tends to help a lot. Consider getting a st-link v2 for debugging (should be <$3 on ebay from china) - you can step through the program as it is running on the chip, set breakpoints and things like that.

[keru]

I ordered a st-link v2 it will take some time to get here

The reset pin seem to be specific to trackpoints. I'll try again with a normal PS/2 mouse in case the mouse was not in fact defective.

It seems some USB devices can be passively converted to PS/2, maybe I can find a way to use a working USB device as PS/2 to debug my PS/2 to USB converter .... I know it's messed up but I have to figure out something

I opened another thread http://deskthority.net/workshop-f7/tmk- ... 12666.html thanks a lot for the help !

[tentator]

I've a Question, what about this one:
http://www.aliexpress.com/item/For-Ardu ... 9.8.0KOirZ
is it supported? sounds cheap and full of I/Os as well but still with the beloved 32u4...?

tent

[Laser]

I've a Question, what about this one:
http://www.aliexpress.com/item/For-Ardu ... 9.8.0KOirZ
is it supported? sounds cheap and full of I/Os as well but still with the beloved 32u4...?

tent

I used something like that with Soarer's controller (here), you just have to know how to map the Teensy pinout to Arduino. Except the bootloader part, it should work also with TMK (since the Arduino Micro is basically a Pro Micro with a reset button and some more pins, and the Pro Micro *can* be used with TMK, as it is proved somewhere in this thread)

[flabbergast]

Yes, this is just a clone of Arduino Micro. It uses atmega32u4 from ATMEL, AVR8 architecture. It is supported by "classic" TMK, without any extra additions. It is *not* an ARM chip.

[clickclack123]

Would anyone mind writing a quick TLDR on how I can get TMK running on a "Blue Pill" STM32F103C8T6 "STM32 Minimum System Development Board" like this one I just ordered?

There's a lot of info in this thread, it's hard for me to understand where to start. Is there a git repo that I can easily clone to start off to play with?

I'm totally new to STM32, just ordered a programmer as well (both an st-link and a j-link - couldn't decide which one to get ).

[profet]

Sorry for the thread rez, but I am curious about the one key example for the TeensyLC I am able to compile and load the firmware just fine, but I can't for the life of me figure out which hardware pins on the TeensyLC are configured for the matrix.

Looking at the code it seems to be Pins 2 and 5... but those dont' seem to register a key press when jumped.

Am I wrong? Or is the code in a state of broken?

EDIT:

I actually got this working in TMK... silly me thought it would work in QMK... but seems like ARM support for the Teensy One Key example is broken in QMK master