Date   

[PATCH] arm: board: Fix stm32f4_disco defconfig

andreas.koelbl@...
 

From: Andreas Kölbl <andreas.koelbl@st.oth-regensburg.de>

This change fixes the prescaler values in the defconfig. The prescaler values
shown in the technical reference manual (STM32F407xx, p.19) differ from those in
the defconfig which results in wrong timer delays.

Signed-off-by: Andreas Kölbl <andreas.koelbl@st.oth-regensburg.de>
---
For further information about the fix look at
https://lists.zephyrproject.org/pipermail/zephyr-users/2017-July/000618.html

boards/arm/stm32f4_disco/stm32f4_disco_defconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/boards/arm/stm32f4_disco/stm32f4_disco_defconfig b/boards/arm/stm32f4_disco/stm32f4_disco_defconfig
index f67fa14ed..6290c8e19 100644
--- a/boards/arm/stm32f4_disco/stm32f4_disco_defconfig
+++ b/boards/arm/stm32f4_disco/stm32f4_disco_defconfig
@@ -27,10 +27,10 @@ CONFIG_CLOCK_STM32_SYSCLK_SRC_PLL=y
# use HSE as PLL input
CONFIG_CLOCK_STM32_PLL_SRC_HSE=y
# produce 168MHz clock at PLL output
-CONFIG_CLOCK_STM32_PLL_M_DIVISOR=4
-CONFIG_CLOCK_STM32_PLL_N_MULTIPLIER=72
+CONFIG_CLOCK_STM32_PLL_M_DIVISOR=8
+CONFIG_CLOCK_STM32_PLL_N_MULTIPLIER=336
CONFIG_CLOCK_STM32_PLL_P_DIVISOR=2
-CONFIG_CLOCK_STM32_PLL_Q_DIVISOR=3
+CONFIG_CLOCK_STM32_PLL_Q_DIVISOR=7
CONFIG_CLOCK_STM32_AHB_PRESCALER=1
-CONFIG_CLOCK_STM32_APB1_PRESCALER=2
-CONFIG_CLOCK_STM32_APB2_PRESCALER=1
+CONFIG_CLOCK_STM32_APB1_PRESCALER=4
+CONFIG_CLOCK_STM32_APB2_PRESCALER=2
--
2.13.3


Re: STM32 LL SPI driver

Marti Bolivar <marti.bolivar@...>
 

Does this reproduce in the loopback test for you? Are you able to take an analog trace?

On Aug 1, 2017 1:22 PM, "Matthias Bösl" <matthias.boesl@...> wrote:

Yes, I do.


On Tue, Aug 1, 2017, 7:20 PM Michał Kruszewski <mkru@...> wrote:
I tested new SPI on nrf5 boards and everything looks ok.
Do you use spi contex to control CS gpio?

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] STM32 LL SPI driver
Local Time: August 1, 2017 4:59 PM
UTC Time: August 1, 2017 2:59 PM
To: Matthias Bösl <matthias.boesl@...>
Zephyr Devel <devel@...>

Hi Matthias,

Thank you for your reply.

I cannot reproduce the issue here.

On 96b_carbon (STM32F4 based), with my series, CS GPIO is glitch free when testing with tests/drivers/spi/spi_loopback. Analog looks good too; typical waveform looks like this: http://imgur.com/a/9tY22

Do you have any repro steps I could try? Can you take an analog trace to see if perhaps there's a signal quality issue on your board?

Thanks,
Marti



On 1 August 2017 at 10:12, Matthias Bösl <matthias.boesl@...> wrote:
Hi Marti,

tested with and without your patch, same behavior with both versions

BR,

Matthias

On Tue, Aug 1, 2017 at 4:08 PM Marti Bolivar <marti.bolivar@...> wrote:
Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png
_______________________________________________
Zephyr-devel mailing list



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



Re: STM32 LL SPI driver

Matthias Boesl
 

Yes, I do.


On Tue, Aug 1, 2017, 7:20 PM Michał Kruszewski <mkru@...> wrote:
I tested new SPI on nrf5 boards and everything looks ok.
Do you use spi contex to control CS gpio?

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] STM32 LL SPI driver
Local Time: August 1, 2017 4:59 PM
UTC Time: August 1, 2017 2:59 PM
To: Matthias Bösl <matthias.boesl@...>
Zephyr Devel <devel@...>

Hi Matthias,

Thank you for your reply.

I cannot reproduce the issue here.

On 96b_carbon (STM32F4 based), with my series, CS GPIO is glitch free when testing with tests/drivers/spi/spi_loopback. Analog looks good too; typical waveform looks like this: http://imgur.com/a/9tY22

Do you have any repro steps I could try? Can you take an analog trace to see if perhaps there's a signal quality issue on your board?

Thanks,
Marti



On 1 August 2017 at 10:12, Matthias Bösl <matthias.boesl@...> wrote:
Hi Marti,

tested with and without your patch, same behavior with both versions

BR,

Matthias

On Tue, Aug 1, 2017 at 4:08 PM Marti Bolivar <marti.bolivar@...> wrote:
Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

Matthias
_______________________________________________
Zephyr-devel mailing list



Re: STM32 LL SPI driver

Michał Kruszewski <mkru@...>
 

I tested new SPI on nrf5 boards and everything looks ok.
Do you use spi contex to control CS gpio?

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] STM32 LL SPI driver
Local Time: August 1, 2017 4:59 PM
UTC Time: August 1, 2017 2:59 PM
From: marti.bolivar@...
To: Matthias Bösl <matthias.boesl@...>
Zephyr Devel <devel@...>

Hi Matthias,

Thank you for your reply.

I cannot reproduce the issue here.

On 96b_carbon (STM32F4 based), with my series, CS GPIO is glitch free when testing with tests/drivers/spi/spi_loopback. Analog looks good too; typical waveform looks like this: http://imgur.com/a/9tY22

Do you have any repro steps I could try? Can you take an analog trace to see if perhaps there's a signal quality issue on your board?

Thanks,
Marti



On 1 August 2017 at 10:12, Matthias Bösl <matthias.boesl@...> wrote:
Hi Marti,

tested with and without your patch, same behavior with both versions

BR,

Matthias

On Tue, Aug 1, 2017 at 4:08 PM Marti Bolivar <marti.bolivar@...> wrote:
Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png
_______________________________________________
Zephyr-devel mailing list



Re: STM32 LL SPI driver

Marti Bolivar <marti.bolivar@...>
 

Hi Matthias,

Thank you for your reply.

I cannot reproduce the issue here.

On 96b_carbon (STM32F4 based), with my series, CS GPIO is glitch free when testing with tests/drivers/spi/spi_loopback. Analog looks good too; typical waveform looks like this: http://imgur.com/a/9tY22

Do you have any repro steps I could try? Can you take an analog trace to see if perhaps there's a signal quality issue on your board?

Thanks,
Marti



On 1 August 2017 at 10:12, Matthias Bösl <matthias.boesl@...> wrote:
Hi Marti,

tested with and without your patch, same behavior with both versions

BR,

Matthias

On Tue, Aug 1, 2017 at 4:08 PM Marti Bolivar <marti.bolivar@...> wrote:
Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png

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




Re: STM32 LL SPI driver

Matthias Boesl
 

Hi Marti,

tested with and without your patch, same behavior with both versions

BR,

Matthias

On Tue, Aug 1, 2017 at 4:08 PM Marti Bolivar <marti.bolivar@...> wrote:
Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png

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



Re: STM32 LL SPI driver

Marti Bolivar <marti.bolivar@...>
 

Hi Matthias,


Thanks,
Marti

On 1 August 2017 at 02:56, Matthias Bösl <matthias.boesl@...> wrote:
I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png

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



Re: bug in http server

Erwin Rol
 

Hey Yannis,

On Tue, 2017-08-01 at 10:11 +0300, Yannis Damigos wrote:
Hi Erwin

On Mon, Jul 31, 2017 at 11:57 PM, Erwin Rol <mailinglists@erwinrol.com> wrote:
Hey Anas, Erwan,

I fixed the compile bug, but on the olimex board the ethernet is no not
functional.

I got two boards (same STM32F407 CPU), one is working, one (the olimex)
isn't. Both were working before the changes to the pinmux stuff.

The olimex does receive ethernet but can't send, the other board can
send and receive. The only obvious difference is the GPIO pins that are
used. The working board uses pins from GPIOB where the non working
olimex uses pins (the 3 TX pins) from GPIOG.

Is there anything special I have to do to enable GPIOG ? GPIOC and GPIOB
are used by the for example the UARTS, but GPIOG is only used by the ETH
controller, so did I forgot some initialization stuff or something like
that?
Did you try to enable CONFIG_GPIO_STM32_PORTG? I took a look into
samples/net/http_server/outdir/olimex_stm32_e407/.config and GPIOG is
not enabled.
GPIOG not being enabled by default by the board was one issue I fixed
while looking into the bug report by Anas, should have mentioned that.

But even with GPIOG enabled in the menu things don't work, I really have
the feeling port GPIOG somehow isn't clocked or does not have its
alternate-functions set correctly.

- Erwin


Re: bug in http server

Yannis Damigos
 

Hi Erwin

On Mon, Jul 31, 2017 at 11:57 PM, Erwin Rol <mailinglists@erwinrol.com> wrote:
Hey Anas, Erwan,

I fixed the compile bug, but on the olimex board the ethernet is no not
functional.

I got two boards (same STM32F407 CPU), one is working, one (the olimex)
isn't. Both were working before the changes to the pinmux stuff.

The olimex does receive ethernet but can't send, the other board can
send and receive. The only obvious difference is the GPIO pins that are
used. The working board uses pins from GPIOB where the non working
olimex uses pins (the 3 TX pins) from GPIOG.

Is there anything special I have to do to enable GPIOG ? GPIOC and GPIOB
are used by the for example the UARTS, but GPIOG is only used by the ETH
controller, so did I forgot some initialization stuff or something like
that?
Did you try to enable CONFIG_GPIO_STM32_PORTG? I took a look into
samples/net/http_server/outdir/olimex_stm32_e407/.config and GPIOG is
not enabled.

Yannis

- Erwin


PS: Anas do you want me to push the compile fix, because even if the
driver isn't working the fix I have is correct (just used the wrong
defines).


On Mon, 2017-07-31 at 13:32 +0000, Nashif, Anas wrote:
Hi,

Please take a look at this bug:
https://jira.zephyrproject.org/browse/ZEP-2452



This happened with olimex_stm32_e407 board.





Anas


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


STM32 LL SPI driver

Matthias Boesl
 

I'm about porting the enc28j60 to the new SPI driver (stm32f4 + CS GPIO pin), after some debugging, I found the CS pin seems to go high for a very short time in between a transaction, did anyone observe similar behavior?

screenshot attached

Best,

MatthiasScreenshot from 2017-08-01 08-15-57.png


Re: Reg: Zephyr

Bandaru Sivakrishna <bandarusivakrishna@...>
 

Thank you Neil and Justin Watson for reply.

On Mon, Jul 31, 2017 at 8:39 PM, Neil Armstrong <narmstrong@...> wrote:
Hi SivaKrishna, Edward,

Porting Zephyr to such SoCs is doable, but it need to workout support for Class-A Cortex processors from ARM.
The support itself is quite easy since other RTOS does support them, but you won't support the major features of these cpus like the MMU for memory protection, ...

Such support seems so have some supporters, but none has done the work yet.
If you find time and support for such feature, implement it and the community will certainly review it.

Anyway, like other replied, it will also need Schematics of the boards, but personally I don't think it blocking since there is Mainline U-Boot and Linux support for these boards.

Neil

On 07/31/2017 04:59 PM, Justin Watson wrote:
> Porting Raspberry Pi 3 has many issues. Zephyr OS does not support the Raspberry Pi 3. The Raspberry Pi 3 is a different ARM architecture than what we currently have support for. The Raspberry Pi 3 is Cortex A5, we currently support a few Cortex M versions. Adding support for another architecture is a major undertaking. This is just the SoC issue. The next problem with porting for the Raspberry Pi 3 board is that you don't have schematics. This means you can't support any of the hardware on the board. The schematics for Raspberry Pi boards are proprietary and are not released to the public at all. Do you work for Raspberry Pi Organization? If not, I doubt you can get the schematics.
>
> On Mon, Jul 31, 2017 at 7:32 AM Bandaru Sivakrishna <bandarusivakrishna@... <mailto:bandarusivakrishna@gmail.com>> wrote:
>
>     Hi Zephyr Dev Team,
>
>     I am planning to port this Zephyr OS on to Raspberrypi3 board. So i have
>     below queries
>     1) Raspberry pi3 board supports Zephyr os or not to port?
>     2) In case it supports, what are the steps i need to take care?
>
>     Thank you,
>     SivaKrishna.
>     _______________________________________________
>     Zephyr-devel mailing list
>     Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
>     https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@lists.zephyrproject.org
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>



Re: bug in http server

Nashif, Anas
 

Erwin,
Can we have this communication the related JIRA please?

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwin Rol
Sent: Monday, July 31, 2017 4:57 PM
To: Zephyr Devel List <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] bug in http server

Hey Anas, Erwan,

I fixed the compile bug, but on the olimex board the ethernet is no not functional.

I got two boards (same STM32F407 CPU), one is working, one (the olimex) isn't. Both were working before the changes to the pinmux stuff.

The olimex does receive ethernet but can't send, the other board can send and receive. The only obvious difference is the GPIO pins that are used. The working board uses pins from GPIOB where the non working olimex uses pins (the 3 TX pins) from GPIOG.

Is there anything special I have to do to enable GPIOG ? GPIOC and GPIOB are used by the for example the UARTS, but GPIOG is only used by the ETH controller, so did I forgot some initialization stuff or something like that?

- Erwin


PS: Anas do you want me to push the compile fix, because even if the driver isn't working the fix I have is correct (just used the wrong defines).


On Mon, 2017-07-31 at 13:32 +0000, Nashif, Anas wrote:
Hi,

Please take a look at this bug:
https://jira.zephyrproject.org/browse/ZEP-2452



This happened with olimex_stm32_e407 board.





Anas


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


Re: bug in http server

Erwin Rol
 

Hey Anas, Erwan,

I fixed the compile bug, but on the olimex board the ethernet is no not
functional.

I got two boards (same STM32F407 CPU), one is working, one (the olimex)
isn't. Both were working before the changes to the pinmux stuff.

The olimex does receive ethernet but can't send, the other board can
send and receive. The only obvious difference is the GPIO pins that are
used. The working board uses pins from GPIOB where the non working
olimex uses pins (the 3 TX pins) from GPIOG.

Is there anything special I have to do to enable GPIOG ? GPIOC and GPIOB
are used by the for example the UARTS, but GPIOG is only used by the ETH
controller, so did I forgot some initialization stuff or something like
that?

- Erwin


PS: Anas do you want me to push the compile fix, because even if the
driver isn't working the fix I have is correct (just used the wrong
defines).

On Mon, 2017-07-31 at 13:32 +0000, Nashif, Anas wrote:
Hi,

Please take a look at this bug:
https://jira.zephyrproject.org/browse/ZEP-2452



This happened with olimex_stm32_e407 board.





Anas


Re: Public and Private API's

Boie, Andrew P
 

Private APIs are for internal use by the kernel and can change at any time. They are prefixed with an underscore.

Public APIs are intended to be stable and typically go through a deprecation process before changing.

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Bøe, Sebastian
Sent: Monday, July 31, 2017 5:20 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Public and Private API's

 

Hi,

 

what is the difference between the "public" and "private" API header files?

(Other than their location)

 

Thanks in advance.

 


Re: incoming build dependency on Python elftools

Boie, Andrew P
 

This was all updated, yes.

 

Andrew

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Monday, July 31, 2017 12:42 AM
To: Boie, Andrew P <andrew.p.boie@...>; zephyr-devel@...
Subject: RE: incoming build dependency on Python elftools

 

Hi Andrew,

 

(Outlook doesn’t allow me to quote here, sorry).

 

Have you updated the build instructions in the Getting Started guides? Those contain the list of Python packages required, and, in the case of MSYS2, instructions to install pip.

 

Regards,

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Boie, Andrew P
Sent: 24 July 2017 18:31
To: zephyr-devel@...
Subject: [Zephyr-devel] incoming build dependency on Python elftools

 

Some changes are coming in to convert host build tools like gen_idt and gen_offset_header to Python, as well as some new tools to support memory protection which involve parsing DWARF information in the built ELF binaries.

 

To support this change, we will additionally require the Python 3 build of the pyelftools package, version 0.24 or later. You will need to install this on your development workstation. Please note that some Linux distristributions are out-of-date on this package, including the current version of Fedora and Ubuntu 16.04 and earlier. Because of this we recommend installing this via 'pip'. The documentation will be updated when the patches land, but in brief:

 

  pip3 install --user pyelftools

 

You may need to install the Python 3 version of pip, the package name on both Ubuntu and Fedora is 'python3-pip'.

 

Andrew


Re: Reg: Zephyr

Neil Armstrong
 

Hi SivaKrishna, Edward,

Porting Zephyr to such SoCs is doable, but it need to workout support for Class-A Cortex processors from ARM.
The support itself is quite easy since other RTOS does support them, but you won't support the major features of these cpus like the MMU for memory protection, ...

Such support seems so have some supporters, but none has done the work yet.
If you find time and support for such feature, implement it and the community will certainly review it.

Anyway, like other replied, it will also need Schematics of the boards, but personally I don't think it blocking since there is Mainline U-Boot and Linux support for these boards.

Neil

On 07/31/2017 04:59 PM, Justin Watson wrote:
Porting Raspberry Pi 3 has many issues. Zephyr OS does not support the Raspberry Pi 3. The Raspberry Pi 3 is a different ARM architecture than what we currently have support for. The Raspberry Pi 3 is Cortex A5, we currently support a few Cortex M versions. Adding support for another architecture is a major undertaking. This is just the SoC issue. The next problem with porting for the Raspberry Pi 3 board is that you don't have schematics. This means you can't support any of the hardware on the board. The schematics for Raspberry Pi boards are proprietary and are not released to the public at all. Do you work for Raspberry Pi Organization? If not, I doubt you can get the schematics.

On Mon, Jul 31, 2017 at 7:32 AM Bandaru Sivakrishna <bandarusivakrishna@gmail.com <mailto:bandarusivakrishna@gmail.com>> wrote:

Hi Zephyr Dev Team,

I am planning to port this Zephyr OS on to Raspberrypi3 board. So i have
below queries
1) Raspberry pi3 board supports Zephyr os or not to port?
2) In case it supports, what are the steps i need to take care?

Thank you,
SivaKrishna.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



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


Re: Reg: Zephyr

Justin
 

Porting Raspberry Pi 3 has many issues. Zephyr OS does not support the Raspberry Pi 3. The Raspberry Pi 3 is a different ARM architecture than what we currently have support for. The Raspberry Pi 3 is Cortex A5, we currently support a few Cortex M versions. Adding support for another architecture is a major undertaking. This is just the SoC issue. The next problem with porting for the Raspberry Pi 3 board is that you don't have schematics. This means you can't support any of the hardware on the board. The schematics for Raspberry Pi boards are proprietary and are not released to the public at all. Do you work for Raspberry Pi Organization? If not, I doubt you can get the schematics.


On Mon, Jul 31, 2017 at 7:32 AM Bandaru Sivakrishna <bandarusivakrishna@...> wrote:
Hi Zephyr Dev Team,

I am planning to port this Zephyr OS on to Raspberrypi3 board. So i have
below queries
1) Raspberry pi3 board supports Zephyr os or not to port?
2) In case it supports, what are the steps i need to take care?

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


Public and Private API's

Sebastian Boe
 

Hi,


what is the difference between the "public" and "private" API header files?
(Other than their location)


Thanks in advance.



STM32F4 clock bug

Andreas Kölbl <andreas.koelbl@...>
 

Hello,

I'm working on a stm32f4_discovery board (defconfig). No changes besides enabling GPIOs.

The blinky example works, but the k_sleep call is about ~2.x slower than expected. Digging a bit deeper, the k_timer shows the same slow motion effect.

Anyone experiencing similar behaviour on that board?

Do I have to change some timer settings? Actually I thought that default settings for that board would provide an accurate setting.

Thanks,

--
Andreas Kölbl


howto sanitycheck does not work

Bobby
 

Hello,

I tried to run the sanitcheck as descibed in the Contribution Guide but I get an error message.

Are there any additional commands to be issued?


Thats what I issued on vanilla zephyr:master:

$ source zephyr-env.sh
$ make host-tools
$ export PREBUILT_HOST_TOOLS=${ZEPHYR_BASE}/bin
$ export USE_CCACHE=1
$ ./scripts/sanitycheck

Thatś what I got:

~/zephyr$ ./scripts/sanitycheck
Generating LALR tables
Selecting default platforms per test case
Building testcase defconfigs...
Traceback (most recent call last):
  File "./scripts/sanitycheck", line 2096, in <module>
    main()
  File "./scripts/sanitycheck", line 1991, in main
    args.platform_limit, toolchain, args.extra_args, args.ccache)
  File "./scripts/sanitycheck", line 1407, in apply_filters
    with open(out_config, "r") as fp:
FileNotFoundError: [Errno 2] No such file or directory: '/home/bernhard/zephyr/sanity-out/bbc_microbit/tests/kernel/gen_isr_table/test/.config-sanitycheck'



Bobby

5361 - 5380 of 8521