Date   

Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran <siddharth@...>
 

Hi Erwan,

Thanks, I did notice that. Infact that's the reason I ORed it to existing headder. But was unsure since none of the existing includes had a anything ORed with them.

Perhaps, we should OR all macros that uses the same header upfront so as to avoid such confusions?

diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
index 333095b..be905b1 100644 
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h 
@@ -127,33 +127,33 @@ 
* @{ 
*/ 

-#if defined(STM32F100xB) 
+#if defined(STM32F100xB) || defined(STM32F100x4) || 
defined(STM32F100x6) || defined (STM32F100x8) 
#include "stm32f100xb.h" 
-#elif defined(STM32F100xE) 
+#elif defined(STM32F100xE) || defined(STM32F100xC) || defined(STM32F100xD) 
#include "stm32f100xe.h" 
-#elif defined(STM32F101x6) 
+#elif defined(STM32F101x6) || defined(STM32F101x4) 
#include "stm32f101x6.h" 
-#elif defined(STM32F101xB) 
+#elif defined(STM32F101xB) || defined(STM32F101x8) 
#include "stm32f101xb.h" 
-#elif defined(STM32F101xE) 
+#elif defined(STM32F101xE) || defined(STM32F101xC) || defined(STM32F101xD) 
#include "stm32f101xe.h" 
-#elif defined(STM32F101xG) 
+#elif defined(STM32F101xG) || defined(STM32F101xF) 
#include "stm32f101xg.h" 
-#elif defined(STM32F102x6) 
+#elif defined(STM32F102x6) || defined(STM32F102x4) 
#include "stm32f102x6.h" 
-#elif defined(STM32F102xB) 
+#elif defined(STM32F102xB) || defined(STM32F102x8) 
#include "stm32f102xb.h" 
-#elif defined(STM32F103x6) 
+#elif defined(STM32F103x6) || defined(STM32F103x4) 
#include "stm32f103x6.h" 
-#elif defined(STM32F103xB) 
+#elif defined(STM32F103xB) || defined(STM32F103x8) 
#include "stm32f103xb.h" 
-#elif defined(STM32F103xE) 
+#elif defined(STM32F103xE) || defined(STM32F103xC) || defined(STM32F103xD) 
#include "stm32f103xe.h" 
-#elif defined(STM32F103xG) 
+#elif defined(STM32F103xG) || defined(STM32F103xF) 
#include "stm32f103xg.h" 
-#elif defined(STM32F105xC) 
+#elif defined(STM32F105xC) || defined(STM32F105x8) || defined(STM32F105xB) 
#include "stm32f105xc.h" 
-#elif defined(STM32F107xC) 
+#elif defined(STM32F107xC) || defined(STM32F107xB) 
#include "stm32f107xc.h" 
#else 
#error "Please select first the target STM32F1xx device used in your 
application (in stm32f1xx.h file)" 


Siddharth.


---- On Wed, 17 May 2017 14:20:52 +0530 erwan.gouriou@... wrote ----

According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h,
you should use STM32F103xB:
  /* #define STM32F103xB  */   /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, STM32F103TB and STM32F103VB */

Erwan

On 17 May 2017 at 09:21, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list






Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 15/05/17 17:37, Daniel Thompson wrote:
On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).
I will get back to you as soon as I can!
Yes!

It solves the problem in the sense that devices are now enumerating correctly! However I'm afraid that the code isn't really robust enough for me to contemplate a pull request at this point (even with ModemManager disabled I am only getting a couple of characters from samples/subsys/usb/console).

I'll try to keep a rebase branch working on my github for anyone interested (branch has Christer's patch, 96b_carbon support and modifications in samples/subsys/usb to allow some of the examples to build):
https://github.com/daniel-thompson/zephyr/tree/hacking/carbon-usb


Daniel.


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...>> wrote:

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.

Can you offer any clues?


Daniel.


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

According to ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h,
you should use STM32F103xB:
  /* #define STM32F103xB  */   /*!< STM32F103C8, STM32F103R8, STM32F103T8, STM32F103V8, STM32F103CB, STM32F103RB, STM32F103TB and STM32F103VB */

Erwan

