-
-
Notifications
You must be signed in to change notification settings - Fork 39.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for ErgoDox with STM32 Microcontroller #5398
Merged
Merged
Changes from all commits
Commits
Show all changes
25 commits
Select commit
Hold shift + click to select a range
a392fb4
Began Work On STM32 Ergodox
Codetector1374 079fbc4
test
Codetector1374 304cd5b
Now it compile. Not linking thou
Codetector1374 c2b9529
Screw this Linker. It links now!
Codetector1374 06f9f2a
Blinkly Keyboard
Codetector1374 4927abe
bootloader test code
Codetector1374 23b445a
Working on matrix / i2c stuff
Codetector1374 3c5251f
Progress (LED Blink)
Codetector1374 0365c92
Progress on MCP_23017 Status Flag
Codetector1374 cf99732
[WIP]
Codetector1374 fd84782
update
Codetector1374 1f1f23c
Works! Remeber to change back the bootloader address when the new boo…
Codetector1374 ee657d7
Time to go debug the i2c
Codetector1374 ec07114
Finally, it now works with PCB Rev 1.0.2
Codetector1374 222e791
updated for rev.2 pcb
Codetector1374 082de2c
minor compilation fix
Codetector1374 4378d6c
Merge remote-tracking branch 'upstream/master' into ergodox_stm32
Codetector1374 224637b
Why when debugger is enabled then everything works.
Codetector1374 3438cad
Remeber to call init functions.
Codetector1374 35591b3
Update arm i2c driver to support STM32F103 series device.
Codetector1374 f7b501d
fix include once header. Replaced with #pragma once.
Codetector1374 86db0c2
Merge remote-tracking branch 'source/master' into ergodox_stm32
Codetector1374 c4ec830
complication test
Codetector1374 20ae9ce
Merge branch 'master' into ergodox_stm32
Codetector1374 6ef3d88
fix conflict and support for latest gcc
Codetector1374 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
51 changes: 51 additions & 0 deletions
51
keyboards/ergodox_stm32/boards/ERGODOX_STM32_BOARD/board.c
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,51 @@ | ||
/* | ||
ChibiOS - Copyright (C) 2006..2016 Giovanni Di Sirio | ||
|
||
Licensed under the Apache License, Version 2.0 (the "License"); | ||
you may not use this file except in compliance with the License. | ||
You may obtain a copy of the License at | ||
|
||
http://www.apache.org/licenses/LICENSE-2.0 | ||
|
||
Unless required by applicable law or agreed to in writing, software | ||
distributed under the License is distributed on an "AS IS" BASIS, | ||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
See the License for the specific language governing permissions and | ||
limitations under the License. | ||
*/ | ||
|
||
#include "hal.h" | ||
|
||
/** | ||
* @brief PAL setup. | ||
* @details Digital I/O ports static configuration as defined in @p board.h. | ||
* This variable is used by the HAL when initializing the PAL driver. | ||
*/ | ||
#if HAL_USE_PAL || defined(__DOXYGEN__) | ||
const PALConfig pal_default_config = | ||
{ | ||
{VAL_GPIOAODR, VAL_GPIOACRL, VAL_GPIOACRH}, | ||
{VAL_GPIOBODR, VAL_GPIOBCRL, VAL_GPIOBCRH}, | ||
{VAL_GPIOCODR, VAL_GPIOCCRL, VAL_GPIOCCRH}, | ||
{VAL_GPIODODR, VAL_GPIODCRL, VAL_GPIODCRH}, | ||
{VAL_GPIOEODR, VAL_GPIOECRL, VAL_GPIOECRH}, | ||
}; | ||
#endif | ||
|
||
/* | ||
* Early initialization code. | ||
* This initialization must be performed just after stack setup and before | ||
* any other initialization. | ||
*/ | ||
void __early_init(void) { | ||
|
||
stm32_clock_init(); | ||
} | ||
|
||
/* | ||
* Board-specific initialization code. | ||
*/ | ||
void boardInit(void) { | ||
AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_JTAGDISABLE; | ||
|
||
} |
142 changes: 142 additions & 0 deletions
142
keyboards/ergodox_stm32/boards/ERGODOX_STM32_BOARD/board.h
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,142 @@ | ||
/* | ||
ChibiOS - Copyright (C) 2006..2016 Giovanni Di Sirio | ||
|
||
Licensed under the Apache License, Version 2.0 (the "License"); | ||
you may not use this file except in compliance with the License. | ||
You may obtain a copy of the License at | ||
|
||
http://www.apache.org/licenses/LICENSE-2.0 | ||
|
||
Unless required by applicable law or agreed to in writing, software | ||
distributed under the License is distributed on an "AS IS" BASIS, | ||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
See the License for the specific language governing permissions and | ||
limitations under the License. | ||
*/ | ||
|
||
#ifndef _BOARD_H_ | ||
#define _BOARD_H_ | ||
|
||
/* | ||
* Board identifier. | ||
*/ | ||
#define BOARD_JM60 | ||
#define BOARD_NAME "ErgoDox STM32 Keyboard" | ||
|
||
/* | ||
* Board frequencies. | ||
*/ | ||
#define STM32_LSECLK 0 | ||
#define STM32_HSECLK 8000000 | ||
|
||
/* | ||
* MCU type, supported types are defined in ./os/hal/platforms/hal_lld.h. | ||
* | ||
* Only xB (128KB Flash) is defined, but it's identical to the | ||
* x8 version (64KB Flash) except for the Flash region size in the | ||
* linker script. For x8 parts use xB here and change to the x8 linker | ||
* script in the project Makefile. | ||
*/ | ||
#define STM32F103xB | ||
|
||
/* | ||
* IO pins assignments | ||
* | ||
* numbering is sorted by onboard/connectors, as from the schematics in | ||
* http://www.vcc-gnd.com/read.php?tid=369 | ||
*/ | ||
|
||
/* on-board */ | ||
#define GPIOA_USBDM 11 // pin 8 | ||
#define GPIOA_USBDP 12 // pin 9 | ||
|
||
#define GPIOC_OSC32_IN 14 | ||
#define GPIOC_OSC32_OUT 15 | ||
|
||
/* | ||
* I/O ports initial setup, this configuration is established soon after reset | ||
* in the initialization code. | ||
* | ||
* The digits have the following meaning: | ||
* 0 - Analog input. | ||
* 1 - Push Pull output 10MHz. | ||
* 2 - Push Pull output 2MHz. | ||
* 3 - Push Pull output 50MHz. | ||
* 4 - Digital input. | ||
* 5 - Open Drain output 10MHz. | ||
* 6 - Open Drain output 2MHz. | ||
* 7 - Open Drain output 50MHz. | ||
* 8 - Digital input with PullUp or PullDown resistor depending on ODR. | ||
* 9 - Alternate Push Pull output 10MHz. | ||
* A - Alternate Push Pull output 2MHz. | ||
* B - Alternate Push Pull output 50MHz. | ||
* C - Reserved. | ||
* D - Alternate Open Drain output 10MHz. | ||
* E - Alternate Open Drain output 2MHz. | ||
* F - Alternate Open Drain output 50MHz. | ||
* Please refer to the STM32 Reference Manual for details. | ||
*/ | ||
|
||
/* | ||
* Port A setup. | ||
* Everything input with pull-up except: | ||
*/ | ||
#define VAL_GPIOACRL 0x88888888 /* PA7...PA0 */ | ||
#define VAL_GPIOACRH 0x88888888 /* PA15...PA8 */ | ||
#define VAL_GPIOAODR 0xFFFFFFFF | ||
|
||
/* | ||
* Port B setup. | ||
* Everything input with pull-up except: | ||
*/ | ||
#define VAL_GPIOBCRL 0x88888888 /* PB7...PB0 */ | ||
#define VAL_GPIOBCRH 0x88888888 /* PB15...PB8 */ | ||
#define VAL_GPIOBODR 0xFFFFFFFF | ||
|
||
/* | ||
* Port C setup. | ||
* Everything input with pull-up except: | ||
*/ | ||
#define VAL_GPIOCCRL 0x88888888 /* PC7...PC0 */ | ||
#define VAL_GPIOCCRH 0x88888888 /* PC15...PC8 */ | ||
#define VAL_GPIOCODR 0xFFFFFFFF | ||
|
||
/* | ||
* Port D setup. | ||
* Everything input with pull-up except: | ||
* PD0 - Normal input (XTAL). | ||
* PD1 - Normal input (XTAL). | ||
*/ | ||
#define VAL_GPIODCRL 0x88888844 /* PD7...PD0 */ | ||
#define VAL_GPIODCRH 0x88888888 /* PD15...PD8 */ | ||
#define VAL_GPIODODR 0xFFFFFFFF | ||
|
||
/* | ||
* Port E setup. | ||
* Everything input with pull-up except: | ||
*/ | ||
#define VAL_GPIOECRL 0x88888888 /* PE7...PE0 */ | ||
#define VAL_GPIOECRH 0x88888888 /* PE15...PE8 */ | ||
#define VAL_GPIOEODR 0xFFFFFFFF | ||
|
||
/* | ||
* USB bus activation macro, required by the USB driver. | ||
*/ | ||
#define usb_lld_connect_bus(usbp) /* always connected */ | ||
|
||
/* | ||
* USB bus de-activation macro, required by the USB driver. | ||
*/ | ||
#define usb_lld_disconnect_bus(usbp) /* always connected */ | ||
|
||
#if !defined(_FROM_ASM_) | ||
#ifdef __cplusplus | ||
extern "C" { | ||
#endif | ||
void boardInit(void); | ||
#ifdef __cplusplus | ||
} | ||
#endif | ||
#endif /* _FROM_ASM_ */ | ||
|
||
#endif /* _BOARD_H_ */ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# List of all the board related files. | ||
BOARDSRC = $(BOARD_PATH)/boards/ERGODOX_STM32_BOARD/board.c | ||
|
||
# Required include directories | ||
BOARDINC = $(BOARD_PATH)/boards/ERGODOX_STM32_BOARD |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yiancar since I think you're more familiar with this, any issues with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything else I should improve about this? Or is this good to merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually have never checked what API the f1 uses. Just to make sure @awkannan any takes on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer more general means of determining the i2c code to use rather than a specific MCU symbol definition, although ChibiOS doesn't exactly make it easy. Even if it was just the generic family definition instead (
STM32F1xx
) I'd be happy enough.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested this i2c code on STM32F1xx.
I agree with @pelrun. There are also multiple i2c buses available to use on STM chips, so this still is not enough.
Until we figure out a good way to handle i2c bus selection and using family definition, I'd personally prefer to keep this in keyboard branches, etc. Just override i2c_master in your local keyboard folder. But I'm not the judge of that, I defer to QMK people to figure it out. The reason I say this though is because my RGB code is stuck in purgatory because it doesn't support every STM32 chip yet.
Also, as it stands, any non STM32F1xx chip would fall back to the F303 code, which is wrong on many chips. I like how we do it in eeprom, where we raise an error if no one has written the code for a specific family.
I also don't know how I feel about making tons of ifdefs, but I don't know a better alternative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The best solution would probably be to add an explicit symbol in the board definition and choose based on that. I was planning on bringing in to core the main board definitions that are floating around some of the keyboards, at which point it's fairly straightforward to keep them in line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @pelrun, however I didn't make it so that you have to declare this in board.h because I feel like that would break compatibility with a lot of existing code. I am thinking about either let the board.h define the config structure and initialization, thus they can both control the i2c version and which i2c bus to use. However, again, this would come at the cost of backwards compatibility. I initially just provided my own i2c_master file, but @drashna suggested to me that I should probably use the standard i2c_master. So I modified the i2c master. And honestly, I see the i2cmaster file the best to be more of a utility than configure the i2c bus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is an issue right now, then it should be fine to revert back to the separate files.
Though, I'm not fond of having multiple files, but it seems like this is the best option until we have a better way to handle this.