libopenstm32-devel Mailing List for libopenstm32 (Page 4)
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: Piotr Esden-T. <pi...@es...> - 2010-12-26 00:08:19
|
On Dec 26, 2010, at 12:48 AM, Uwe Hermann wrote: > On Sat, Dec 25, 2010 at 08:50:12PM +0100, Piotr Esden-Tempski wrote: >> I just "finished" (famous last words) implementing CAN support for libopenstm32. I pushed it into my repository on github: https://github.com/esden/libopenstm32 > > Thanks, pulled with some small cosmetic fixes. > > I don't have any special hardware to test CAN right now, I hope someone > else can have a look. Tested after your cosmetic fixes. Works for me. (TM) :) Thanks! -- 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: Uwe H. <uw...@he...> - 2010-12-25 23:48:35
|
On Sat, Dec 25, 2010 at 08:50:12PM +0100, Piotr Esden-Tempski wrote: > I just "finished" (famous last words) implementing CAN support for libopenstm32. I pushed it into my repository on github: https://github.com/esden/libopenstm32 Thanks, pulled with some small cosmetic fixes. I don't have any special hardware to test CAN right now, I hope someone else can have a look. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Piotr Esden-T. <pi...@es...> - 2010-12-25 20:07:59
|
Hi, I just "finished" (famous last words) implementing CAN support for libopenstm32. I pushed it into my repository on github: https://github.com/esden/libopenstm32 Reviews, testing and comments are welcome! :) I tested the code on the all new clogic open-bldc logic boards. The CAN test program for that is in the dedicated obldc subdirectory. Port's to evaluation boards are welcome. I sadly don't have my MB525 board handy otherwise I would have done that myself. Maybe using built in loopback test mode of the CAN peripheral is a way to test the code, if you are not set up to use a real CAN bus? 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: Uwe H. <uw...@he...> - 2010-12-17 05:09:57
|
Hi, On Thu, Dec 02, 2010 at 10:08:06AM +1300, Gareth McMullin wrote: > Here are the basic register definitions for the STM32F107 Ethernet. > They're not quite useful yet, but a starting point if someone wants to > work on this. Thanks a lot, merged. I fixed a typo and some build issues, please check if my fixes are correct. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2010-12-17 05:09:57
|
On Thu, Dec 02, 2010 at 02:13:47PM +1300, Gareth McMullin wrote: > I've attached a diff of minor ld script changes: > I've added wildcards to the input section names. > This fixes the script for use with the "-ffunction-sections > -fdata-sections -Wl,--gc-sections" options when compiling/linking. Merged, thanks! Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2010-12-17 05:07:54
|
On Tue, Dec 07, 2010 at 10:13:18PM +1300, Philip Court wrote:
> I have attached a diff with changes to gpio.h and gpio.c. The changes
> define the remap IO for TIM1 and also provides an implementation for
> gpio_port_configuration_lock.
Thanks, merged in slightly different form. The #defines look OK, but I
changed gpio_port_config_lock() a bit (and renamed it).
> +void gpio_port_configuration_lock(u32 gpioport, u16 gpios)
> +{
> + u32 set = GPIO_LCKK | gpios; //used to set LCKK
> + u32 reset = ~GPIO_LCKK & gpios; //used to reset LCKK
> +
> + GPIOE_LCKR = set;
> + GPIOE_LCKR = reset;
> + GPIOE_LCKR = set;
Changed the hardcoded use of GPIOE here to GPIO_LCKR(gpioport) so it's
usable for all GPIO ports. Let me know if the code still works OK.
Thanks, Uwe.
--
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
|
|
From: Gareth M. <ga...@bl...> - 2010-12-16 08:19:21
|
Hi I'm considering taking on a small project to develop a free USB CAN adapter. I am wondering if anyone would have any interest in this. My current thoughts are to use an STM32F105 as this has USB OTG (I would only use the peripheral) and CAN. A quick draft schematic is available at http://www.blacksphere.co.nz/tmp/usbcan_1.pdf The significant portion of the software development would be support for the OTG and CAN controllers which I would contribute to libopenstm32. I will also develop a Linux SocketCAN driver when the device is working. If anyone is at all interested, please drop me a comment on my schematic. 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: Philip C. <ph...@gr...> - 2010-12-07 09:13:30
|
Hi guys Apologies for the HTML email in the previous post... I have attached a diff with changes to gpio.h and gpio.c. The changes define the remap IO for TIM1 and also provides an implementation for gpio_port_configuration_lock. Cheers Philip -- Philip Court Director Greenstage - Market driven change for the planet http://www.greenstage.co.nz PO Box 87 212 Meadowbank 1742 Auckland, New Zealand Ph +64 21 953 032 Fax +64 9 521 3533 -- Philip Court Director Greenstage - Market driven change for the planet http://www.greenstage.co.nz PO Box 87 212 Meadowbank 1742 Auckland, New Zealand Ph +64 21 953 032 Fax +64 9 521 3533 |
|
From: Philip C. <ph...@gr...> - 2010-12-07 00:28:55
|
Hi guys I have attached a diff with changes to gpio.h and gpio.c. The changes define the remap IO for TIM1 and also provides an implementation for gpio_port_configuration_lock. Cheers Philip -- Philip Court Director Greenstage - Market driven change for the planet http://www.greenstage.co.nz PO Box 87 212 Meadowbank 1742 Auckland, New Zealand Ph +64 21 953 032 Fax +64 9 521 3533 |
|
From: Gareth M. <ga...@bl...> - 2010-12-02 01:14:16
|
Hi I've attached a diff of minor ld script changes: I've added wildcards to the input section names. This fixes the script for use with the "-ffunction-sections -fdata-sections -Wl,--gc-sections" options when compiling/linking. I've also discarded the .eh_frame section. This section is emitted by GCC 4.4, but not 4.5. Discarding it doesn't appear to break anything. I suspect this is used for C++ exception implementation. I found this to be a problem when building with GCC 4.4 (arm-elf), because the USB DFU demo exceeded the 8k I allowed for it. Does anyone know exactly what this section is or how it should be handled? 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...> - 2010-12-01 21:08:35
|
Hi All Here are the basic register definitions for the STM32F107 Ethernet. They're not quite useful yet, but a starting point if someone wants to work on this. It seems that there is a minor complication with the STM32 connectivity line devices because their interrupt vector table is different. It would be nice to have both tables compiled in libopenstm32, and the one to be included selected at link-time. Does anyone have an idea on how this can be implemented cleanly? 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...> - 2010-11-13 04:27:51
|
On Sat, Nov 13, 2010 at 4:26 PM, dan...@gm... <dan...@gm...> wrote: > hi, > > I just compiled the libopenstm32 usbhid examples and flashed into a > STM32F103C8T6 chip, and when I connect > the USB cable in linux or MacOSX I can see a HID device > with ID : 0483:5710 , and on MacOSX it says that the device is a > composite hid device. but, when the OS is > windows, I only see windows reported that was a unknow device, so , > what's the problem here ? I didn't modify the code which was just the > original git version. I included an optional DFU interface in the HID example. Try removing this line from usbhid.c: #define INCLUDE_DFU_INTERFACE I tested both interfaces under Linux, but only tested it on Windows without the DFU interface. Does anyone know how to get the composite device to work on Windows? How do ST do the application mode DFU in their examples? 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: <dan...@gm...> - 2010-11-13 03:26:25
|
hi, I just compiled the libopenstm32 usbhid examples and flashed into a STM32F103C8T6 chip, and when I connect the USB cable in linux or MacOSX I can see a HID device with ID : 0483:5710 , and on MacOSX it says that the device is a composite hid device. but, when the OS is windows, I only see windows reported that was a unknow device, so , what's the problem here ? I didn't modify the code which was just the original git version. Thanks! |
|
From: Uwe H. <uw...@he...> - 2010-11-02 01:06:06
|
On Tue, Oct 26, 2010 at 01:12:54PM +1300, Gareth McMullin wrote: > Hi > > Attached is an updated patch of the USB stack. Great, thanks, merged updated version with minor changes as discussed. Thanks a lot for this awesome work! I'll probably do a few minor coding-style / whitespace cleanups as time permits and I hope to be able to test this on my hardware soon. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Linus C. <li...@li...> - 2010-10-27 20:21:25
|
Found it!
Registers AFIO_EXTICRX are not well set.
file exti.c on line 130:
/* Ensure that only valid EXTI lines are used. */
if (exti < EXTI4) {
AFIO_EXTICR1 &= ~(0x000F << shift);
AFIO_EXTICR1 |= (~bits << shift);
} else if (exti < EXTI8) {
AFIO_EXTICR2 &= ~(0x000F << shift);
AFIO_EXTICR2 |= (~bits << shift);
} else if (exti < EXTI12) {
AFIO_EXTICR3 &= ~(0x000F << shift);
AFIO_EXTICR3 |= (~bits << shift);
} else if (exti < EXTI16) {
AFIO_EXTICR4 &= ~(0x000F << shift);
AFIO_EXTICR4 |= (~bits << shift);
}
Cheers,
Linus.
On Wed, Oct 27, 2010 at 3:03 PM, Linus Casassa <li...@li...> wrote:
> Hi Mark
>
> I can't make your code to work on PB0.
>
> I changed two lines:
> gpio_set_mode(GPIOB, GPIO_MODE_INPUT, GPIO_CNF_INPUT_FLOAT, GPIO0);
> and
> exti_select_source(EXTI0,GPIOB); //select PortB pin0 as interrupt source
>
> I connected PB0 to ground and when I press the button (PA0) the interrupt
> EXT0 executes...
>
> What am I missing?
>
> Thanks in advance.
>
> On Mon, Oct 11, 2010 at 12:18 AM, Mark Butler <mb...@ph...
> > wrote:
>
>> Hi,
>> Here is an example that works on the olimex stm32-p103
>>
>> If you are using c++, I have found that interrupt service routines must be
>> declared as extern c functions in order to get the correct function names
>> for the interrupt vector.
>>
>> I am currently using my own version of exti.c however I don't think it was
>> changed after I submitted to libopenstm32
>>
>> Feel free to ask if you have any questions.
>>
>> cheers,
>> Mark
>>
>>
>> On 09/10/10 05:52, Linus Casassa wrote:
>>
>>> Hi
>>>
>>> Thank you very much for your work on the lib libopenstm32. It has been
>>> very easy to program the stm32 chip. But I am having problems with the exti
>>> interrupt.
>>>
>>> Do you have an example of a button interrupting?
>>>
>>> Thanks in advance.
>>>
>>> --
>>> Linus Casassa
>>> Estudiante Ingeniería Civil Electrónica
>>> Universidad Técnica Federico Santa María
>>> Fono: 56-9-97776941
>>>
>>
>>
>
>
> --
> Linus Casassa
> Estudiante Ingeniería Civil Electrónica
> Universidad Técnica Federico Santa María
> Fono: 56-9-97776941
>
--
Linus Casassa
Estudiante Ingeniería Civil Electrónica
Universidad Técnica Federico Santa María
Fono: 56-9-97776941
|
|
From: Gareth M. <ga...@bl...> - 2010-10-26 00:13:28
|
Hi Attached is an updated patch of the USB stack. Changes include: Examples have been added for DFU and HID device classes. The USB control code now provides a mechanism to notify the application when a transfer is complete. This was required for the implementation of the DFU class. Applications can now be notified of SUSPEND and RESUME events. The code style has been cleaned up: long lines broken, debugging junk removed, etc. The application may provide a larger buffer for control transfers: the libraries buffer is a weak symbol. To implement the DFU functions, I've added scb_reset_system() and scb_reset_core() functions. If there are no comments or suggestions can we please commit this to the repository. 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...> - 2010-10-19 00:10:13
|
On Mon, Oct 18, 2010 at 12:40:30PM +1300, Gareth McMullin wrote: > > I've just had a look through and no changes are required to the examples. > The results should be the same as before the patch. Great, thanks. Patch merged. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Gareth M. <ga...@bl...> - 2010-10-18 00:15:58
|
Hi I've finally done some work on the USB device stack. The patch is attached, including an example of a CDC ACM device. The stack is functional but not complete. Some discussion is probably in order before committing. I've included the USB related files in a directory lib/usb and included this in the VPATH in the Makefile. I've used the cdc.h header from the Linux kernel and usb.h from libusb-0.1 for some structure definitions. The new files are: usb.h - public header file for application implementing a usb device. Symbols are prefixed with 'usbd_' usb_private.h - internal header for definitions used in the library, but not exported to the application. Symbols are prefixed with '_usbd_' usb.c - usb library initialisation function usb_f103.c - platform specific implementation for STM32F10[23] device hardware. usb_control.c - implementation of the default usb control endpoint. usb_standard.c - implementation of the standard usb requests. The stack should be portable, with only the file usb_f103.c needing to be changed for different platforms. I have the same code working on an AT91. I've kept using the C99 stdint.h types in the portable files. Minor modification have been made to other files to support the stack and example. I added functions to rcc.c to configure the usb prescaler and configure clocks for 48MHz from HSI. My example has the 1.5k D+ pull-up resistor connected to PA15 (JTDI). Change this to match your hardware, especially if you need the JTAG port for debugging. Any comments or discussion would be appreciated. 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...> - 2010-10-17 23:41:02
|
Hi On Mon, Oct 18, 2010 at 11:25 AM, Uwe Hermann <uw...@he...> wrote: > Hi, > > On Fri, Oct 15, 2010 at 07:28:00PM +1300, Gareth McMullin wrote: > > I've just started working on libopenstm32, and noticed that the C runtime > > isn't initialized correctly (there is garbage in the data and bss > sections). > > The attached patch includes a reset_handler which initializes these > section > > before calling the application's main() function. > > The initial stack pointer is also defined in the linker script, allowing > the > > application to override with a linker command line option > > "-Wl,--defsym,_stack=0x20005000". > > > The patch looks good, just a small question: does this require changes > to any of the example linker scripts or Makefiles or READMEs in examples/*? > If yes, could you also provide a patch to update those? > > I've just had a look through and no changes are required to the examples. The results should be the same as before the patch. 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...> - 2010-10-17 22:46:02
|
Hi, On Fri, Oct 15, 2010 at 07:28:00PM +1300, Gareth McMullin wrote: > I've just started working on libopenstm32, and noticed that the C runtime > isn't initialized correctly (there is garbage in the data and bss sections). > The attached patch includes a reset_handler which initializes these section > before calling the application's main() function. > The initial stack pointer is also defined in the linker script, allowing the > application to override with a linker command line option > "-Wl,--defsym,_stack=0x20005000". > > Is posting patches to this list the preferred way of contributing? Yes. The patch looks good, just a small question: does this require changes to any of the example linker scripts or Makefiles or READMEs in examples/*? If yes, could you also provide a patch to update those? Thanks, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2010-10-17 22:41:02
|
On Wed, Oct 13, 2010 at 05:21:14PM +1300, Mark Butler wrote: > Hi, I have added the flash functions that I have been using. Thanks a lot, merged after fixing a few whitespace and coding style issues. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Uwe H. <uw...@he...> - 2010-10-17 22:39:09
|
Hi Edward, On Mon, Jun 07, 2010 at 08:58:51PM +1200, Edward Cheeseman wrote: > Just started the timer.c file. > > No where near complete but I think it conforms to the libopenstm32 style, so should be a start. I will add further when I can. Thanks, merged. Sorry for the looong delay. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
|
From: Gareth M. <ga...@bl...> - 2010-10-16 09:28:46
|
> According to the comment and the symbol STK_CTRL_CLKSOURCE_AHB_DIV8, > systick'c clock source is core clock divided by 8. > > Diving into the Core M3 datasheet, I've found that bit 2 of SysTick > control and status register selects the clock source, not a divider: > > stk clk src = (STK_CTRL bit 2 == 1) ? core clock : ext ref clk > > The reference manual from ST Microelectronics for STM32F10[12357] (RM0008) says in section 6.2 and 7.2: "The RCC feeds the Cortex System Timer (SysTick) external clock with the AHB clock (HCLK) divided by 8. The SysTick can work either with this clock or with the Cortex clock (HCLK), configurable in the SysTick Control and Status Register." These names are STM32 specific, not Cortex-M3 generic. 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...> - 2010-10-15 06:28:30
|
Hi I've just started working on libopenstm32, and noticed that the C runtime isn't initialized correctly (there is garbage in the data and bss sections). The attached patch includes a reset_handler which initializes these section before calling the application's main() function. The initial stack pointer is also defined in the linker script, allowing the application to override with a linker command line option "-Wl,--defsym,_stack=0x20005000". Is posting patches to this list the preferred way of contributing? 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: Mark B. <mb...@ph...> - 2010-10-13 04:41:53
|
Hi, I have added the flash functions that I have been using. Cheers, Mark |
