Thread: [libopenstm32-devel] gpio_toggle and examples question
Status: Inactive
Brought to you by:
uh1763
From: Marko K. <kra...@gm...> - 2011-01-28 09:10:43
|
Hi, I just got a little STM32 discovery board, came across a post from Uwe somewhere mentioning libopenstm32 and the script to build the toolchain. I got it up and running and have been playing around a little bit. I modified examples/button.c to work with the discovery board (should I be submitting examples modified for this target, anyway? Could be handy, as the board is 10 bucks.. nice way to get into ARM, I thought). Anyway, I started to play with a few of the library routines, and gpio_toggle doesn't exactly work with multiple GPIOs. If you have some high, and some low... it toggles them all as they were the same as the first (presumably) bit read. eg. If you pass GPIO0...3 to gpio_toggle(), and they are 0xA, instead of toggling 0xA, 0x5, 0xA ad nauseam, it will go 0xF, 0x0, 0xF. I came up with a direct way of implementing it properly, and one using existing functions, I'm not sure which is better? current function: void gpio_toggle(u32 gpioport, u16 gpio) { if ((gpio_port_read(gpioport) & gpio) == gpio) gpio_clear(gpioport, gpio); else gpio_set(gpioport, gpio); } calling existing port read/write functions: void gpio_toggle(u32 gpioport, u16 gpios) { gpio_port_write(gpioport, gpio_port_read(gpioport) ^ gpios); } or direct register: void gpio_toggle(u32 gpioport, u16 gpios) { GPIO_ODR(gpioport) = GPIO_IDR(gpioport) ^ gpios; } I suppose it's the same deal either way, just not sure what is preferred. I've made a little wig-wag blinker to demo it, if there is any want for it. What else... Regarding the clock setup bits, eg. rcc_clock_setup_in_hse_8mhz_out_72mhz() - Is there any thought of moving this to a more universal function? say like: rcc_clock_setup_hse(in_mhz, out_mhz) - or so? Do you think this is worthwhile? (the MCU on this board only goes to 24MHz, so I've just added a in_hse_8MHz_out_24MHz function temporarily). Is there a delay function in the works? What areas of the lib need help? Sorry for rambling. There was more I was thinking about but it seems to have slipped my mind. -Mark |
From: Uwe H. <uw...@he...> - 2011-01-30 22:13:23
|
Hi, On Fri, Jan 28, 2011 at 03:10:35AM -0600, Marko Kraljevic wrote: > Hi, I just got a little STM32 discovery board, came across a post from > Uwe somewhere mentioning libopenstm32 and the script to build the > toolchain. I got it up and running and have been playing around a little > bit. Nice! I also have one of those around now. How do you program them though? AFAIK it needs SWD and last time I check OpenOCD support for SWD was not ready yet. Do you use some tool which relies on the internal bootloader? > I modified examples/button.c to work with the discovery board (should I > be submitting examples modified for this target, anyway? Could be handy, > as the board is 10 bucks.. nice way to get into ARM, I thought). Sure, having a few examples for the STM32 discovery board would be nice. > Anyway, I started to play with a few of the library routines, and > gpio_toggle doesn't exactly work with multiple GPIOs. If you have some Yep, known limitation. > void gpio_toggle(u32 gpioport, u16 gpios) > { > GPIO_ODR(gpioport) = GPIO_IDR(gpioport) ^ gpios; > } This one is probably the best option. > I suppose it's the same deal either way, just not sure what is > preferred. I've made a little wig-wag blinker to demo it, if there is > any want for it. Sure. > What else... > Regarding the clock setup bits, eg. > rcc_clock_setup_in_hse_8mhz_out_72mhz() - Is there any thought of moving > this to a more universal function? say like: > rcc_clock_setup_hse(in_mhz, out_mhz) - or so? Do you think this is > worthwhile? Hm, good question. Not sure if it's worth the trouble, but it wouldn't hurt either, I guess. > (the MCU on this board only goes to 24MHz, so I've just > added a in_hse_8MHz_out_24MHz function temporarily). > Is there a delay function in the works? Nobody I know of is working on it, but it's definately something we need! (timer-based, exact delay instead of the current "loop" quick hack) > What areas of the lib need help? Various, an incomplete and outdated (and way too unspecific) status page is at: http://sourceforge.net/apps/mediawiki/libopenstm32/index.php?title=Status Having specific, working examples for each subsystem would be great, for example. One or two header files may be missing, too. Proof-reading the headers for typos is also a good thing to do, it's easy to miss some typos when you add new #define lists. Other than that, currently some work is going into timers, CAN (I think), USB, and I'll personally probably make an FSMC example sooner or later, as I want to design a hardware with some STM32 that can read/write NAND flash. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
From: Gareth M. <ga...@bl...> - 2011-01-30 22:25:57
|
> Nice! I also have one of those around now. How do you program them > though? AFAIK it needs SWD and last time I check OpenOCD support for SWD > was not ready yet. Do you use some tool which relies on the internal > bootloader? I have a design for a debugger/programmer for Cortex-M3 which supports JTAG and SWD. I just got it working with libopenstm32. I'll put the design out in a few days time. It is a hardware/firmware design based on STM32, USB enumerates as CDC-ACM device and implements the GDB protocol directly. It doesn't try to be everything OpenOCD is, but for me it works a lot better. I'll also write something up on how to hack the ST-LINK to use my firmware for people who prefer to use GDB. I hope everybody's interested... Regards, Gareth -- Black Sphere Technologies Ltd. Web: www.blacksphere.co.nz Mobile: +64 27 777 2182 Tel: +64 9 478 8885 Skype: gareth.mcmullin LinkedIn: http://nz.linkedin.com/in/gsmcmullin |
From: Краљевић М. <kra...@gm...> - 2011-01-30 22:43:16
|
On Sun, Jan 30, 2011 at 4:13 PM, Uwe Hermann <uw...@he...> wrote: > Nice! I also have one of those around now. How do you program them > though? AFAIK it needs SWD and last time I check OpenOCD support for SWD > was not ready yet. Do you use some tool which relies on the internal > bootloader? > I've been programming through the builtin serial bootloader, there is a little gpl'd C program for this here: http://code.google.com/p/stm32flash/ You need a RS-232 <> 3.3V TTL level shifter hooked to USART1, so either a MAX3232, or one of the FTDI deals. I usually just buy Nokia CA-42 cables and cut the end off, they are something like $3 for chinese knockoffs and use a PL2303 or ARK3116 (at least the ones I've come across). There's a driver in linux for both of those ICs for quite some time. Just plug it in and go. No debug, of course. > Sure, having a few examples for the STM32 discovery board would be nice. > I'll try and modify some of the examples to the discovery and submit them some time in the near future. >> void gpio_toggle(u32 gpioport, u16 gpios) >> { >> GPIO_ODR(gpioport) = GPIO_IDR(gpioport) ^ gpios; >> } > > This one is probably the best option. > > >> I suppose it's the same deal either way, just not sure what is >> preferred. I've made a little wig-wag blinker to demo it, if there is >> any want for it. > > Sure. > Sounds good, I'm not sure the method of submitting it - Just send a diff to the list? > >> What else... >> Regarding the clock setup bits, eg. >> rcc_clock_setup_in_hse_8mhz_out_72mhz() - Is there any thought of moving >> this to a more universal function? say like: >> rcc_clock_setup_hse(in_mhz, out_mhz) - or so? Do you think this is >> worthwhile? > > Hm, good question. Not sure if it's worth the trouble, but it wouldn't > hurt either, I guess. > I guess we would have to make it #warn if out isn't a multiple of in, but shouldn't be hard to implement otherwise i don't think... I might play with it and see how it goes. > Various, an incomplete and outdated (and way too unspecific) status page > is at: > > http://sourceforge.net/apps/mediawiki/libopenstm32/index.php?title=Status > Alright. Well I'll try and get some of the examples adapted to discovery for now, as time allows, and go from there. |
From: Marko K. <kra...@gm...> - 2011-02-01 13:35:14
Attachments:
1.diff
|
Hi, I've attached a patch consisting of: Modify gpio.c so that gpio_toggle() supports multiple gpios. Modify rcc.c to provide rcc_clock_setup_in_hse_8mhz_out_24mhz(), as 24MHz is the maximum speed of the chip on the stm32 discovery board. Added directory of examples, tested on stm32 discovery, just modifications of: button, miniblink, fancyblink, usart, and rtc. More to come when i get some spare time to try out some other library features... Let me know if anything needs fixing, or whatnot. mark |
From: Uwe H. <uw...@he...> - 2011-02-09 01:49:52
|
On Tue, Feb 01, 2011 at 07:35:03AM -0600, Marko Kraljevic wrote: > I've attached a patch consisting of: > Modify gpio.c so that gpio_toggle() supports multiple gpios. Merged, thanks. > Modify rcc.c to provide rcc_clock_setup_in_hse_8mhz_out_24mhz(), as > 24MHz is the maximum speed of the chip on the stm32 discovery board. Merged, too. > Added directory of examples, tested on stm32 discovery, just > modifications of: > button, miniblink, fancyblink, usart, and rtc. Merged, too, with some minor fixups. Haven't tested the examples on hardware yet, but will probably do so later. Just to make sure -- you have the ST STM32VLDISCOVERY from http://www.st.com/internet/evalboard/product/250863.jsp, correct? Thanks, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |