Page 3 of 3
Posted: 07 Jan 2016, 11:53
by flabbergast
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.
Posted: 08 Jan 2016, 01:05
by nicstreet
keru wrote: 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.
Posted: 10 Jan 2016, 07:55
by 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.
Posted: 10 Jan 2016, 10:07
by 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).
Posted: 10 Jan 2016, 21:12
by 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.
Posted: 10 Jan 2016, 21:23
by 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.
Posted: 14 Jan 2016, 21:15
by 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.
Posted: 15 Jan 2016, 14:00
by 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.
Posted: 15 Jan 2016, 22:49
by 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.
Posted: 15 Jan 2016, 23:12
by keru
Thanks a lot, it does compile
I'll investigate and report back when/if I get PS/2 to work.
Posted: 16 Jan 2016, 06:56
by 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
Posted: 16 Jan 2016, 19:52
by 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 ?
Posted: 16 Jan 2016, 20:08
by vinnycordeiro
keru wrote: 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.
Posted: 16 Jan 2016, 20:11
by 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.
Posted: 17 Jan 2016, 05:54
by 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 ...
Posted: 17 Jan 2016, 09:33
by 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.
Posted: 18 Jan 2016, 15:27
by 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 ?
Posted: 18 Jan 2016, 16:01
by 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.
Posted: 18 Jan 2016, 23:25
by 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 !
Posted: 22 Jan 2016, 11:33
by 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
Posted: 22 Jan 2016, 11:40
by Laser
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)
Posted: 22 Jan 2016, 12:29
by 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.
Posted: 23 Aug 2016, 07:51
by 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
).
Posted: 30 Dec 2017, 21:26
by 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