On 17 May 2017 at 09:21, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list





Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

Hi Siddharth,


Thanks for the update. I'll have a look about STM32F103x8 and get back to you.
This is indeed strange not having a define for this part.

Erwan

On 16 May 2017 at 21:53, Siddharth Chandrasekaran <siddharth@...> wrote:
Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list




Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran <siddharth@...>
 

Hi Erwan,

Thanks for your speedy response, that was very helpful. After adding the pin mux settings, I was able to get the UART to work.

I added a new CONFIG value for STM32F103X8 and had to do a bunch of other things to get it to work. Here is an updated patch http://embedjournal.com/board_stm32_min_dev_v1.patch please have a look.

The part that I am worried about is,
diff --git a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
index 333095b..8dc37db 100644
--- a/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
+++ b/ext/hal/st/stm32cube/stm32f1xx/soc/stm32f1xx.h
@@ -145,7 +145,7 @@
   #include "stm32f102xb.h"
 #elif defined(STM32F103x6)
   #include "stm32f103x6.h"
-#elif defined(STM32F103xB)
+#elif defined(STM32F103xB) || defined(STM32F103x8)
   #include "stm32f103xb.h"
 #elif defined(STM32F103xE)
   #include "stm32f103xe.h"

Since, I couldn't find a stm32f103x8.h (ST's own sdk ships with an stm32f10xxx.h), I am just using stm32f103xb.h instead. Is this acceptable?. For now things look okay, but will have to validate this a little further to know for sure. Once I document the board, will send the PR.

-Siddharth.

---- On Mon, 15 May 2017 13:42:46 +0530 Erwan Gouriou <erwan.gouriou@...> wrote ----

Hello Siddharth,
It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c
Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).
Regarding upstream; yes, we'll be please to have this board supported!
Erwan



On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:


Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list



Re: Reading Values From not supported sensors

Marti Bolivar <marti.bolivar@...>
 

+list

Please remember to keep the list in CC.

On May 16, 2017 1:00 PM, "Marti Bolivar" <marti.bolivar@...> wrote:
Hi Kevin,

Your temperature sensor needs a Zephyr driver to work with the sensor subsystem, yes. If your sensor is not supported right now, you may be able to write a driver for it and submit it for merging upstream, using existing drivers as examples.

Marti

On May 16, 2017 12:11 PM, "Kevin Stöckl" <k_stoeckl@...> wrote:

But is this only possible with the supported sensors (mcp9808,...) or can i take every temperature sensor?




Von: Marti Bolivar <marti.bolivar@...>
Gesendet: Dienstag, 16. Mai 2017 17:02
An: Kevin Stöckl
Cc: zephyr-devel@...ct.org
Betreff: Re: [Zephyr-devel] Reading Values From not supported sensors
 
Hi Kevin,

Temperature sensor support is working in Zephyr. You can search the samples/ directory for the string "SENSOR_CHAN_TEMP" to find example code which reads temperature sensors:

https://github.com/zephyrproject-rtos/zephyr/search?q=SENSOR_CHAN_TEMP&type=

Hope this helps,
Marti


On 16 May 2017 at 07:25, Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Representing Sensor Values with Arduino DUE

Kevin Stöckl <k_stoeckl@...>
 

Hello,


I want to represent my sensor values which are collected with the Arduino DUE in the web over WiFi. For Example in thingsboard.io.
How is it possible to realize this?

Thanks in Advance

Kevin


Re: Reading Values From not supported sensors

Marti Bolivar <marti.bolivar@...>
 

Hi Kevin,

Temperature sensor support is working in Zephyr. You can search the samples/ directory for the string "SENSOR_CHAN_TEMP" to find example code which reads temperature sensors:

https://github.com/zephyrproject-rtos/zephyr/search?q=SENSOR_CHAN_TEMP&type=

Hope this helps,
Marti


On 16 May 2017 at 07:25, Kevin Stöckl <k_stoeckl@...> wrote:

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Reading Values From not supported sensors

Kevin Stöckl <k_stoeckl@...>
 

Hello,

is it possible to read values from not supported sensors, like temperature senors. And how is this possible.


Thanks, Kevin


Re: STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

On 15/05/17 10:19, Erwan Gouriou wrote:
Hi Daniel,
I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.
I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182
Please have a look and tell me if it solves the issue
I took a quick look at this. It didn't "just work" for me but I am pretty short of time today and a couple of other things didn't "just work" either (and they should have done).

I will get back to you as soon as I can!


Daniel.



On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@... <mailto:daniel.thompson@...>> wrote:
Hi Erwan
I've taken another look at Christer Weinigel's patched for USB on
STM32F4 recently.
I'm having a problem with the new LL clock code.
I applied the following patch to Christer's work in order to bring
it up to date w.r.t. the LL clock driver:
diff --git a/drivers/usb/device/usb_dc_stm.c
b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk =
device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};
clock_control_on(clk, (clock_control_subsys_t *)&pclken);
Unfortunately this change is not enough to get the USB code to work.
Have I done the translation correctly?
I think the problem is one of enable rather than USB clock rate
(there is no attempt to hotplug... if the USB clock rate were wrong
hotplug detect would work but there would be no comms).
Finally, just to double check my assumptions about, I did do a
bisect to try and chase thise problem down. bisect took me straight
to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know
this is strictly related to the clock driver change rather than any
other zephyr changes.
Can you offer any clues?
Daniel.


BSD Sockets like API: prototyping report #4

Paul Sokolovsky
 

Hello,

Given that initial prototyping was complete and issues were identified
and at least workarounds exist, I started process of refactoring the
code into the in-tree subsystem:
https://github.com/zephyrproject-rtos/zephyr/pull/153 . This is not
targeted for 1.8, but rather for 1.9 window, so feel free to skip for
now if you're busy with 1.8 release work.

I also posted instructions to build the prototype version in the
MicroPython codebase:
https://github.com/pfalcon/micropython/wiki/ZephyrSocket

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: STM32F4: Correct translation from native to LL clock driver

Erwan Gouriou
 

Hi Daniel,

I think I spotted the bug, which is indeed in the commit you pointed.
It appears with current code (stm32_clock_control_on), you can't activate AHB2 clock on F4.

I've pushed following commit to solve the case:
https://github.com/zephyrproject-rtos/zephyr/pull/182

Please have a look and tell me if it solves the issue

Erwan


