Skip to content
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

feature: support stm32f4 gpio output function and example app: gpioer #86

Closed
wants to merge 13 commits into from

Conversation

benwei
Copy link
Contributor

@benwei benwei commented Apr 19, 2014

Here is first version of gpio function support , just gpio with output-only api.
An Example of gpioer with user the stm32f407 built-in four leds.
The gpioer app will make the 4 leds blink with 1 second interval.

@georgekang
Copy link
Member

Because F9 is microkernel based, it would be better to put hardware driver in user space.
In my opinion, both user-log and user-gpioer violate the design principle of microkernel.
They will let F9 look like a monolithic kernel. user-log is a workaround just for easy dump but
not a good design.

@benwei
Copy link
Contributor Author

benwei commented Apr 20, 2014

Thank for your opinion. Sure, I agreed with you. Now, I'm trying to do the following modification.

firstly, I created all api related for gpio.c to gpioer.c (each function with __USER_TEXT).
let user/apps/gpioer/main.c call gpioer.c from user space.

secondly, the memory access fault because gpioer.c api access the following address

RCC_AHB1ENR,
GPIO_MODER(port);
GPIO_OTYPER(port)
GPIO_OSPEEDR(port)
GPIO_PUPDR(port)
GPIO_MODER(port)
GPIO_AFRL(port)
GPIO_AFRH(port)
GPIO_ODR(port)
Do you have any suggestion about memory permission ?
Should I grant all of the memory address to allow userspace gpioer app read/wrte? if doing by this way, how about the security control?

@benwei
Copy link
Contributor Author

benwei commented May 2, 2014

update gpioer sample code which access AHB1_1DEV from user space directly. because RCC_AHB1ENR(0x40023830) will be accessed, memory.c was modified with AHB1_1DEV's upbound range from 0x40022400 to 0x40023c00.

@benwei
Copy link
Contributor Author

benwei commented May 27, 2014

Thank for info. I referred the student code. That's great way to avoid hacking root_thread.c, I fixed code and remove duplicated code and put gpio.c to user mode. I extended the Kconfig for Applications to make default build original apps.

@jserv
Copy link
Member

jserv commented Jun 25, 2014

@benwei, please rebase to master.

In addition, @georgekang is going to revise the interrupt handling, and my student is working on the new driver model. We expect to make it fairly functioned next week.

@jserv
Copy link
Member

jserv commented Jun 26, 2014

WIP: user_interrupt branch

@jserv
Copy link
Member

jserv commented Jun 26, 2014

Cc. @slpbaby , who is working on STM32F429 Discovery platform support.
Cc. @rampant1018 , who is expected to revise further design of programming model and corresponding APIs.

@jserv
Copy link
Member

jserv commented Aug 18, 2014

Deprecated since we should always follow principle of least privilege (POLA).

@jserv jserv closed this Aug 18, 2014
@ab1aw
Copy link

ab1aw commented Feb 23, 2019

I am trying to build an F9 image that can flash the LEDs on the STM32F407 Discovery board. I find that the forked repository of benwei does not build. I merged the benwei gpio code into my fork of latest f9-kernel. It builds successfully but does not run. Is there any successful code demonstration of flashing the LEDs? Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants