libopenstm32-devel Mailing List for libopenstm32 (Page 3)
Status: Inactive
Brought to you by:
uh1763
Menu
▾
▴
libopenstm32-devel — Development mailing list
You can subscribe to this list here.
| 2010 |
Jan
(10) |
Feb
(8) |
Mar
(27) |
Apr
(2) |
May
(16) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(11) |
Nov
(3) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(18) |
Feb
(17) |
Mar
(5) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(20) |
Aug
(1) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
|
|
From: Uwe H. <uw...@he...> - 2011-02-09 01:21:47
|
On Fri, Feb 04, 2011 at 10:55:57PM +1300, Gareth McMullin wrote: > I've added the register definitions for System Control and GPIO > and the miniblink example for the LM3S3748-EVB from > Texas Instruments/LuminaryMicro. Great, thanks a lot! > Available from my github repo: > git://github.com/gsmcmullin/libusbdev.git Pulled. It seems you forgot to add the headers (e.g. gpio.h) though? > Also note that the lpc13xx example is broken. Because > there is no interrupt vector table, the output binary is empty (0 bytes). Yeah, possible, I didn't actually finish or test that stuff. Will look into it. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2011-02-09 01:20:18
|
On Tue, Feb 08, 2011 at 07:51:04PM +1300, Gareth McMullin wrote: > > What convenience functions do you have in mind for the DebugMCU? > > The bits in the DBGMCU_CR may be useful to set while debugging, > > but I would think that you would be more likely do to this from the > > external debugger than from the application. > > > > In the back of my mind has been a plan for a GDB stub, I don't > > know how interested anyone would be in this. > > I've added register definitions for DBGMCU, Core Debug in the > System Control Space (SCS) and Flash Patch and Breakpoint (FPB) > to my github repo: > git://github.com/gsmcmullin/libusbdev.git Thanks, pulled with some small fixes (others pending, will do tomorrow). Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Gareth M. <ga...@bl...> - 2011-02-08 06:51:35
|
> What convenience functions do you have in mind for the DebugMCU? > The bits in the DBGMCU_CR may be useful to set while debugging, > but I would think that you would be more likely do to this from the > external debugger than from the application. > > In the back of my mind has been a plan for a GDB stub, I don't > know how interested anyone would be in this. I've added register definitions for DBGMCU, Core Debug in the System Control Space (SCS) and Flash Patch and Breakpoint (FPB) to my github repo: git://github.com/gsmcmullin/libusbdev.git - 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: Gareth M. <ga...@bl...> - 2011-02-04 09:56:25
|
I've added the register definitions for System Control and GPIO and the miniblink example for the LM3S3748-EVB from Texas Instruments/LuminaryMicro. Available from my github repo: git://github.com/gsmcmullin/libusbdev.git Also note that the lpc13xx example is broken. Because there is no interrupt vector table, the output binary is empty (0 bytes). 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: Gareth M. <ga...@bl...> - 2011-02-01 21:34:33
|
> We currently have quite good support of the stm32 I think we should try to wrap that one up and make it the first officially supported chip of libopencm3 for V0.1 release. I think this is a great idea! > Based on the status page we are still missing support for three subsystems of the stm32: > - DAC > - DebugMCU > - SDIO I've done a partial register map for the DAC. I'll find it and it can be included. DebugMCU is only 2 registers. I'll do this one too. The generic Cortex-M3 Core debug / FPB / DWT would also be useful. > I think we should also have convenience functions for at least part of subsystems. The ones still missing or partly missing are: > - Flash (50% I think we should work on finishing that up. I think Uwe wanted to work on this?) > - ADC (I will work on that one soon) > - Timer (it is by now 50% as the functions support Output Compare but not Input Capture yet) > - CRC > - DAC (as the subsystem is not supported yet) > - BKP > - DebugMCU (I think this one is quite important so that we can properly debug the stm32?) > - DMA > - FSMC > - IWDG > - PWR > - SDIO (as the subsystem is not supported yet) > - WWDG > - Ethernet > > I would say that we should have convenience functions for at least the following subsystems: > - Flash > - ADC > - Timer (finish that one up so that Input Compare is easy to use) > - DebugMCU > - DMA What is missing for the Flash. I've been using the current routines with no problem. What convenience functions do you have in mind for the DebugMCU? The bits in the DBGMCU_CR may be useful to set while debugging, but I would think that you would be more likely do to this from the external debugger than from the application. In the back of my mind has been a plan for a GDB stub, I don't know how interested anyone would be in this. > Other tasks: > - We should have examples for all subsystems that have convenience functions. For the STM32-H103 eval board as this one is very common out there. Maybe also the discovery board should get all the examples that exist for STM32-H103 ported? > - Generalize USB implementation? (I am not an expert on that I think Gareth and Uwe should comment on that one?) > - Generalize core clock setup routine? (rcc_clock_setup_in_hse_8mhz_out_24mhz discussion?) > - Anything I missed? :) I think USB is as general as it's likely to get. There is a problem with the USB HID example on the STM32-H103 board, Uwe and I were trying to solve this on Monday. I would like the USB to be working reliably for a stable release. > What do you think? Is anyone willing to take a stab at any of these parts? What did I miss? Do you have a different take on that? I just think that coordinating a little and giving us a target of a release may focus our efforts a little and make it easier going forward? I already see that we are getting more and more momentum as more people are contributing to libopencm3 what is really great! Thanks to everyone! :) I think some level of documentation would be really great for newcomers. Doxygen, perhaps? I've neglected to keep the usb api documented, as I'm still expecting it to change as things develop. This is another important concern. If we provide a stable release users will expect the api to remain consistent with future versions. I don't think that we are ready to freeze the api. 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: Piotr Esden-T. <pi...@es...> - 2011-02-01 19:33:46
|
Hi everyone, I would like to start a discussion about making an official stable release of libopencm3. To do that we should realize what still needs to be done, to achieve that and what we want to support in that release. There are several levels on which we can define support: - chip support (stm32, lpc13xx, linaro aso.) - subsystem support of a chip (for example DAC, ADC, Tim on STM32) - convenience functions for subsystems - example/test code for subsystems - examples for different eval boards and existing STM32 designs We currently have quite good support of the stm32 I think we should try to wrap that one up and make it the first officially supported chip of libopencm3 for V0.1 release. Based on the status page we are still missing support for three subsystems of the stm32: - DAC - DebugMCU - SDIO DebugMCU is in my opinion the only one that should be present for the V0.1 release. But if someone wants to write support for the other two is welcome to do so. :) I think we should also have convenience functions for at least part of subsystems. The ones still missing or partly missing are: - Flash (50% I think we should work on finishing that up. I think Uwe wanted to work on this?) - ADC (I will work on that one soon) - Timer (it is by now 50% as the functions support Output Compare but not Input Capture yet) - CRC - DAC (as the subsystem is not supported yet) - BKP - DebugMCU (I think this one is quite important so that we can properly debug the stm32?) - DMA - FSMC - IWDG - PWR - SDIO (as the subsystem is not supported yet) - WWDG - Ethernet I would say that we should have convenience functions for at least the following subsystems: - Flash - ADC - Timer (finish that one up so that Input Compare is easy to use) - DebugMCU - DMA Other tasks: - We should have examples for all subsystems that have convenience functions. For the STM32-H103 eval board as this one is very common out there. Maybe also the discovery board should get all the examples that exist for STM32-H103 ported? - Generalize USB implementation? (I am not an expert on that I think Gareth and Uwe should comment on that one?) - Generalize core clock setup routine? (rcc_clock_setup_in_hse_8mhz_out_24mhz discussion?) - Anything I missed? :) What do you think? Is anyone willing to take a stab at any of these parts? What did I miss? Do you have a different take on that? I just think that coordinating a little and giving us a target of a release may focus our efforts a little and make it easier going forward? I already see that we are getting more and more momentum as more people are contributing to libopencm3 what is really great! Thanks to everyone! :) Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain |
|
From: Marko K. <kra...@gm...> - 2011-02-01 13:35:14
|
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: Краљевић М. <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: 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: 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 21:50:19
|
Hi Uwe On Mon, Jan 31, 2011 at 10:09 AM, Uwe Hermann <uw...@he...> wrote: > How much does the stack depend on a STM32 controller? Would it be sufficient > to supply another driver struct to it to support other Cortex-M3's easily? > It would be awesome if we could reuse (most of) the code for other > microcontrollers. Most of it is not specific to STM32 at all. I had it working on an AT91SAM9 device before. I know there is an AT91SAM3 based on Cortex-M3, but I don't know what the USB hardware looks like. I don't have any other Cortex-M3 micro's around to work on though. I had a Stellaris board; if I can find it I'll look into support for this. I don't know if there are any big-endian implementation around, the usb stack assumes the device is little-endian. 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: Uwe H. <uw...@he...> - 2011-01-30 21:47:22
|
On Thu, Jan 27, 2011 at 04:56:44PM +0100, Damjan Marion wrote: > --- > include/libopencm3/stm32/memorymap.h | 14 +++++++++++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/include/libopencm3/stm32/memorymap.h b/include/libopencm3/stm32/memorymap.h Added, thanks. > /* AHB */ > #define SDIO_BASE (PERIPH_BASE_AHB + 0x00000) > @@ -95,6 +102,7 @@ > /* PERIPH_BASE_AHB + 0xb400 (0x4002 3400 - 0x4002 7FFF): Reserved */ > #define ETHERNET_BASE (PERIPH_BASE_AHB + 0x10000) > /* PERIPH_BASE_AHB + 0x18000 (0x4003 0000 - 0x4FFF FFFF): Reserved */ > -#define USB_OTG_FS_BASE (PERIPH_BASE_AHB + 0x10000000) > +#define USB_OTG_FS_BASE (PERIPH_BASE + 0x10000000) Thanks, this was a bug indeed. I changed it to be based on PERIPH_BASE_AHB though for consistency... > +#define FSMC_BASE (PERIPH_BASE + 0x60000000) ...and this one is not based off of AHB it seems, so I made it an extra "section" in memorymap.h. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2011-01-30 21:45:10
|
On Thu, Jan 27, 2011 at 11:08:31AM +0100, Damjan Marion wrote: > This is my 1st contribution to this project. Welcome :) > It is slightly modeified > fancyblink sample to support Olimex STM32-H107 board. > > Please add to git repo. Done, thanks. I fixed a small issue in one comment and some whitespace. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2011-01-30 21:11:02
|
On Sat, Jan 29, 2011 at 10:41:22AM +1300, Gareth McMullin wrote: > I've attached the register definitions for the connectivity line OTG_FS device. > I wrote this a while ago, and it's untested, but it's a start if anyone wants to > work on usb with these devices. I'll be working on it in a week or two when > I have hardware. Thanks, pulled as part of "USB driver abstraction". Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2011-01-30 21:10:21
|
On Fri, Jan 21, 2011 at 07:49:58PM +1300, Gareth McMullin wrote: > Unrelated: Th patch also clears the CTR flag in usbd_poll() if an > endpoint doesn't have an associated callback function. > This fixes a problem when calling usbd_poll() from an ISR. Thanks, pulled now. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2011-01-30 21:09:36
|
Hi, On Sun, Jan 30, 2011 at 05:18:39PM +1300, Gareth McMullin wrote: > I'm planning on adding support for the OTG_FS hardware to the usb > stack soon, but this requires some restructuring to keep the interface > clean. > > I've put all the functions in usb_f103.c into a driver structure, and > a pointer to this structure is passed to usbd_init(). The idea is to > add another driver structure for each hardware implementation. > An application developer then only needs to change the driver pointer > when porting across hardware implementations. Yeah, I like this approach. > Please have a look at my repo on github and let me know what you > think of this approach: > git://github.com/gsmcmullin/libusbdev.git > > Any comments would be appreciated. If everybody likes this it can be > pulled into the main repo. I pulled it, looks good. Thanks a lot! This also pulled your OTG patch and the fixes from "Minor USB issue". How much does the stack depend on a STM32 controller? Would it be sufficient to supply another driver struct to it to support other Cortex-M3's easily? It would be awesome if we could reuse (most of) the code for other microcontrollers. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Gareth M. <ga...@bl...> - 2011-01-30 04:19:10
|
Hi All I'm planning on adding support for the OTG_FS hardware to the usb stack soon, but this requires some restructuring to keep the interface clean. I've put all the functions in usb_f103.c into a driver structure, and a pointer to this structure is passed to usbd_init(). The idea is to add another driver structure for each hardware implementation. An application developer then only needs to change the driver pointer when porting across hardware implementations. Please have a look at my repo on github and let me know what you think of this approach: git://github.com/gsmcmullin/libusbdev.git Any comments would be appreciated. If everybody likes this it can be pulled into the main repo. 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: Gareth M. <ga...@bl...> - 2011-01-28 21:41:52
|
Hi All I've attached the register definitions for the connectivity line OTG_FS device. I wrote this a while ago, and it's untested, but it's a start if anyone wants to work on usb with these devices. I'll be working on it in a week or two when I have hardware. 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: Damjan M. <dam...@gm...> - 2011-01-28 16:56:02
|
Hi, Connectivity line devices have different GPIO mappings. Currently some definitions in the code are only for F103 series, for example: #define GPIO_USART1_TX GPIO9 /* PA9 */ #define GPIO_USART1_RX GPIO10 /* PA10 */ On STM32F107 GPIO_USART1_TX is PB6 and GPIO_USART1_RX is PB7. I can prepare patch to support connectivity line, but before I start I would like to know how we should address support for different devices as seems that current code is written only with F103 on the mind. Please comment... Damjan |
|
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: Damjan M. <dam...@gm...> - 2011-01-27 15:57:07
|
--- include/libopencm3/stm32/memorymap.h | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/include/libopencm3/stm32/memorymap.h b/include/libopencm3/stm32/memorymap.h index 52fe6d4..ad7fe5a 100644 --- a/include/libopencm3/stm32/memorymap.h +++ b/include/libopencm3/stm32/memorymap.h @@ -39,7 +39,10 @@ #define TIM5_BASE (PERIPH_BASE_APB1 + 0x0c00) #define TIM6_BASE (PERIPH_BASE_APB1 + 0x1000) #define TIM7_BASE (PERIPH_BASE_APB1 + 0x1400) -/* PERIPH_BASE_APB1 + 0x1800 (0x4000 1800 - 0x4000 27FF): Reserved */ +#define TIM12_BASE (PERIPH_BASE_APB1 + 0x1800) +#define TIM13_BASE (PERIPH_BASE_APB1 + 0x1c00) +#define TIM14_BASE (PERIPH_BASE_APB1 + 0x2000) +/* PERIPH_BASE_APB1 + 0x2400 (0x4000 2400 - 0x4000 27FF): Reserved */ #define RTC_BASE (PERIPH_BASE_APB1 + 0x2800) #define WWDG_BASE (PERIPH_BASE_APB1 + 0x2c00) #define IWDG_BASE (PERIPH_BASE_APB1 + 0x3000) @@ -80,7 +83,11 @@ #define TIM8_BASE (PERIPH_BASE_APB2 + 0x3400) #define USART1_BASE (PERIPH_BASE_APB2 + 0x3800) #define ADC3_BASE (PERIPH_BASE_APB2 + 0x3c00) -/* PERIPH_BASE_APB2 + 0x4000 (0x4001 4000 - 0x4001 7FFF): Reserved */ +/* PERIPH_BASE_APB2 + 0x4000 (0x4001 4000 - 0x4001 4FFF): Reserved */ +#define TIM9_BASE (PERIPH_BASE_APB2 + 0x4c00) +#define TIM10_BASE (PERIPH_BASE_APB2 + 0x5000) +#define TIM11_BASE (PERIPH_BASE_APB2 + 0x5400) +/* PERIPH_BASE_APB2 + 0x5800 (0x4001 5800 - 0x4001 7FFF): Reserved */ /* AHB */ #define SDIO_BASE (PERIPH_BASE_AHB + 0x00000) @@ -95,6 +102,7 @@ /* PERIPH_BASE_AHB + 0xb400 (0x4002 3400 - 0x4002 7FFF): Reserved */ #define ETHERNET_BASE (PERIPH_BASE_AHB + 0x10000) /* PERIPH_BASE_AHB + 0x18000 (0x4003 0000 - 0x4FFF FFFF): Reserved */ -#define USB_OTG_FS_BASE (PERIPH_BASE_AHB + 0x10000000) +#define USB_OTG_FS_BASE (PERIPH_BASE + 0x10000000) +#define FSMC_BASE (PERIPH_BASE + 0x60000000) #endif -- 1.7.2.3 |
|
From: Damjan M. <dam...@gm...> - 2011-01-27 10:08:52
|
Hi, This is my 1st contribution to this project. It is slightly modeified fancyblink sample to support Olimex STM32-H107 board. Please add to git repo. Regards, Damjan --- examples/stm32/Makefile | 10 +++- examples/stm32/stm32-h107/Makefile | 38 +++++++++++++ examples/stm32/stm32-h107/fancyblink/Makefile | 23 ++++++++ examples/stm32/stm32-h107/fancyblink/README | 10 +++ examples/stm32/stm32-h107/fancyblink/fancyblink.c | 59 ++++++++++++++++++++ examples/stm32/stm32-h107/fancyblink/fancyblink.ld | 31 ++++++++++ 6 files changed, 169 insertions(+), 2 deletions(-) create mode 100644 examples/stm32/stm32-h107/Makefile create mode 100644 examples/stm32/stm32-h107/fancyblink/Makefile create mode 100644 examples/stm32/stm32-h107/fancyblink/README create mode 100644 examples/stm32/stm32-h107/fancyblink/fancyblink.c create mode 100644 examples/stm32/stm32-h107/fancyblink/fancyblink.ld diff --git a/examples/stm32/Makefile b/examples/stm32/Makefile index a2c2eff..da49aa8 100644 --- a/examples/stm32/Makefile +++ b/examples/stm32/Makefile @@ -24,12 +24,16 @@ Q := @ MAKEFLAGS += --no-print-directory endif -all: stm32-h103 mb525 lisa-m obldc other +all: stm32-h103 stm32-h107 mb525 lisa-m obldc other stm32-h103: @printf " BUILD examples/stm32/stm32-h103\n" $(Q)$(MAKE) -C stm32-h103 +stm32-h107: + @printf " BUILD examples/stm32/stm32-h107\n" + $(Q)$(MAKE) -C stm32-h107 + mb525: @printf " BUILD examples/stm32/mb525\n" $(Q)$(MAKE) -C mb525 @@ -49,6 +53,8 @@ obldc: clean: @printf " CLEAN examples/stm32/stm32-h103\n" $(Q)$(MAKE) -C stm32-h103 clean + @printf " CLEAN examples/stm32/stm32-h107\n" + $(Q)$(MAKE) -C stm32-h107 clean @printf " CLEAN examples/stm32/mb525\n" $(Q)$(MAKE) -C mb525 clean @printf " CLEAN examples/stm32/lisa-m\n" @@ -58,5 +64,5 @@ clean: @printf " CLEAN examples/stm32/obldc\n" $(Q)$(MAKE) -C obldc clean -.PHONY: stm32-h103 mb525 lisa-m other obldc clean +.PHONY: stm32-h103 stm32-h107 mb525 lisa-m other obldc clean diff --git a/examples/stm32/stm32-h107/Makefile b/examples/stm32/stm32-h107/Makefile new file mode 100644 index 0000000..c9edec3 --- /dev/null +++ b/examples/stm32/stm32-h107/Makefile @@ -0,0 +1,38 @@ +## +## This file is part of the libopencm3 project. +## +## Copyright (C) 2009 Uwe Hermann <uw...@he...> +## +## This program is free software: you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation, either version 3 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program. If not, see <http://www.gnu.org/licenses/>. +## + +# Be silent per default, but 'make V=1' will show all compiler calls. +ifneq ($(V),1) +Q := @ +# Do not print "Entering directory ...". +MAKEFLAGS += --no-print-directory +endif + +all: fancyblink + +fancyblink: + @printf " BUILD examples/stm32/stm32-h107/fancyblink\n" + $(Q)$(MAKE) -C fancyblink + +clean: + @printf " CLEAN examples/stm32/stm32-h107/fancyblink\n" + $(Q)$(MAKE) -C fancyblink clean + +.PHONY: fancyblink + diff --git a/examples/stm32/stm32-h107/fancyblink/Makefile b/examples/stm32/stm32-h107/fancyblink/Makefile new file mode 100644 index 0000000..1baec4d --- /dev/null +++ b/examples/stm32/stm32-h107/fancyblink/Makefile @@ -0,0 +1,23 @@ +## +## This file is part of the libopencm3 project. +## +## Copyright (C) 2009 Uwe Hermann <uw...@he...> +## +## This program is free software: you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation, either version 3 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program. If not, see <http://www.gnu.org/licenses/>. +## + +BINARY = fancyblink + +include ../../Makefile.include + diff --git a/examples/stm32/stm32-h107/fancyblink/README b/examples/stm32/stm32-h107/fancyblink/README new file mode 100644 index 0000000..6f1ac39 --- /dev/null +++ b/examples/stm32/stm32-h107/fancyblink/README @@ -0,0 +1,10 @@ +------------------------------------------------------------------------------ +README +------------------------------------------------------------------------------ + +This is small LED blinking example program using libopencm3. + +It's intended for the ST STM32-based Olimex STM32-H107 eval board (see +http://olimex.com/dev/stm32-h107.html for details). It should blink +the LED on the board. + diff --git a/examples/stm32/stm32-h107/fancyblink/fancyblink.c b/examples/stm32/stm32-h107/fancyblink/fancyblink.c new file mode 100644 index 0000000..759b767 --- /dev/null +++ b/examples/stm32/stm32-h107/fancyblink/fancyblink.c @@ -0,0 +1,59 @@ +/* + * This file is part of the libopencm3 project. + * + * Copyright (C) 2009 Uwe Hermann <uw...@he...> + * Copyright (c) 2011 Damjan Marion <dam...@gm...> + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. + */ + +#include <libopencm3/stm32/rcc.h> +#include <libopencm3/stm32/gpio.h> + +/* Set STM32 to 72 MHz. */ +void clock_setup(void) +{ + rcc_clock_setup_in_hse_8mhz_out_72mhz(); + + /* Enable GPIOC clock. */ + rcc_peripheral_enable_clock(&RCC_APB2ENR, RCC_APB2ENR_IOPCEN); + +} + +void gpio_setup(void) +{ + /* Set GPIO12 (in GPIO port C) to 'output push-pull'. */ + gpio_set_mode(GPIOC, GPIO_MODE_OUTPUT_50_MHZ, + GPIO_CNF_OUTPUT_PUSHPULL, GPIO6); + gpio_set_mode(GPIOC, GPIO_MODE_OUTPUT_50_MHZ, + GPIO_CNF_OUTPUT_PUSHPULL, GPIO7); +} + +int main(void) +{ + int i; + + clock_setup(); + gpio_setup(); + + /* Blink the LEDs (PC6 and PC7) on the board. */ + while (1) { + gpio_toggle(GPIOC, GPIO6); /* STAT1 LED on/off */ + gpio_toggle(GPIOC, GPIO7); /* STAT2 LED on/off */ + for (i = 0; i < 8000000; i++) /* Wait a bit. */ + __asm__("nop"); + } + + return 0; +} diff --git a/examples/stm32/stm32-h107/fancyblink/fancyblink.ld b/examples/stm32/stm32-h107/fancyblink/fancyblink.ld new file mode 100644 index 0000000..6c9c766 --- /dev/null +++ b/examples/stm32/stm32-h107/fancyblink/fancyblink.ld @@ -0,0 +1,31 @@ +/* + * This file is part of the libopencm3 project. + * + * Copyright (C) 2009 Uwe Hermann <uw...@he...> + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. + */ + +/* Linker script for Olimex STM32-H107 (STM32F107VCT6, 256K flash, 64K RAM). */ + +/* Define memory regions. */ +MEMORY +{ + rom (rx) : ORIGIN = 0x08000000, LENGTH = 256K + ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64K +} + +/* Include the common ld script. */ +INCLUDE libopencm3_stm32.ld + -- 1.7.2.3 |
|
From: Gareth M. <ga...@bl...> - 2011-01-21 06:50:28
|
Hi all I pulled updates to libopenstm32 and noticed that some of my experimental changes to the usb code have made it into the library. The API was changed for a simpler and more direct handling of usb control requests from the application. There is a bug in this code (or maybe the examples, since it's not documented), but the CDC example registers the control callback in the set_config callback, so if the device receives multiple set_config requests the array of control callbacks will fill up. The DFU example doesn't implement a set_config callback, and the control callback is registered from main(). So if control callbacks should be cleared on set_config, then this example is broken. Attached is a proposed patch to fix these issues: control callbacks are cleared only if a user set_config handler is installed. We should possibly do the same thing with endpoints. It will simplify the implementation of devices with only one configuration, by not requiring a set_config callback. Let me know you how you feel the usb api should behave. This is only a suggestion, but there is are bugs either way that must be fixed. Unrelated: Th patch also clears the CTR flag in usbd_poll() if an endpoint doesn't have an associated callback function. This fixes a problem when calling usbd_poll() from an ISR. 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: Uwe H. <uw...@he...> - 2011-01-07 16:10:13
|
On Tue, Jan 04, 2011 at 02:39:29PM -0300, Linus Casassa wrote: > I think I found a problem with interrupts. AFIO_EXTICR[1 to 4] > registers are not beeing set correctly. You have to force a 0 on the > bits that are 0 for the mutex to work. > I have attached a patch. Thanks, merged. Untested by me, but the fix looks correct. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Linus C. <li...@li...> - 2011-01-04 17:39:59
|
Hi! I think I found a problem with interrupts. AFIO_EXTICR[1 to 4] registers are not beeing set correctly. You have to force a 0 on the bits that are 0 for the mutex to work. I have attached a patch. Hope this helps. -- Linus Casassa Estudiante Ingeniería Civil Electrónica Universidad Técnica Federico Santa María Fono: 56-9-97776941 |