On 13 May 2017 at 12:16, Daniel Thompson <daniel.thompson@...> wrote:
Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
 static int usb_dc_stm_clock_enable(void)
 {
        struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
-       struct stm32f4x_pclken pclken = {
-               .bus = STM32F4X_CLOCK_BUS_AHB2,
-               .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+       struct stm32_pclken pclken = {
+               .bus = STM32_CLOCK_BUS_AHB2,
+               .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
        };

        clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work. Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate (there is no attempt to hotplug... if the USB clock rate were wrong hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a bisect to try and chase thise problem down. bisect took me straight to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know this is strictly related to the clock driver change rather than any other zephyr changes.

Can you offer any clues?


Daniel.


Re: Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Erwan Gouriou
 

Hello Siddharth,

It seems your porting miss the pinmux configuration driver file, cf:
drivers/pinmux/stm32/pinmux_board_nucleo_f103rb.c

Then, you'll have to create a new CONFIG value "SOC_STM32F103X8". We need to identify stm32 SoC variants with the last letter in order to keep the Flash size information.
You'll use this value to fill flash/ram in in dts/arm/st/mem.h (please rebase if you don't see it).

Regarding upstream; yes, we'll be please to have this board supported!

Erwan




On 14 May 2017 at 23:20, Siddharth Chandrasekaran <siddharth@...> wrote:
Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Representing Sensor Values with Arduino DUE

Kevin Stöckl <k_stoeckl@...>
 

Hello,


I want to represent my sensor values which are collected with the Arduino DUE in the web over WiFi. For Example in thingsboard.io.
How is it possible to realize this?

Thanks in Advance

Kevin


Porting Zephyr to STM32F103C8T6 Minimum System Development Board

Siddharth Chandrasekaran <siddharth@...>
 

Hello,

I am trying to port Zephyr into one of the cheap, breadboard friendly, "STM32F103C8T6 Minimum System Development Boards" (link not attached due to overwhelming results in Google) and I am facing some difficulty.

So far, with the other ported boards as a reference, I was able to setup a new board and get the blinky sample application to work. However, I am unable to get console logs to show up in UART_1 as expected. I have tried the hello_world and shell applications without much luck.

Digging a little deeper, I realised that the SOC support had STM32103XB and there isn't a STM32103X8 or a STM32103XX. Now I am beginning now wondering if there is a reason why the SOC was called STM32103XB and not STM32103XX, as the data sheet for the two of them is unified. I also verified that the peripheral register address map for UART 1 is in fact at the the same location as in the STM32103XB, which means at least UART 1 should work even if the SOCs aren't compatible.

Here is a patch to my work so far http://embedjournal.com/board_stm32_min_dev.patch. Do let me know If I am missing something. Also, is this a hardware that the upstream will be interested in? It's a pretty popular design although there are slight incistencies. I can raise a PR after successful validation if it means anything.

Thanks,
Sid.


1.8 Merge window

Nashif, Anas
 

Hi,

Due to the late release of Zephyr  v1.7 and the infrastructure move to github, the TSC has decided to extend the merge window until May 19th. All major changes and feature submissions have to be submitted and reviewed by end of next week.

 

Once we tag RC1 we will only be accepting bug fixes, documentation and stabilization related changes. Please make sure you have submitted all changes and features ASAP to make it into the 1.8 release.

 

Thanks,

Anas

 


STM32F4: Correct translation from native to LL clock driver

Daniel Thompson <daniel.thompson@...>
 

Hi Erwan

I've taken another look at Christer Weinigel's patched for USB on STM32F4 recently.

I'm having a problem with the new LL clock code.

I applied the following patch to Christer's work in order to bring it up to date w.r.t. the LL clock driver:

diff --git a/drivers/usb/device/usb_dc_stm.c b/drivers/usb/device/usb_dc_stm.c
index 070e6766bf67..49f7dbffd5c3 100644
--- a/drivers/usb/device/usb_dc_stm.c
+++ b/drivers/usb/device/usb_dc_stm.c
@@ -149,9 +149,9 @@ static void usb_dc_stm_isr(void *arg)
static int usb_dc_stm_clock_enable(void)
{
struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
- struct stm32f4x_pclken pclken = {
- .bus = STM32F4X_CLOCK_BUS_AHB2,
- .enr = STM32F4X_CLOCK_ENABLE_OTGFS,
+ struct stm32_pclken pclken = {
+ .bus = STM32_CLOCK_BUS_AHB2,
+ .enr = LL_AHB2_GRP1_PERIPH_OTGFS,
};

clock_control_on(clk, (clock_control_subsys_t *)&pclken);

Unfortunately this change is not enough to get the USB code to work. Have I done the translation correctly?

I think the problem is one of enable rather than USB clock rate (there is no attempt to hotplug... if the USB clock rate were wrong hotplug detect would work but there would be no comms).

Finally, just to double check my assumptions about, I did do a bisect to try and chase thise problem down. bisect took me straight to 80b7bec ("soc: stm32f4: Enable LL based clock control") so I know this is strictly related to the clock driver change rather than any other zephyr changes.

Can you offer any clues?


Daniel.


Re: [RFC] Touchscreen driver API

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-05-09 at 13:54 +0200, Tomasz Bursztyka wrote:
I don't know much about touchscreens myself but as a sensor, because it
basically is one,
is there any reason why you specifically did not make this with sensor API?

Some of the existing attributes and functions there seem really meant
for such usage.

If things are missing in sensor API, wouldn't it be worth improving that
API then?
So the sensor API (like most things in Zephyr) doesn't specify much in
the way dynamic behaviour, or implementation or usage constraints.
Specifically in this case, how often trigger handlers get called and
there interaction with calls to channel_get and sample_fetch.

So, for my driver, I've implementation so that the first call to
channel_get after a sample_fetch triggers a work item to enabled the
trigger callback for the next sample. Which means for suitably written
client code, we can guarantee to a) see all sample events and b) not
hang waiting for a callback.

This doesn't really help other people writing touchscreen drivers or
other users of my driver, as they won't know the usage semantics. But at
least my driver now uses an official Zephyr API, with the following
modification...

--- a/include/sensor.h
+++ b/include/sensor.h
@@ -110,6 +110,12 @@ enum sensor_channel {
        SENSOR_CHAN_GREEN,
        /** Altitude, in meters */
        SENSOR_CHAN_ALTITUDE,
+       /**
+        * Touchscreen X,Y and Z (pressure) samples, in device specific units.
+        * Higher pressure is lower Z values and the maximum Z integer value
+        * (0x7fffffff) indicates that the screen isn't being touched.
+        */
+       SENSOR_CHAN_TOUCHSCREEN_XYZ,
        /** All channels. */
        SENSOR_CHAN_ALL,
 };

--
Tixy


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Chuck Jordan <Chuck.Jordan@...>
 

Be sure to also get the data sheet for the device attached to SPI or I2C.
There are configurable options you must do correctly to communicate properly to the device on the other side.

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Bogdan Davidoaia
Sent: Thursday, May 11, 2017 1:00 AM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Hello,

Although they are not specific to ARC, you can look over most of the sensor drivers (in drivers/sensor/) for use of I2C and SPI.

Use of the I2C/SPI API is the same regardless of the platform, so it should be an ok starting point.

Regards,
Bogdan



On 11 May 2017 at 08:12, Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...> wrote:


Hi Team



Do you have any sample/example of Using I2C or SPI driver of ARC (
sensor
subsystem) in Quark_se ?



Thanks






_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproje
ct.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0
tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKS
QRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI
&e=
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=nirrrHvTYPm_ezoRVKSQRHEVyJyfsiT6yrNJC04V0C0&s=rW_84jfRfJ5BSA2GSTM_0-tJAVqNHs73iLJNKcJ0FtI&e=


Re: I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

Dinh, Kien T
 

Have you looked at the gpio sample under samples/drivers/gpio?

 

It’s just “GPIO_0”, and it depends whether the app is built for ARC or x86.

For x86, it can be built with:

$ make BOARD=arduino_101

And for ARC, it can be built with

$ make BOARD=arduino_101_sss

 

Regards,

Kien

 

From: "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 18:35
To: Kien Dinh <kien.t.dinh@...>, "users@..." <users@...>, "devel@..." <devel@...>
Cc: Bogdan Davidoaia <bogdan.davidoaia@...>
Subject: RE: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi

 

Iam using zephyr 1.6.0 downloaded from the site

 

If I need to toggle a simple GPIO on the Sensor subsystem, In the Kconfig file of the ARC

Config options given are GPIO_QMSI , GPIO_QMSI_SS & GPIO_QMSI_SS_0_NAME (default name is GPIO_SS_0)

 

So In device binding we need to give as device_get_binding(“GPIO_SS_0”);

If I give as device_get_binding(“GPIO_0”); then x86 gpio is toggling.

 

Can you confirm this ?

 

 

Do you have any example of gpio with sensor subsystem ?

 

 

 

Thanks


From: Dinh, Kien T [mailto:kien.t.dinh@...]
Sent: Thursday, May 11, 2017 2:41 PM
To: Mahendravarman Rajarao (RBEI/EAA10) <Mahendravarman.Rajarao@...>; users@...; devel@...
Subject: Re: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

Hi Mahendravarman,

 

You might try to look at the samples folder in the repository. The below examples are using I2C and SPI on ARC:

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/drivers/current_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/environmental_sensing

https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/sensor/bme280

 

Regards,

Kien

 

 

From: <zephyr-devel-bounces@...> on behalf of "Mahendravarman Rajarao (RBEI/EAA10)" <Mahendravarman.Rajarao@...>
Date: Thursday, May 11, 2017 14:12
To: "
users@..." <users@...>, "devel@..." <devel@...>
Subject: [Zephyr-devel] I2C or SPI Driver Example for ARC (Sensor subsystem) for Quark_se

 

 

Hi Team

 

Do you have any sample/example of Using I2C or SPI driver of ARC ( sensor subsystem) in Quark_se ?

 

Thanks

 

 

5701 - 5720 of 8627