Re: CMSIS?
Absent answer means no. I had the same idea. Actually I have played around with using vendor libraries from TI and ST, and there is no problem compiling them in. I can't see any reason CMSIS wouldn't fit in fine too. Actually from memory the useful parts of CMSIS comprise two parts, ARM specific intrinsic instructions and register locations in a header file, and reasonable math libraries. It shouldn't be a bit deal to use these, I would ignore the CMSIS linker scripts and such though. I would like to see CMSIS and parts of the vendor libraries integrated with RTEMS if possible, but I am uncertain about licensing compatibility. It seems daft to have to rewrite register locations and platform specific instructions if the vendors provide them.. Regards, Chris. On 29/08/2014 10:04 AM, Daniel Gutson wrote: absent answer means NO? Thanks, Daniel. On Thu, Aug 28, 2014 at 11:31 AM, Daniel Gutson wrote: Hi, is there any precedent regarding a CMSIS abstraction layer implementation on RTEMS? Thanks, Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
Hi, I was fiddling with this platform and got as far as a project implementing a USB device. If you are interested I could send you the code. It hasn't been touched for a while, it may or may not have bit rot. Sent with AquaMail for Android http://www.aqua-mail.com On 18 September 2014 12:12:21 Tomasz Gregorek wrote: Hello I am interested in development of the stm32f4 bsp. We have small project based on the STM32F429 MCPU which we would like to run RTEMS on. From the current code one could say there is not much. Only UART in polling, started I2C, some defines and few registers descriptions, interrupts just touched. Is anyone working on this so I would not double the work? What is current status of the work? Who can I contact for some initial information about bsps? Still a lot of reading to do... Best regards Tomasz -- ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
Interrupts working yes. No I don't mind. It's a bit of a mess though, I was in the process of doing another cleaner USB device implementation for BeagleBone Black, which I was then going to backport to STM32F4 and eventually maybe work towards some sort of general RTEMS USB device framework. Actually I got the BB black code enumerating as well, I just ran out of time to work on it. I'll send the STM32 project to you soon, I will be travelling for the next week so if I don't get a chance tonight it will probably be in a week or so. Regards, Chris. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 00:43:59 Tomasz Gregorek wrote: Hi Chris Yes, I am very interested. I guess you have interrupts working there? Do you mind your code or work based on it to end up under RTEMS licence on the git repository? Thanks 2014-09-19 6:00 GMT+02:00 Chris Nott : > Hi, I was fiddling with this platform and got as far as a project > implementing a USB device. If you are interested I could send you the code. > It hasn't been touched for a while, it may or may not have bit rot. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 18 September 2014 12:12:21 Tomasz Gregorek > wrote: > >> Hello >> >> I am interested in development of the stm32f4 bsp. >> We have small project based on the STM32F429 MCPU which we would like to >> run RTEMS on. >> >> From the current code one could say there is not much. Only UART in >> polling, started I2C, some defines and few registers descriptions, >> interrupts just touched. >> >> Is anyone working on this so I would not double the work? >> What is current status of the work? >> >> Who can I contact for some initial information about bsps? >> >> Still a lot of reading to do... >> >> Best regards >> Tomasz >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
I have used the BSD stack with RTEMS on a project with Chris J. It is fine for some uses but it is very heavyweight for implementing just a device on small embedded target. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 09:37:35 Gedare Bloom wrote: On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott wrote: > Interrupts working yes. > > No I don't mind. It's a bit of a mess though, I was in the process of doing > another cleaner USB device implementation for BeagleBone Black, which I was > then going to backport to STM32F4 and eventually maybe work towards some > sort of general RTEMS USB device framework. > There is some support for USB in the BSD stack which is probably the best place to put efforts toward improving. I don't personally know the state of USB there. > Actually I got the BB black code enumerating as well, I just ran out of time > to work on it. > > I'll send the STM32 project to you soon, I will be travelling for the next > week so if I don't get a chance tonight it will probably be in a week or so. > > Regards, > Chris. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 19 September 2014 00:43:59 Tomasz Gregorek > wrote: >> >> Hi Chris >> >> Yes, I am very interested. >> I guess you have interrupts working there? >> >> Do you mind your code or work based on it to end up under RTEMS licence on >> the git repository? >> Thanks >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >>> >>> Hi, I was fiddling with this platform and got as far as a project >>> implementing a USB device. If you are interested I could send you the code. >>> It hasn't been touched for a while, it may or may not have bit rot. >>> >>> Sent with AquaMail for Android >>> http://www.aqua-mail.com >>> >>> On 18 September 2014 12:12:21 Tomasz Gregorek >>> wrote: >>>> >>>> Hello >>>> >>>> I am interested in development of the stm32f4 bsp. >>>> We have small project based on the STM32F429 MCPU which we would like to >>>> run RTEMS on. >>>> >>>> From the current code one could say there is not much. Only UART in >>>> polling, started I2C, some defines and few registers descriptions, >>>> interrupts just touched. >>>> >>>> Is anyone working on this so I would not double the work? >>>> What is current status of the work? >>>> >>>> Who can I contact for some initial information about bsps? >>>> >>>> Still a lot of reading to do... >>>> >>>> Best regards >>>> Tomasz >>>> ___ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >> >> > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
On good, thanks. I was hoping to work up to putting a tcpip stack on one of our STM32F4 boards with ethernet. I thought the BSD stack was the only option but LWIP would be ideal. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 19:23:33 Joel Sherrill wrote: There is a port of LWIP discussed recently on the list which would be very appropriate on lower memory targets. On September 19, 2014 9:21:02 PM CDT, Chris Nott wrote: >I have used the BSD stack with RTEMS on a project with Chris J. It is >fine >for some uses but it is very heavyweight for implementing just a device >on >small embedded target. > >Sent with AquaMail for Android >http://www.aqua-mail.com > > >On 19 September 2014 09:37:35 Gedare Bloom wrote: > >> On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott >wrote: >> > Interrupts working yes. >> > >> > No I don't mind. It's a bit of a mess though, I was in the process >of doing >> > another cleaner USB device implementation for BeagleBone Black, >which I was >> > then going to backport to STM32F4 and eventually maybe work towards >some >> > sort of general RTEMS USB device framework. >> > >> There is some support for USB in the BSD stack which is probably the >> best place to put efforts toward improving. I don't personally know >> the state of USB there. >> >> > Actually I got the BB black code enumerating as well, I just ran >out of time >> > to work on it. >> > >> > I'll send the STM32 project to you soon, I will be travelling for >the next >> > week so if I don't get a chance tonight it will probably be in a >week or so. >> > >> > Regards, >> > Chris. >> > >> > Sent with AquaMail for Android >> > http://www.aqua-mail.com >> > >> > On 19 September 2014 00:43:59 Tomasz Gregorek > >> > wrote: >> >> >> >> Hi Chris >> >> >> >> Yes, I am very interested. >> >> I guess you have interrupts working there? >> >> >> >> Do you mind your code or work based on it to end up under RTEMS >licence on >> >> the git repository? >> >> Thanks >> >> >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >> >>> >> >>> Hi, I was fiddling with this platform and got as far as a project >> >>> implementing a USB device. If you are interested I could send you >the code. >> >>> It hasn't been touched for a while, it may or may not have bit >rot. >> >>> >> >>> Sent with AquaMail for Android >> >>> http://www.aqua-mail.com >> >>> >> >>> On 18 September 2014 12:12:21 Tomasz Gregorek > >> >>> wrote: >> >>>> >> >>>> Hello >> >>>> >> >>>> I am interested in development of the stm32f4 bsp. >> >>>> We have small project based on the STM32F429 MCPU which we would >like to >> >>>> run RTEMS on. >> >>>> >> >>>> From the current code one could say there is not much. Only UART >in >> >>>> polling, started I2C, some defines and few registers >descriptions, >> >>>> interrupts just touched. >> >>>> >> >>>> Is anyone working on this so I would not double the work? >> >>>> What is current status of the work? >> >>>> >> >>>> Who can I contact for some initial information about bsps? >> >>>> >> >>>> Still a lot of reading to do... >> >>>> >> >>>> Best regards >> >>>> Tomasz >> >>>> ___ >> >>>> devel mailing list >> >>>> devel@rtems.org >> >>>> http://lists.rtems.org/mailman/listinfo/devel >> >> >> >> >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > >___ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
STM32F4 register definitions and PLL settings patch
Hi,
I sent these header file changes previously, they didn't get picked up.
I re-merged with the head, cleaned up formatting and fixed a bug with
PLL_Q setting not generating the right auxiliary clock frequency for USB
peripheral - Tomasz this was your change, could you please review my fix.
Regards,
Chris.
>From 128c5293ea8e2cc94e7ee6ea4eae033175cedc78 Mon Sep 17 00:00:00 2001
From: Chris Nott
Date: Sat, 18 Oct 2014 01:55:37 -0700
Subject: [PATCH] Added register definition headers for STM32F4 ADC, EXTI, PWR,
SYSCFG, TIM, OTGFS and updated FLASH and RCC. Fixed PLL_Q for USB 48MHz
operation. Added flash prefetch enable.
---
c/src/lib/libbsp/arm/stm32f4/Makefile.am | 6 +
c/src/lib/libbsp/arm/stm32f4/include/stm32f4.h | 100 -
.../libbsp/arm/stm32f4/include/stm32f4_exti.h | 64 +++
.../libbsp/arm/stm32f4/include/stm32f4_flash.h | 111 +++--
.../libbsp/arm/stm32f4/include/stm32f4_otgfs.h | 445 +
.../libbsp/arm/stm32f4/include/stm32f4_pwr.h | 47 +++
.../libbsp/arm/stm32f4/include/stm32f4_rcc.h | 146 ++-
.../arm/stm32f4/include/stm32f4_syscfg.h | 108 +
.../libbsp/arm/stm32f4/include/stm32f4_tim.h | 206 ++
c/src/lib/libbsp/arm/stm32f4/preinstall.am | 24 ++
c/src/lib/libbsp/arm/stm32f4/startup/bspstart.c| 9 +-
11 files changed, 1209 insertions(+), 57 deletions(-)
create mode 100644 c/src/lib/libbsp/arm/stm32f4/include/stm32f4_exti.h
mode change 100644 => 100755
c/src/lib/libbsp/arm/stm32f4/include/stm32f4_flash.h
create mode 100755 c/src/lib/libbsp/arm/stm32f4/include/stm32f4_otgfs.h
create mode 100755 c/src/lib/libbsp/arm/stm32f4/include/stm32f4_pwr.h
mode change 100644 => 100755
c/src/lib/libbsp/arm/stm32f4/include/stm32f4_rcc.h
create mode 100755 c/src/lib/libbsp/arm/stm32f4/include/stm32f4_syscfg.h
create mode 100755 c/src/lib/libbsp/arm/stm32f4/include/stm32f4_tim.h
diff --git a/c/src/lib/libbsp/arm/stm32f4/Makefile.am
b/c/src/lib/libbsp/arm/stm32f4/Makefile.am
index 055a0b1..338f78d 100644
--- a/c/src/lib/libbsp/arm/stm32f4/Makefile.am
+++ b/c/src/lib/libbsp/arm/stm32f4/Makefile.am
@@ -49,9 +49,15 @@ include_bsp_HEADERS += include/stm32f4.h
include_bsp_HEADERS += include/stm32f10xxx_gpio.h
include_bsp_HEADERS += include/stm32f10xxx_rcc.h
include_bsp_HEADERS += include/stm32f10xxx_exti.h
+include_bsp_HEADERS += include/stm32f4_adc.h
+include_bsp_HEADERS += include/stm32f4_exti.h
include_bsp_HEADERS += include/stm32f4_gpio.h
include_bsp_HEADERS += include/stm32f4_rcc.h
+include_bsp_HEADERS += include/stm32f4_pwr.h
+include_bsp_HEADERS += include/stm32f4_syscfg.h
+include_bsp_HEADERS += include/stm32f4_tim.h
include_bsp_HEADERS += include/stm32f4_flash.h
+include_bsp_HEADERS += include/stm32f4_otgfs.h
include_bsp_HEADERS += include/stm32_i2c.h
include_bsp_HEADERS += include/i2c.h
include_bsp_HEADERS += include/stm32_usart.h
diff --git a/c/src/lib/libbsp/arm/stm32f4/include/stm32f4.h
b/c/src/lib/libbsp/arm/stm32f4/include/stm32f4.h
index d26f914..154d4f6 100644
--- a/c/src/lib/libbsp/arm/stm32f4/include/stm32f4.h
+++ b/c/src/lib/libbsp/arm/stm32f4/include/stm32f4.h
@@ -35,6 +35,11 @@
* @{
*/
+#define STM32F4_APB1_BASE (STM32F4_BASE + 0x4000)
+#define STM32F4_APB2_BASE (STM32F4_BASE + 0x4001)
+#define STM32F4_AHB1_BASE (STM32F4_BASE + 0x4002)
+#define STM32F4_AHB2_BASE (STM32F4_BASE + 0x5000)
+
/**
* @name STM32f4 GPIO
* @{
@@ -51,7 +56,7 @@
*/
#include
-#define STM32F4_RCC ((volatile stm32f4_rcc *) (STM32F4_BASE + 0x40023800))
+#define STM32F4_RCC ((volatile stm32f4_rcc *) (STM32F4_AHB1_BASE + 0x3800))
/** @} */
@@ -93,6 +98,99 @@
/** @} */
+/**
+ * @name STM32f4 PWR
+ * @{
+ */
+
+#include
+#define STM32F4_PWR ((volatile stm32f4_pwr *) (STM32F4_APB1_BASE + 0x7000))
+
+/** @} */
+
+/**
+ * @name STM32f4 EXTI
+ * @{
+ */
+
+#include
+#define STM32F4_EXTI ((volatile stm32f4_exti *) (STM32F4_APB2_BASE + 0x3c00))
+
+/** @} */
+
+/**
+ * @name STM32f4 SYSCFG
+ * @{
+ */
+
+#include
+#define STM32F4_SYSCFG ((volatile stm32f4_syscfg *) (STM32F4_APB2_BASE +
0x3800))
+
+/** @} */
+
+/**
+ * @name STM32f4 FLASH
+ * @{
+ */
+
+#include
+#define STM32F4_FLASH ((volatile stm32f4_flash *) (STM32F4_AHB1_BASE + 0x3c00))
+
+/** @} */
+
+/**
+ * @name STM32f4 TIM
+ * @{
+ */
+
+#include
+#define STM32F4_TIM1 ((volatile stm32f4_tim *) (STM32F4_APB2_BASE + 0x))
+#define STM32F4_TIM2 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x))
+#define STM32F4_TIM3 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x0400))
+#define STM32F4_TIM4 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x0800))
+#define STM32F4_TIM5 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x0c00))
+#define STM32F4_TIM6 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x1000))
+#define STM32F4_TIM7 ((volatile stm32f4_tim *) (STM32F4_APB1_BASE + 0x1
Re: STM32F4 register definitions and PLL settings patch
Hi, On 18/10/2014 3:45 AM, Tomasz Gregorek wrote: Hi Chris - pll_q = ( (long) ( src_clk * pll_n + src_clk * pll_n / 2 ) ) / pll_m / 48; + pll_q = ( (long) ( src_clk * pll_n ) ) / pll_m / 48; Your fix for the PLL_Q calculation is correct. It supposed to be rounding from <=X.5 to X and from >X.5 to (X+1) but first I messed up the equation second this clock should not exceed 48MHz so rounding up is not necessarily the best idea. A check for clock <= 48MHz would be good. Even better if we can check if USB is used and warn if it is not exactly 48MHz.. -#define FLASH_ACR_LATENCY( val ) BSP_FLD32( val, 0, 3 ) -#define FLASH_ACR_LATENCY_MSK BSP_MSK32( 0, 3 ) +#define STM32F4_FLASH_ACR_LATENCY(val) BSP_FLD32(val, 0, 2) // Flash access latency +#define STM32F4_FLASH_ACR_LATENCY_GET(reg) BSP_FLD32GET(reg, 0, 2) +#define STM32F4_FLASH_ACR_LATENCY_SET(reg, val) BSP_FLD32SET(reg, val, 0, 2) I would argue about the STM32F4_FLASH_ACR_LATENCY where you use 3LSB of ACR (up to 7 wait states) which is correct for the STM32F405xx/07xx and STM32F415xx/17xx while for the STM32F42xxx and STM32F43xxx there are 4LSBs in use (up to 15 wait states). I am not sure how to deal with it. Do we need to distinguish for which chip we are compiling? I think it should be safe to use 3 bits as it was. It's a pretty low risk that someone will accidentally set a flash latency > 7 and it is pretty likely a write to that bit would be ignored in the hardware anyway. Ideally yes when we support STM42xxx etc. as well we should add a build option, but there may be more we need to add, like the operating chip voltage. Honesty my priority so far is first adding register maps and example projects to make RTEMS more useful out of the box for standard boards like STM32F4Discovery. Thanks and regards Tomasz 2014-10-18 11:06 GMT+02:00 Chris Nott <mailto:chr...@vl.com.au>>: Hi, I sent these header file changes previously, they didn't get picked up. I re-merged with the head, cleaned up formatting and fixed a bug with PLL_Q setting not generating the right auxiliary clock frequency for USB peripheral - Tomasz this was your change, could you please review my fix. Regards, Chris. ___ devel mailing list devel@rtems.org <mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: STM32F4 register definitions and PLL settings patch
OK, thats good to hear. I have some extra code here I can incorporate when I have time, like DMA driven I2S audio, SPI and UART. On 19/10/2014 2:27 PM, Tomasz Gregorek wrote: Hi Chris Yes, there are more registers specific to specific CPU versions, different number of UARTs and other peripherals. As above, lets keep it simple for the start. Myself I have working UART driver with interrupt driven data receiver (currently it is polled UART). I should be able to push it in few days. I2C is half working but will take more time due to work overload. Cheers Tomasz Thanks and regards Tomasz 2014-10-18 11:06 GMT+02:00 Chris Nott mailto:chr...@vl.com.au>>: Hi, I sent these header file changes previously, they didn't get picked up. I re-merged with the head, cleaned up formatting and fixed a bug with PLL_Q setting not generating the right auxiliary clock frequency for USB peripheral - Tomasz this was your change, could you please review my fix. Regards, Chris. ___ devel mailing list devel@rtems.org <mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org <mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Decreasing BSS size for STM32F4
Hi,
I have a BSP almost identical to STM32F4 except I want a slight change
to the linker settings (I want to offset the start location because
there is a bootloader at location 0).
Two questions:
- Is there any way to do this other than to
a) duplicate the BSP and change just the linker files
b) use the STM32F4 BSP as-is but copy the linker files into the
application project and modify (this is the solution I am using now)
- As a matter of policy, how different should a platform be before we
fork a BSP?
On 29/10/2014 8:07 AM, Joel Sherrill wrote:
On 10/29/2014 10:03 AM, Мороз Олег wrote:
looks like the BSS segment is depend from RAM_SIZE. I'm changing file
called linkcmds:
MEMORY {
RAM_INT : ORIGIN = 0x2000, LENGTH = 128k
after building has
arm-rtems4.11-size shell.exe
text databssdechex filename
364756 32256 98824 495836 790dc shell.exe
.BSS is 98824
MEMORY {
RAM_INT : ORIGIN = 0x2000, LENGTH = 192k
arm-rtems4.11-size shell.exe
text databssdechex filename
364756 32256 164360 561372 890dc shell.exe
.BSS raised up to 164360
MEMORY {
RAM_INT : ORIGIN = 0x2000, LENGTH = 256K
arm-rtems4.11-size shell.exe
text databssdechex filename
364756 32256 229896 626908 990dc shell.exe
How can i fix the BSS size?
Sebastian should look into this but as a quick hint, the symbol marking
bss end sounds like it is after something indicating end of RAM. I have
seen this on other BSPs but the ARM linkcmds is shared, Sebastian did the
magic for that.
You should be able to spot the issue since you have test cases.
On 14.10.2014 14:47, Мороз Олег wrote:
arm-rtems4.11-readelf -l shell.exe
Elf file type is EXEC (Executable file)
Entry point 0x8000189
There are 4 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Align
EXIDX 0x027aa0 0x080279e8 0x080279e8 0x8 0x8 R
0x4
LOAD 0xb8 0x0800 0x0800 0x27a00 0x27a00 RWE
0x8
LOAD 0x027ab8 0x20001188 0x08027a00 0x0061c 0x0061c RW
0x8
LOAD 0x0280e0 0x2000 0x2000 0x0 0x3 RW
0x20
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .start .text .init .fini .rodata .ARM.exidx .eh_frame
.init_array .fini_array .jcr
02 .data
03 .vector .bss .work
On 14.10.2014 14:10, Sebastian Huber wrote:
arm-rtems4.11-readelf -l
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
