Re: issue with missing log api
Hi Chris,
that does the trick! Although I now run into a different
issue:
Compiling apps/s/src/events.cc
Compiling apps/s/src/console.cc
Error: In file included from
repos/apache-mynewt-core/kernel/os/include/os/os.h:132:0, from
apps/s/src/events.h:7, from apps/s/src/events.cc:1:
repos/apache-mynewt-core/kernel/os/include/os/os_mutex.h: In function
'os_error_t os_mutex_get_level(os_mutex*)':
repos/apache-mynewt-core/kernel/os/include/os/os_mutex.h:122:16: error:
invalid conversion from 'uint16_t {aka short unsigned int}' to
'os_error_t {aka os_error}' [-fpermissive] return mu->mu_level;
^~~~
I guess not a lot of folks check for C++ compatibility. But that's a bug I can
fix myself ;)
Thanks a lot,
Markus
On Tue, 5 Feb 2019 07:32:04 -0800
Christopher Collins wrote:
> Hi Markus,
>
> On Mon, Feb 04, 2019 at 08:34:50PM -0800, markus wrote:
> > I updated to the latest master from github (4fedf428) and now my
> > projects break with the error message:
> >
> > Building target targets/s
> > Error: Unsatisfied APIs detected:
> > * log, required by: sys/log/modlog
>
> To solve this issue without enabling logging, you can add
> `@apache-mynewt-core/sys/log/stub` to your app's list of dependencies
> (`pkg.deps`). This satisfies the `log` API requirement without
> pulling in any actual logging functionality.
>
> This is not a great fix--it does the job, but it is a hassle for the
> developer. A solution that does not require you to modify a `pkg.yml`
> file would be much better. I have a few ideas, but haven't
> implemented anything yet. We should definitely do something about
> this problem before the next release so others don't struggle with
> this one. Thanks for raising this issue.
>
> You are seeing this issue because logging has been integrated
> into several more core packages. I think most projects already use a
> log package and are unaffected, but that is just an assumption.
>
> By the way, the `newt target revdep ` command is a useful
> tool for debugging issues like this. In this case, it will tell you
> which package(s) depends on modlog.
>
> > Since I neither need nor want any logging in my app I figured I'll
> > turn it off by setting
> >
> > NEWT_FEATURE_LOGCFG: 0
> >
> > in syscfg.yml - unfortunately this results in a segfault in the newt
> > tool. Updating that to the latest master (bc272f6e) has the same
> > result.
>
> The `NEWT_FEATURE_[...]` settings should not be overridden. I
> probably would have tried the same thing :).
>
> Chris
issue with missing log api
I updated to the latest master from github (4fedf428) and now my projects break with the error message: Building target targets/s Error: Unsatisfied APIs detected: * log, required by: sys/log/modlog Since I neither need nor want any logging in my app I figured I'll turn it off by setting NEWT_FEATURE_LOGCFG: 0 in syscfg.yml - unfortunately this results in a segfault in the newt tool. Updating that to the latest master (bc272f6e) has the same result. Any idea what's going on here? Thanks in advance, Markus
Re: MYNEWT_VAL(...) invalid syntax ?
Hi Fabio, that gets me a bit further - although I'm not too excited about the duplication between syscfg.yml and the linker script. Anyway, further down the road I ran into an undefined function in the linker: stm32f3_flash_dev() 'turns out that got replaced with a global structure stm32_flash_dev - however, the global structure is not in any header file while the device specific (now non-existing) function declarations are still in the stm32f*_bsp.h I've adapted my bsp implementation accordingly so I can build it successfully again. Thanks for all the help, Markus On Wed, 09 Jan 2019 07:13:42 -0200 Fabio Utzig wrote: > Hi Markus, > > You may need to update your BSP's `syscfg.yml`, check one included > BSPs that has the same MCU that you're using for a complete list. > Your particular failure is that your `syscfg.yml` is missing a > "STM32_FLASH_SIZE_KB" entry. > > Best, > Fabio > > On Wed, Jan 9, 2019, at 4:30 AM, markus wrote: > > Hi Lukasz, > > > > did manually build newt and run into some build failures: > > > > . > > Compiling repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/ > > hal_gpio.c > > Error: In file included from > > repos/apache-mynewt-core/kernel/os/include/ os/mynewt.h:23:0, > > from > > repos/apache-mynewt-core/hw/mcu/stm/stm32_common/ > > src/hal_flash.c:21: > > bin/targets/spi/generated/include/syscfg/syscfg.h:15:49: error: > > 'MYNEWT_VAL_STM32_FLASH_SIZE_KB' undeclared here (not in a > > function); did you mean 'MYNEWT_VAL_STM32_FLASH_IS_LINEAR'? #define > > MYNEWT_VAL(x) MYNEWT_VAL_ ## x ^ > > repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:30:30: > > note: in expansion of macro 'MYNEWT_VAL' > > #define _FLASH_SIZE (MYNEWT_VAL(STM32_FLASH_SIZE_KB) * > > 1024) ^~ > > repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:64:16: > > note: in expansion of macro '_FLASH_SIZE' > > .hf_size = _FLASH_SIZE, > > ^~~ > > > > Anything else I should be doing? > > I also updated master again - just in case > > * master cb9ece042 hw/drivers/lps33thw: Restore > > read error stats > > > > Thanks again, > > Markus > > > > > > > > On Tue, 8 Jan 2019 07:05:11 +0100 > > Łukasz Rymanowski wrote: > > > > > Hi Markus, > > > > > > If master is used on mynewt-core then master branch of newt tool > > > should be used. Please try this and let us know of it works for > > > you > > > > > > Best > > > Lukasz > > > > > > > > > On Tue, Jan 8, 2019, 06:18 markus > > > > > > 'been away for a few months and I can't build my projects > > > > anymore. I updated repos/apache-mynewt-core to the latest > > > > master branch (59912fc02) and it seems I'm running the latest > > > > newt tool, 1.5.0 > > > > > > > > Executing `newt build ...` gives me an error for each package in > > > > apache-mynewt-core: > > > > > > > > * Warning: Parsing pkg @apache-mynewt-core/boot/boot_serial > > > > config: strconv.ParseInt: parsing > > > > "MYNEWT_VAL(BOOT_SERIAL_SYSINIT_STAGE_MAIN)": invalid syntax; > > > > ignoring package. > > > > > > > > > > > > I couldn't find anything in the release notes - any clues as to > > > > what I'm doing wrong would be much appreciated. > > > > > > > > Thanks, > > > > Markus > > > > > >
Re: MYNEWT_VAL(...) invalid syntax ?
Hi Lukasz, did manually build newt and run into some build failures: . Compiling repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_gpio.c Error: In file included from repos/apache-mynewt-core/kernel/os/include/os/mynewt.h:23:0, from repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:21: bin/targets/spi/generated/include/syscfg/syscfg.h:15:49: error: 'MYNEWT_VAL_STM32_FLASH_SIZE_KB' undeclared here (not in a function); did you mean 'MYNEWT_VAL_STM32_FLASH_IS_LINEAR'? #define MYNEWT_VAL(x) MYNEWT_VAL_ ## x ^ repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:30:30: note: in expansion of macro 'MYNEWT_VAL' #define _FLASH_SIZE (MYNEWT_VAL(STM32_FLASH_SIZE_KB) * 1024) ^~ repos/apache-mynewt-core/hw/mcu/stm/stm32_common/src/hal_flash.c:64:16: note: in expansion of macro '_FLASH_SIZE' .hf_size = _FLASH_SIZE, ^~~ Anything else I should be doing? I also updated master again - just in case * master cb9ece042 hw/drivers/lps33thw: Restore read error stats Thanks again, Markus On Tue, 8 Jan 2019 07:05:11 +0100 Łukasz Rymanowski wrote: > Hi Markus, > > If master is used on mynewt-core then master branch of newt tool > should be used. Please try this and let us know of it works for you > > Best > Lukasz > > > On Tue, Jan 8, 2019, 06:18 markus > > 'been away for a few months and I can't build my projects anymore. I > > updated repos/apache-mynewt-core to the latest master branch > > (59912fc02) and it seems I'm running the latest newt tool, 1.5.0 > > > > Executing `newt build ...` gives me an error for each package in > > apache-mynewt-core: > > > > * Warning: Parsing pkg @apache-mynewt-core/boot/boot_serial config: > > strconv.ParseInt: parsing > > "MYNEWT_VAL(BOOT_SERIAL_SYSINIT_STAGE_MAIN)": invalid syntax; > > ignoring package. > > > > > > I couldn't find anything in the release notes - any clues as to what > > I'm doing wrong would be much appreciated. > > > > Thanks, > > Markus > >
Re: MYNEWT_VAL(...) invalid syntax ?
Great - thanks for the clarification, that makes sense. Have fun, Markus On Tue, 8 Jan 2019 13:11:29 -0800 Christopher Collins wrote: > The next version of the newt tool will be backwards compatible with > older Mynewt repos. The latest versions of the Mynewt repos are > taking advantage of a new newt feature (syscfg values in `pkg.yml`), > so they do not work with older versions of newt. If a repo does not > use this new feature, then it will be compatible with both old and > new versions of the newt tool. > > Backwards compatiblity is important, and it is always bad when an > upgrade breaks something. This particular feature seemed important > enough to introduce such breakage because it will actually help to > maintain backwards compatibility in the future. The feature allows > Mynewt YAML files to switch their configuration based on the version > of newt being used. For example: > > pkg.item.NEWT_FEATURE_FOO > - ... > > That item only gets processed if the newt tool injects the > `NEWT_FEATURE_FOO` setting. The item does not get processed with > older versions of newt which do not support the `FOO` feature. Older > versions of newt could not process conditional items in most of the > YAML files, so would always process the above item. > > Chris > > On Tue, Jan 08, 2019 at 11:23:58AM -0800, markus wrote: > > Hey Chris, > > > > that is understood and fine, the question and to some degree > > concern is the other way around. Will the next version of the newt > > tool be incompatible with all existing repositories? > > > > I understand that apache-mynewt-core and all other mynewt managed > > repositories don't have a problem with such a change. But what about > > all the other repositories? > > > > Thanks, > > Markus > > > > > > > > On Tue, 8 Jan 2019 10:29:24 -0800 > > Christopher Collins wrote: > > > > > Hi Markus, > > > > > > On Tue, Jan 08, 2019 at 10:15:22AM -0800, markus wrote: > > > > Hi Lukasz, > > > > > > > > got it, I guess I have to start building newt. > > > > > > > > Follow up question: Does this mean the next release will break > > > > all repositories out there or is backwards compatibility still > > > > on the roadmap for this release? > > > > > > The next mynewt release will only be compatible with the version > > > of newt that is released at the same time. An attempt to use an > > > older newt with the newt repos will fail with instructions to > > > upgrade newt. > > > > > > Chris > >
Re: MYNEWT_VAL(...) invalid syntax ?
Hey Chris, that is understood and fine, the question and to some degree concern is the other way around. Will the next version of the newt tool be incompatible with all existing repositories? I understand that apache-mynewt-core and all other mynewt managed repositories don't have a problem with such a change. But what about all the other repositories? Thanks, Markus On Tue, 8 Jan 2019 10:29:24 -0800 Christopher Collins wrote: > Hi Markus, > > On Tue, Jan 08, 2019 at 10:15:22AM -0800, markus wrote: > > Hi Lukasz, > > > > got it, I guess I have to start building newt. > > > > Follow up question: Does this mean the next release will break all > > repositories out there or is backwards compatibility still on the > > roadmap for this release? > > The next mynewt release will only be compatible with the version of > newt that is released at the same time. An attempt to use an older > newt with the newt repos will fail with instructions to upgrade newt. > > Chris
Re: MYNEWT_VAL(...) invalid syntax ?
Hi Lukasz, got it, I guess I have to start building newt. Follow up question: Does this mean the next release will break all repositories out there or is backwards compatibility still on the roadmap for this release? Thanks, Markus On Tue, 8 Jan 2019 07:05:11 +0100 Łukasz Rymanowski wrote: > Hi Markus, > > If master is used on mynewt-core then master branch of newt tool > should be used. Please try this and let us know of it works for you > > Best > Lukasz > > > On Tue, Jan 8, 2019, 06:18 markus > > 'been away for a few months and I can't build my projects anymore. I > > updated repos/apache-mynewt-core to the latest master branch > > (59912fc02) and it seems I'm running the latest newt tool, 1.5.0 > > > > Executing `newt build ...` gives me an error for each package in > > apache-mynewt-core: > > > > * Warning: Parsing pkg @apache-mynewt-core/boot/boot_serial config: > > strconv.ParseInt: parsing > > "MYNEWT_VAL(BOOT_SERIAL_SYSINIT_STAGE_MAIN)": invalid syntax; > > ignoring package. > > > > > > I couldn't find anything in the release notes - any clues as to what > > I'm doing wrong would be much appreciated. > > > > Thanks, > > Markus > >
linking woes with weak linkage
I'm sure it's just my newt kung-fu that isn't strong enough, here is what I'm trying to do: in the package hw/mcu/stm/stm32_common there is a function called (let's say): stm32_hal_timer_get_freq for specific processors I want to overwrite that function, so I implement the same function in package hw/mcu/stm/stm32f3xx. Now I tought if I make the implementation in stm32_common a weak symbol the linker would pick up the processor specific version if one was supplied. As it turns out that's not the case. The reason seeming to be that stm32_common is linked before stm32f3xx, so the linker resolve the symbol from stm32_common. If I rename the package "stm32_common" to "~stm32_common" it gets linked after "stm32f3xx" and the linker picks up the correct implementation. Is there a better way of telling newt to link one library before another one? Note that the stm32f3xx package has a dependency on the stm32_common package
Re: os data.core memory section
Hey Will,
thanks for the background - much appreciated.
I did indeed need the additional memory to store a time series
generated at high frequencies, so offloading wasn't an option. I solved
it by storing some of the time series in CCM memory, which is probably
the better solution anyway.
Given the constraints around CCM and DTCM, it might actually be better
if the OS doesn't use it. I guess I got confused, misled by the "core"
in the section name, which in retrospect probably applies to the MCU and
not the OS.
Thanks for all the input,
Markus
On Mon, 2 Apr 2018 10:54:32 -0700
will sanfilippo <wi...@runtime.io> wrote:
> Markus:
>
> I presume you are referring to these definitions:
>
> #define sec_data_core __attribute__((section(".data.core")))
> #define sec_bss_core__attribute__((section(".bss.core")))
> #define sec_bss_nz_core __attribute__((section(".bss.core.nz")))
>
> As far as I know there is no real magic here but I am sure there is
> some degree of inconsistency.
>
> The reason sec_bss_nz_core was added was to get around a HW problem
> with early nordic chips (you can see the reference in nrf52.ld) so I
> do not doubt that this is no longer used. Personally, I think the
> idea of having a “non-zeroed .bss” is pretty cool. I guess one could
> simply call that the heap but sometimes you just like allocating a
> global variable and not allocating it from the heap. I realize that
> the only real reason to do this is save time in the startup code
> zeroing out memory (but still; that is cool!) :-) Not quite sure why
> “core” was added to that defintion. Maybe because there was some
> conflict with naming it bss.nz?
>
> I should probably look at the STM startup code to be sure of this but
> I presume they use sec_data_core for both code and data they want to
> locate in CCM. This is basically a .data section in that the startup
> code needs to copy this from flash (whether it be code or initialized
> data).
>
> I guess sec_bss_core is used to store variables in CCM that just need
> to get zeroed by the startup code.
>
> btw, I am no STM CPU/memory architecture expert but I was reading up
> on it and they do not suggest putting both code and data into CCM. Of
> course, if you need the RAM you need the RAM… Is that why you want to
> move a stack there? I guess if all your code is executing from flash
> then putting data into CCM is fine (maybe faster is SRAM is slower?).
>
> Seems to me it would be nice to differentiate “core text” from “core
> data”. No real reason I guess but seems a bit more intuitive. Might
> be nice to come up with a set of “standard” section definitions (if
> they do not already exist somewhere) that we can apply across all
> BSPs/MCUs.
>
>
> > On Mar 31, 2018, at 4:02 PM, markus <mar...@bibi.ca> wrote:
> >
> > I looked into moving the stack into the CCM memory of the stm32
> > mcu's - and although almost every linker script defines ".data.core"
> > sections and there are some defines in bsp.h's for section
> > attributes they don't seem to be used.
> >
> > Is there some hidden magic going on or is the CCM reserved for
> > application code?
> >
> > Have fun,
> > Markus
>
Re: os data.core memory section
On Mon, 02 Apr 2018 14:16:54 -0300 Fabio Utzig <ut...@apache.org> wrote: > Both > > hw/mcu/stm/stm32f7xx/stm32f767.ld > hw/mcu/stm/stm32f4xx/stm32f407.ld > > already define the stack on CCM (called DTCM on the F7xx). Am I > missing something here? It might be me who's missing something (most likely scenario). The linker scripts do indeed define the DTCM and CCM memory regions and gives them names, ".stack" and ".data.core" depending on the linker script. What I'm missing is that those sections aren't used anywhere in the code. The stacks for (main/idle) tasks are defined by OS_TASK_STACK_DEFINE in os_task.h, which sets the alignment but not the section. Looking at the generated memory map from an stm32f7 app all the sections are there but I cannot identify anything actually placed in there. But then the linker has always been a bit of a dark art to me so I might just not be looking at the right things, or properly interpret what I'm seeing. > > On Mon, Apr 2, 2018, at 2:15 PM, Christopher Collins wrote: > > Hi Markus, > > > > On Sat, Mar 31, 2018 at 04:02:05PM -0700, markus wrote: > > > I looked into moving the stack into the CCM memory of the stm32 > > > mcu's - and although almost every linker script defines > > > ".data.core" sections and there are some defines in bsp.h's for > > > section attributes they don't seem to be used. > > > > > > Is there some hidden magic going on or is the CCM reserved for > > > application code? > > > > No hidden magic; CCM is mostly unused and is up for grabs. I think > > there was some attempt to use this memory intelligently a while > > back, but as the number of supported BSPs increased, it became > > impractical. > > > > When you say "the stack", do you mean the interrupt handler stack? > > That sounds like a reasonable use of CCM (though you and others > > probably have a better sense of this than I do). If this is > > something that users will want to do, it might be good to create a > > syscfg setting to control whether the stack gets put in CCM or > > normal RAM. > > > > Chris
os data.core memory section
I looked into moving the stack into the CCM memory of the stm32 mcu's - and although almost every linker script defines ".data.core" sections and there are some defines in bsp.h's for section attributes they don't seem to be used. Is there some hidden magic going on or is the CCM reserved for application code? Have fun, Markus
Re: STM32 backbone library
That is an excellent question. After reading the statements more carefully it seems ST reserves the right for none-portability: "... The HAL and LL are complementary and cover a wide range of applications requirements: * The HAL offers high-level and feature-oriented APIs, with a high portability level. They hide the MCU and peripheral complexity to end-user. * The LL offers low-level APIs at registers level, with better optimization but less portability. They require deep knowledge of the MCU and peripherals specifications. ..." When they talk about family compatibility they continue to use terms like "high" and either both APIs are mentioned or none at all (just talking about STM32Cube in general). The only time there seems to be a difference is in the global STM32Cube introduction page: "... STM32Cube embedded software libraries, including: The HAL hardware abstraction layer, enabling portability between different STM32 devices via standardized API calls The Low-Layer (LL) APIs, a light-weight, optimized, expert oriented set of APIs designed for both performance and runtime efficiency A collection of Middleware components, like RTOS, USB library, file system, TCP/IP stack, Touch sensing library or Graphic Library (depending on the MCU series) ..." Personally I've never seen a difference or discrepancy - if there was an applicable LL api it worked for all mcu's. But that might say more about my experience with their devices than about the real portability of the LL. On Wed, 28 Mar 2018 06:50:35 -0300 Fabio Utzig <ut...@apache.org> wrote: > On Tue, Mar 27, 2018, at 3:45 PM, markus wrote: > > Hey Miguel, > > > > as you can tell - still causing trouble ;) > > > > I should have mentioned that both APIs, LL (low level) and HAL (high > > level) are provided by ST Microelectronics and are part of their > > SDKs. > > > > Although the LL API is called "low level" it is still portable > > between the different STM32 processor families. The big advantage > > is that it is stateless, doesn't require big data structures, and > > allows finer control. > > Yes, feel free to use it! Btw, is there any explicit "contract" where > it is mentioned that they will always be portable across different > families?
Re: STM32 backbone library
Hey Miguel, as you can tell - still causing trouble ;) I should have mentioned that both APIs, LL (low level) and HAL (high level) are provided by ST Microelectronics and are part of their SDKs. Although the LL API is called "low level" it is still portable between the different STM32 processor families. The big advantage is that it is stateless, doesn't require big data structures, and allows finer control. HTH, Markus On Tue, 27 Mar 2018 17:54:47 + Miguel Azevedo <miguella...@gmail.com> wrote: > Hey Markus! > How are you doing? > > Yes, In fact our Nordic drivers are a wraparound to the > manufacturer's drivers. So what is happening is [mynewt > driver]--->[nordic driver]--->[nordic hal]. Is this optimal? > No, but it works because Nordic works out every workaround for any > possible hw/hal bug. > This allows us to have a driver which works for all nRF52xxx chips. > I wouldn't oppose to have the same going on with STM(despite the fact > that I don't know much about their hw/libs). > I think a good person to ask this is Fabio Utzig, I believe he has > some experience with these boards and he's aware of how STM hw works. > :) > > Best Regards, > Miguel > > > On Tue, Mar 27, 2018 at 5:27 PM, markus <mar...@bibi.ca> wrote: > > I have a PWM implementation for the STM32 (currently F3 & F7) but > > I'm not happy with it - which is why there currently is no PR. > > > > Most of what I want to change is the use of the backend library, > > using the LL api instead of HAL. All STM32 bindings I could find in > > mynewt are based on the HAL library ... > > > > Is it acceptable to base a peripheral library on the LL api or is > > that not something to be done in mynewt? > > > > Have fun, > > Markus > > >
STM32 backbone library
I have a PWM implementation for the STM32 (currently F3 & F7) but I'm not happy with it - which is why there currently is no PR. Most of what I want to change is the use of the backend library, using the LL api instead of HAL. All STM32 bindings I could find in mynewt are based on the HAL library ... Is it acceptable to base a peripheral library on the LL api or is that not something to be done in mynewt? Have fun, Markus
Re: New user: Installing newt on Debian 9.4: Problems with openocd
Hey Kevin, I've never seen this error. Looks like there is something wrong with your installation though. If apt ignores your trusted.gpg file it won't load anything from the mynewt repo. You'll have to fix that first - I'm afraid I'm not an expert in that. Good luck, Markus On Tue, 13 Mar 2018 23:14:47 + Kevin & Pauline Gordon <kgplg...@gmail.com> wrote: > Hello Markus, > > I have successfully upgraded from Debian Stretch to Testing (Busty) > and installed openocd: > > root@kgdebian:~# which openocd > /usr/bin/openocd > root@kgdebian:~# openocd -v > Open On-Chip Debugger 0.10.0 > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > > I then moved onto installing newt: > > root@kgdebian:~# wget -qO - > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/mynewt.gpg.key > > | sudo apt-key add - > OK > W: The key(s) in the keyring /etc/apt/trusted.gpg are ignored as the > file has an unsupported filetype. > root@kgdebian:~# sudo tee /etc/apt/sources.list.d/mynewt.list < > deb [arch=amd64] > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest main > > EOF > deb [arch=amd64] > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest main root@kgdebian:~# apt-get update > Get:1 > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest InRelease [1,762 B] Hit:2 http://ftp.nz.debian.org/debian > testing InRelease Err:1 > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest InRelease The following signatures couldn't be verified > because the public key is not available: NO_PUBKEY 4E9A819250B4B104 > Reading package lists... Done > W: > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/dists/latest/InRelease: > > The key(s) in the keyring /etc/apt/trusted.gpg are ignored as the > file has an unsupported filetype. > W: GPG error: > https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest InRelease: The following signatures couldn't be verified > because the public key is not available: NO_PUBKEY 4E9A819250B4B104 > E: The repository > 'https://raw.githubusercontent.com/runtimeco/debian-mynewt/master > latest InRelease' is not signed. > N: Updating from such a repository can't be done securely, and is > therefore disabled by default. > N: See apt-secure(8) manpage for repository creation and user > configuration details. > W: http://ftp.nz.debian.org/debian/dists/testing/InRelease: The > key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file > has an unsupported filetype. > > Which has problems with: " The key(s) in the keyring > /etc/apt/trusted.gpg are ignored as the file has an unsupported > filetype." > > root@kgdebian:~# apt-key list > /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg > -- > pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] > 126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010 > uid [ unknown] Debian Archive Automatic Signing Key > (8/jessie) <ftpmas...@debian.org> > > /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg > --- > pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] > D211 6914 1CEC D440 F2EB 8DDA 9D6D 8F6B C857 C906 > uid [ unknown] Debian Security Archive Automatic Signing > Key (8/jessie) <ftpmas...@debian.org> > > /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg > --- > pub rsa4096 2013-08-17 [SC] [expires: 2021-08-15] > 75DD C3C4 A499 F1A1 8CB5 F3C8 CBF8 D6FD 518E 17E1 > uid [ unknown] Jessie Stable Release Key > <debian-rele...@lists.debian.org> > > /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg > --- > pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20] > E1CF 20DD FFE4 B89E 8026 58F1 E0B1 1894 F66A EC98 > uid [ unknown] Debian Archive Automatic Signing Key > (9/stretch) <ftpmas...@debian.org> > sub rsa4096 2017-05-22 [S] [expires: 2025-05-20] > > /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg > > pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20] > 6ED6 F5CB 5FA6 FB2F 460A E88E EDA0 D238 8AE2 2BA9 > uid [ unknown] Debian Security Archive Automatic Signing > Key (9/stretch) <ftpmas...@debian.org> > sub rsa4096 2017-05-22 [S] [expires: 2025-05-2
Re: New user: Installing newt on Debian 9.4: Problems with openocd
Hey Kevin, I'm running Debian Testing and use the stock openocd that comes with it. I use the newt tools from the runtimco apt repo. Everything seems to work well and I don't remember there being any issues with dependencies. HTH, Markus On Tue, 13 Mar 2018 02:21:20 + Kevin & Pauline Gordon <kgplg...@gmail.com> wrote: > Hi everyone, I have subscribed to the dev list today. > > I have been working through the section "Installing the ARM Toolchain > For Linux" and have completed: > > apt-get install gcc-arm-none-eabi > > ... > > Setting up gcc-arm-none-eabi (15:5.4.1+svn241155-1) ... > Processing triggers for libc-bin (2.24-11+deb9u3) ... > > successfully. > > Next task: "Installing the OpenOCD Debugger" > > I have installed: > https://github.com/runtimeco/openocd-binaries/raw/master/openocd-bin-0.10.0-Linux.tgz > > which (in Debian 9.4) has problems with dependencies. > > I tried to install openocd_0.10.0-4_amd64.deb but this also has > problems with dependencies: > > The following packages have unmet dependencies: > openocd : Depends: libjaylink0 but it is not installable > Depends: libjim0.77 (>= 0.73) but it is not installable > E: Unable to correct problems, you have held broken packages. > > > root@kgdebian:~# apt-get install > /root/Downloads/libjaylink0_0.1.0-1_amd64.deb > Reading package lists... Done > Building dependency tree > Reading state information... Done > Note, selecting 'libjaylink0' instead of > '/root/Downloads/libjaylink0_0.1.0-1_amd64.deb' > The following NEW packages will be installed: > libjaylink0 > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/17.1 kB of archives. > After this operation, 62.5 kB of additional disk space will be used. > Get:1 /root/Downloads/libjaylink0_0.1.0-1_amd64.deb libjaylink0 amd64 > 0.1.0-1 [17.1 kB] > Selecting previously unselected package libjaylink0. > (Reading database ... 304002 files and directories currently > installed.) Preparing to unpack .../libjaylink0_0.1.0-1_amd64.deb ... > Unpacking libjaylink0 (0.1.0-1) ... > Setting up libjaylink0 (0.1.0-1) ... > Processing triggers for libc-bin (2.24-11+deb9u3) ... > N: Download is performed unsandboxed as root as file > '/root/Downloads/libjaylink0_0.1.0-1_amd64.deb' couldn't be accessed > by user '_apt'. - pkgAcquire::Run (13: Permission denied) > > I was able to resolve: > > apt-get install libftdi1-2 > apt-get install libhidapi-hidraw0 > > apt-get install libusb-0.1-4 > > but I am unable to resolve libjim0.77 > > Perhaps I should return to: > https://github.com/runtimeco/openocd-binaries/raw/master/openocd-bin-0.10.0-Linux.tgz > > Has anyone installed this tar on Debian? What list of dependencies > did you use (with version numbers)? > > Your help would be much appreciated. > > Regards, > > Kevin. > >
pkg.lflags of dependencies not picked up
I checked out Miguels easing library and I had to duplicate the pkg.lflags: - '-lm' in 'app/pwm_test/pkg.yml' although it is already set in 'utils/easing/pkg.yml'. Without it the build fails with unresolved symbols. Is this a known issue? Have fun, Markus
Re: PWM API, new features should be driver specific or not?
Awesome indeed! On Fri, 09 Mar 2018 10:32:49 -0800 "Sterling Hughes" <sterling.hughes.pub...@gmail.com> wrote: > Awesome, thanks @mlaz. > > On 8 Mar 2018, at 21:00, Miguel Azevedo wrote: > > > Hi Markus, and everyone else, > > > > My proposal for changes on our PWM API is on this PR (most recent > > commit): > > https://github.com/apache/mynewt-core/pull/836 > > > > I think it takes care of the oversized unorganized datastructure > > problem and allows a clean use of basic PWM capabilities (i.e. > > looping a duty cycle / playing a dyuty cycle for n cycles) as well > > as for interrupts. > > Again, I believe all of these features are implementable on most HW > > based PWM implementations, however this API interface still allows > > us to use a simple PWM device without any interrupts. > > I also added the pwm_get_top_value and updated doc, as requested. > > > >> Personally I probably would have combined the ISRs into a single > >> callback function and use an additional enumeration parameter to > >> determine the "trigger". This would allow future extensions, say > >> if a counter supports more than one compare value. > > > > I see, although this would make us have to use an enumeration for > > the event type(or "trigger") plus a mechanism to include user data > > according to it, I don't know what kind of other feature you want to > > see on PWM but I suppose it isn't that standard and will probably be > > implementable using pwm_chan_cfg.data. > > > >> As for the nrf52 suggestion, what I meant was that the new api is > >> a super-set of the old api. So once you implement a driver with > >> the new api you can easily implement a driver with the old api by > >> creating an interface layer that just sets all extra pointers and > >> values to dummy values. > > > > Having to maintain 2 APIs for the same driver doesn't make much > > sense to me, why not a single scalable API? > > We can even have some macros to optimize the internal > > datastructures' size(regarding the interrupt related fields) like > > PWM_CYCLE_INT and PWM_SEQ_END_INT. Take a look at pwm_test I got on > > that branch I PRed, it uses this API with both a fully featured > > driver and a simpler one. > > > > Best Regards, > > > > Miguel > > > > On Thu, Mar 1, 2018 at 6:42 AM, markus <mar...@bibi.ca> wrote: > >> wow - it's an email day for me > >> > >> I like the idea of having a single pointer for the additional > >> values, or changing `data` to a pointer to said structure instead > >> of a `void*` (and move the void* into that structure). > >> > >> Personally I probably would have combined the ISRs into a single > >> callback function and use an additional enumeration parameter to > >> determine the "trigger". This would allow future extensions, say > >> if a counter supports more than one compare value. > >> > >> > >> As for the nrf52 suggestion, what I meant was that the new api is > >> a super-set of the old api. So once you implement a driver with > >> the new api you can easily implement a driver with the old api by > >> creating an interface layer that just sets all extra pointers and > >> values to dummy values. > >> > >> Have fun, > >> Markus > >> > >> > >> PS: about all the many emails - I got the STM32 port to work > >> yesterday so before going further I wanted to clarify the > >> interface, and then you sent out this email - and I didn't want to > >> mix topics, hijack your thread . So if anybody asks, I'll > >> blame you - just so you know ;) > >> > >> > >> On Thu, 1 Mar 2018 01:54:53 -0300 > >> Miguel Azevedo <miguella...@gmail.com> wrote: > >> > >>> Hi again Markus, > >>> > >>>> I think your enhancements should be their own driver. Plain PWM > >>>> is such a basic need and feature that I think the interface for > >>>> it should be as simple as possible. I'm also concerned about the > >>>> memory footprint increase, which is 3x that of the original > >>>> interface (and that's just the data structure). > >>> > >>> Agreed. Although if you re-use the structure it isn't such a > >>> dramatic > >>> increase in memory footprint. > >>> Regarding the datastructure size I believe we can keep t
Re: recommendations for IO pin declarations
Hi Miguel, that is what I'm currently doing. I thought it might be possible to store the alternate function in the pin itself, if a pin variable would have at leas 12 bit. But mynewt does not declare a type for a pin, and there is no standard about the variable size of storing a pin. Some components (including pwm) use a uint8_t - which is barely enough to store the pad id alone. For now it seems we'll have to put the burden of on the user. Thanks, Markus On Fri, 9 Mar 2018 04:16:44 -0100 Miguel Azevedo <miguella...@gmail.com> wrote: > Hi Markus, > > One thing I forgot to mention, and that after giving this some thought > makes some sense, is to pass the pin restriction information (what > channels a pin may accept, etc) using the data parameter on > pwm_dev_init, passed through os_dev_create which is called on > hal_bsp.c. For me it makes sense to have these values stored somewhere > on the BSP (or even MCU), since they look like they are directly > dependent on the board model(or the mcu model?) you're using. > > Best regards, > > Miguel > > On Thu, Mar 1, 2018 at 5:57 PM, Wayne Keenan <wayne.kee...@gmail.com> > wrote: > > It is a complicated issue indeed. > > Forgetting the pins, the CubeMX tool also resolves conflicts of > > clock sources as well. (STM chips are most flexible/interesting :) ) > > > > So I'd like to point out that there are other internal parts of > > MicroPython that can help guide MyNewt MCU support on clocks too, > > without the need for CubeMX. > > > > > > > > Thanks, > > Wayne > > > > On 1 March 2018 at 18:48, Wayne Keenan <wayne.kee...@gmail.com> > > wrote: > >> That's a good point, but also having used CubeMX myself I always > >> thought it is very application specific design time choices. IMHO > >> What MyNewt MCU support would need is 'a level above that'. > >> > >> I've perhaps missed something. > >> > >> But AFAIK the MicroPython CSV files are (easily) parsable > >> representations of what's in the STM32 data sheets for each MCU, > >> so it's minus the bespoke tooling, libraries and generated > >> boilerplate code CubeMX generates. > >> > >> > >> > >> > >> Thanks, > >> Wayne > >> > >> On 1 March 2018 at 17:43, Raoul van Bergen > >> <raoul.van.ber...@me.com> wrote: > >> > >>> Hi, > >>> Just my opinion from long time experience with STM32. > >>> > >>> IF (!) there is anything to be supported for this from external, > >>> it should be the definition files generated by the free CubeMX > >>> tool from STM itself. This tool allows you to first create the > >>> perfect matching pin assignment for your application (it was > >>> already mentioned this can become very complicated) and next it > >>> can generate the complete BSP /HAL support source files based on > >>> the library from STM. > >>> > >>> I know some other vendors have similar tools as well. > >>> > >>> I am not advocating to use ST's own library at all but at least > >>> the include files generated by CubeMX do hold the proper defines > >>> and macros needed to do the pin assignments correctly and this > >>> tool is kept up-to-date for all STM32 processors at all times, so > >>> "your" STM32 of choice will always be there.. > >>> > >>> Regards, > >>> Raoul > >>> > >>> > >>> > >>> -Original Message- > >>> From: Wayne Keenan [mailto:wayne.kee...@gmail.com] > >>> Sent: 01 March 2018 18:24 > >>> To: dev@mynewt.apache.org > >>> Cc: Miguel Azevedo <miguella...@gmail.com> > >>> Subject: Re: recommendations for IO pin declarations > >>> > >>> If you take a look at MicroPython, it has CSV files describing the > >>> Alternate Functions of pins for many STM32 devices. > >>> > >>> Files matching *_af.csv under: https://github.com/ > >>> micropython/micropython/tree/master/ports/stm32/boards > >>> > >>> Perhaps the Mynewt STM32 MCU support could/should import and use > >>> them? > >>> > >>> > >>> Thanks, > >>> Wayne > >>> > >>> On 1 March 2018 at 17:06, markus <mar...@bibi.ca> wrote: > >>> > >>> > I didn't explain this correctly, let me start again. > >>> > >
Re: PWM API, new features should be driver specific or not?
wow - it's an email day for me I like the idea of having a single pointer for the additional values, or changing `data` to a pointer to said structure instead of a `void*` (and move the void* into that structure). Personally I probably would have combined the ISRs into a single callback function and use an additional enumeration parameter to determine the "trigger". This would allow future extensions, say if a counter supports more than one compare value. As for the nrf52 suggestion, what I meant was that the new api is a super-set of the old api. So once you implement a driver with the new api you can easily implement a driver with the old api by creating an interface layer that just sets all extra pointers and values to dummy values. Have fun, Markus PS: about all the many emails - I got the STM32 port to work yesterday so before going further I wanted to clarify the interface, and then you sent out this email - and I didn't want to mix topics, hijack your thread . So if anybody asks, I'll blame you - just so you know ;) On Thu, 1 Mar 2018 01:54:53 -0300 Miguel Azevedo <miguella...@gmail.com> wrote: > Hi again Markus, > > > I think your enhancements should be their own driver. Plain PWM is > > such a basic need and feature that I think the interface for it > > should be as simple as possible. I'm also concerned about the > > memory footprint increase, which is 3x that of the original > > interface (and that's just the data structure). > > Agreed. Although if you re-use the structure it isn't such a dramatic > increase in memory footprint. > Regarding the datastructure size I believe we can keep the previous > interface, without the callback associated fields and the cycle(I > don't love this one either) I suggest we have a specific datastructure > defined on pwm_nrf52.h or even pwm.h(given these are common features > on PWM devices, any driver would be eligible to implement them on a > standardized way). This struct could either be a struct containing a > pwm_chan_cfg which we would 'upcast' and 'downcast' (like we do with > dev and odev) or simply something we pass through the data field. > > > For the nrf52 specifically you could implement the old interface > > driver on top of a driver with the new proposed interface. > I don't understand what you mean by using the old interface but I > think one of the the ways I described will sort out the pwm_chan_cfg > memory footprint problem. > > Thanks for your feedback! :) > > Miguel > > On Wed, Feb 28, 2018 at 9:24 PM, markus <mar...@bibi.ca> wrote: > > Hi Miguel, > > > > I think your enhancements should be their own driver. Plain PWM is > > such a basic need and feature that I think the interface for it > > should be as simple as possible. I'm also concerned about the > > memory footprint increase, which is 3x that of the original > > interface (and that's just the data structure). > > > > For the nrf52 specifically you could implement the old interface > > driver on top of a driver with the new proposed interface. > > > > My 2 cents, > > Markus > > > > > > > > On Wed, 28 Feb 2018 17:51:50 -0300 > > Miguel Azevedo <miguella...@gmail.com> wrote: > > > >> Hi everyone, > >> > >> I recently implemented a few new features for the nRF52 PWM driver > >> and will probably implement them for soft PWM as well. > >> > >> The features: > >> * Interrupts fired every cycle with user handler and parameter > >> data; > >> * A mode where the device plays for n cycles; > >> * Interrupts fired at the end of a sequence of n cycles with user > >> handler and parameter data. > >> > >> These changes are PRed here: > >> https://github.com/apache/mynewt-core/pull/836 > >> > >> There is an example (pwm_test) which uses the also PRed easing > >> library: https://github.com/apache/mynewt-core/pull/822 > >> > >> These features change the pwm_chan_cfg datastructure on pwm.h, > >> wich is general to all drivers. > >> I can argue that these features are implementable on virtually any > >> PWM device since every hardware PWM implementation I've seen so > >> far uses timers and counters, however there might be (and probably > >> are) exceptions. > >> Anyway a driver which doesn't use these new fields on this > >> datastructure is still implementable(well, we have soft PWM using > >> the sabe API interface and it works). > >> > >> The alternative to this would be to write a datastructure on the > >> driver's implementation header file (pwm_nrf52.h in this case) with > >> the new fields. > >> > >> What do you think? > >> > >> Best, > >> > >> Miguel Azevedo > > > > >
Re: Device numbering clarification
Hey Chris, your description matches what I see in the code. While working on the STM32F3 port I was using that port for a sample application to get ppl started on controlling their robots with an Android device. And I noticed that depending on which part I was working on (STM32F3 port, bsp or app) I changed my mind - or better my perspective. What I came up with was this (sticking with the uart example): -) the device name (eg "uart0") belongs to the application. As an application developer, if the board supports at least on serial port it will be named "uart0". If there are 2 serial ports they will be available as "uart0" and "uart1" This is the same as on a desktop or notebook computer, the device numbering starts at "0" and increments with each available device. -) the sycfg name (eg "UART_0") belongs to the BSP - and doesn't necessarily have a relationship to the device of a /similar/ name (aka the same number). The reason I ended up here is because the board I was using has one HW uart connected to the USB bridge. It seems that most (all?) bsps use "UART_0" for this connection - and so did I. When I was at the point to switch from the test setup to use the UART which was connected to the BT module I didn't want to change the application and realised that the BSP can declare multiple devices and one can use syscfg to select the one uart that matches the app - assuming that whichever one of the two uarts is enabled shows up as "uart0". This setup allows the BSP to support a lot of devices/device configurations without any ill consequences on memory footprint and code size (unless all of those device are actually enabled). But again, the numbering should start at 0 and increase by 1 for each additional device. Given the discussion a few weeks ago about moving the device declarations into the mcu, this should probably move there and only leave the device creation depending on the syscfg values in the BSP. Haven't figured out how that should look like though - not there yet. -) the mcu HW peripheral name belongs to the mcu and I don't think there is any value in correlating that to any of the numbers above. For quite a few mcus it wouldn't even be possible because the mcy peripheral numbering starts at `1` whereas all mynewt devices start at `0`. Not the most important topic to think about, I just wanted to make sure I'm not violating some sacred standard. Thanks a bunch, Markus On Wed, 28 Feb 2018 11:36:35 -0800 Christopher Collins <ch...@runtime.io> wrote: > Hi Markus, > > On Mon, Feb 26, 2018 at 11:36:41AM -0800, markus wrote: > > Is there some documentation about the numbers, meanings and > > relationship (if any) of the 3 different device numbers? > > > > -) syscfg, eg UART_0 > > -) device name, eg "uart0" > > -) mcu HW device, eg "USART2" > > The short answer is: unfortunately no, there isn't any documentation > about how devices should be numbered. I think the device numbering > scheme is something that evolved without any concrete plan, so a > conversation might be a good idea. > > For the first two (syscfg and os_dev name): these should always > correspond to the same device. I.e., `UART_0` syscfg settings should > configure the device called "uart0". > > The third item (name that the MCU datasheet assigned to a peripheral) > is not so straightforward. I think there is some tension due to two > conflicting goals: > 1. Make setting names consistent with names in MCU documentation. > 2. Make setting names consistent among all BSPs. > > The second goal seems to have won out over the first. The reason the > second goal is important is that it allows for BSP-agnostic libraries > and apps. For example, a library that requires a UART can be > configured to use a UART number without worrying about whether the MCU > documentation calls the device "UART 0" or "USART 0". > > If you have any thoughts on how this could be improved, please don't > hesitate to share them. The same goes for other readers! > > Chris
Re: clarification about pwm_test
Hey Miguel, thanks for the background that helps a lot. I agree that (if this is the way the pwm api should work) the top value should be explicit. As the return value from pwm_set_frequency would be an option - given its prominence though it would probably make sense to add an API call for it or add it as a member to `struct pwm_dev`. At least that way the dependency between the application and driver implementation gets broken. It would be great if we could nail that down here so I can implement the stm driver correctly the first time ;). The pin-less PWM is more a result of calling the APIs in the wrong order. I couldn't come up with a use case but also wasn't sure if it should be supported. I do have robot though where the h-bridge is a bit hard to control. What I ended up doing was to generate the same PWM in 2 hw-units and depending on state enabled one of the output pins. Good stuff, Markus On Thu, 1 Mar 2018 00:48:36 -0300 Miguel Azevedo <miguella...@gmail.com> wrote: > Hi Markus, > > > According to the doc the duty cycle should be absolutely defined > > between 0 (no output) and 65535 (full output). > Yes, the doc on the PWM API wasn't updated after the first drivers got > implemented, if you take a look at pwm_nrf52 on my latest pull request > on PWM the driver's doc is different. > > > Just to be clear, the way I understand the interface a call like > > > > pwm_enable_duty_cycle(pwm, 0, 0x7FFF); > > > > should always lead to a 50% duty cycle, regardless of what the pwm > > frequency was set to and regardless of what counter frequency is > > internally used by the pwm driver. > > Well, in a general way PWM uses clock division, so in practice you > have a top value, which is clock_freq/pwm_freq and this should be the > 100% duty cycle. > Some versions ago there was a PWM HAL API, I based the current PWM API > on that one, with a few differences which BTW where discussed on this > mailing list. > Why not convert it and always have a 0 - 65535 and not have external > code doing it? > At the time I implemented the pwm_nrf52 and soft_pwm drivers it made > more sense to have the duty cycle fraction value based on the top > value. This is because it would totally respect the resolution and > remove the need to convert from one value range to another each time > we change duty cycle. > If you convert it internally every time you change the duty cycle, > which probably will happen frequently, it won't be as efficient as > calculating a top value once you set the frequency(something which is > likely to happen less frequently). > > > I would appreciate any clarifying comments as to what's going on > > here - or where I'm going wrong. > What happens here is that I forgot to change the documentation, > although the drivers work consistently the way I just described. > Just to be clear here: I understand your concern about the fraction > range and that it is on the older API. > It still makes sense to me to use the real range and calculate the top > value when we set the frequency rather than converting from one value > range to another every time we change the duty cycle, its just the way > PWM works. Probably it would be better to return a top value on the > set_frequency function, this is one of the changes would like to > propose. > > > The second question has to do with the sequence of api calls and at > > what point the PWM is actually started (which is an explicit step > > for STM32s). > > - Is it a safe assumption that an application must call > > pwm_chan_config for a channel before it can call > > pwm_enable_duty_cycle? > Absolutely. As far as we go we need to set a GPIO output before we > fire up a PWM channel. > > > - Is there support for kicking off a PWM channel without > > configuring an output pin? > No, can you give us a use case where that would need happen? > > > Lastly, in some email archive about the original PWM driver thread > > I found a reference to 'hal_pwm' - which I can't even find a header > > for. Did this get removed from the repo? > Yes, it did, here you have it: > https://github.com/apache/mynewt-core/blob/mynewt_0_9_0_tag/hw/hal/include/hal/hal_pwm.h > > Best, > > Miguel > > On Wed, Feb 28, 2018 at 9:53 PM, markus <mar...@bibi.ca> wrote: > > I started implementing a PWM driver for the STM32 processors a few > > days ago and ran into an issue I need clarification. According to > > the doc the duty cycle should be absolutely defined between 0 (no > > output) and 65535 (full output). > > > > However, pwm_test and pwm_nrf52 require the application code to get > > the base frequency, calculate the top value from
recommendations for IO pin declarations
While writing a PWM driver for the STM32s mcu family I came across the issue of assigning output pins for a pwm channel. PWM output in STM32s is done by configuring a pin for "alternate functions" - where specific pins have specific (possible) alternate functions. In other words, only a very limited number of timer:channel:pin combinations are possible, each one requiring a very specific alternate function. `struct pwm_chan_config` only specifies the pin number. I've been using the `data` member to put the burden on the application to specify the "correct" number for the alternate function - but I find this a little unsatisfactory. So I was wondering if somebody has a recommendation, better approach to solving this issue? Have fun, Markus
clarification about pwm_test
I started implementing a PWM driver for the STM32 processors a few days ago and ran into an issue I need clarification. According to the doc the duty cycle should be absolutely defined between 0 (no output) and 65535 (full output). However, pwm_test and pwm_nrf52 require the application code to get the base frequency, calculate the top value from that and then scale the duty cycle accordingly. Just to be clear, the way I understand the interface a call like pwm_enable_duty_cycle(pwm, 0, 0x7FFF); should always lead to a 50% duty cycle, regardless of what the pwm frequency was set to and regardless of what counter frequency is internally used by the pwm driver. I would appreciate any clarifying comments as to what's going on here - or where I'm going wrong. The second question has to do with the sequence of api calls and at what point the PWM is actually started (which is an explicit step for STM32s). - Is it a safe assumption that an application must call pwm_chan_config for a channel before it can call pwm_enable_duty_cycle? - Is there support for kicking off a PWM channel without configuring an output pin? Lastly, in some email archive about the original PWM driver thread I found a reference to 'hal_pwm' - which I can't even find a header for. Did this get removed from the repo? Thanks a lot, Markus
Re: PWM API, new features should be driver specific or not?
Hi Miguel, I think your enhancements should be their own driver. Plain PWM is such a basic need and feature that I think the interface for it should be as simple as possible. I'm also concerned about the memory footprint increase, which is 3x that of the original interface (and that's just the data structure). For the nrf52 specifically you could implement the old interface driver on top of a driver with the new proposed interface. My 2 cents, Markus On Wed, 28 Feb 2018 17:51:50 -0300 Miguel Azevedo <miguella...@gmail.com> wrote: > Hi everyone, > > I recently implemented a few new features for the nRF52 PWM driver and > will probably implement them for soft PWM as well. > > The features: > * Interrupts fired every cycle with user handler and parameter data; > * A mode where the device plays for n cycles; > * Interrupts fired at the end of a sequence of n cycles with user > handler and parameter data. > > These changes are PRed here: > https://github.com/apache/mynewt-core/pull/836 > > There is an example (pwm_test) which uses the also PRed easing > library: https://github.com/apache/mynewt-core/pull/822 > > These features change the pwm_chan_cfg datastructure on pwm.h, wich is > general to all drivers. > I can argue that these features are implementable on virtually any PWM > device since every hardware PWM implementation I've seen so far uses > timers and counters, however there might be (and probably are) > exceptions. > Anyway a driver which doesn't use these new fields on this > datastructure is still implementable(well, we have soft PWM using the > sabe API interface and it works). > > The alternative to this would be to write a datastructure on the > driver's implementation header file (pwm_nrf52.h in this case) with > the new fields. > > What do you think? > > Best, > > Miguel Azevedo
Device numbering clarification
Is there some documentation about the numbers, meanings and relationship (if any) of the 3 different device numbers? -) syscfg, eg UART_0 -) device name, eg "uart0" -) mcu HW device, eg "USART2"
stm32f3 branch - PR now or later?
A few weeks ago I started porting mynewt to the stm32f3 family. I've been using it for quite a while and it seems to work so I thought about opening a PR (see https://github.com/mlampert/mynewt-core/tree/feature/stm32f3) There seems to be a refactoring in progress to eliminate some of the duplication between the different stm32 ports - which I think is a good thing! So I was wondering if I should hold off until that is done? Also, comments on the actual port are most welcome. It diverts from the other stm32 family ports mainly in two areas: * accounting of external interrupts is on a per ISR basis, not on a per HW interrupt basis, see https://github.com/apache/mynewt-core/compare/master...mlampert:feature/stm32f3?expand=1#diff-12c253fbcf44cd336f08b3e2ed4eca8e I found this more useful during debugging than the external HW interrupt counts - YMMV. * The stm32f303k8 is rather resource constrained with 64k flash and 12k sram. I didn't see much value in trying to squeeze a bootloader and two app images in there - so the nucleo-f303k8 bsp doesn't support a bootloader and is set up to load a single app image directly.
Re: HAL API change request
doesn't that imply a guarantee the HAL apparently doesn't make? how about hal_gpio_toggle_basic() hal_gpio_toggle_hw() On Wed, 17 Jan 2018 16:23:51 -0800 will sanfilippo <wi...@runtime.io> wrote: > hal_gpio_toggle_atomic() > > > > On Jan 17, 2018, at 2:50 PM, markus <mar...@bibi.ca> wrote: > > > > any suggestions for a name of the new api? > > > > > > On Wed, 17 Jan 2018 14:41:08 -0800 > > Christopher Collins <ch...@runtime.io> wrote: > > > >> On Wed, Jan 17, 2018 at 02:33:09PM -0800, markus wrote: > >>> I do think there is a write and wrong about toggling a pin. The > >>> reason processors and HALs have an API for toggling a pin is to > >>> make sure that the pin actually gets toggled and do so in the > >>> least amount of processor cycles (precisely because it's such a > >>> common operation). Requiring a return value makes usage of such > >>> support impossible. > >>> > >>> Furthermore, an API call in a low level API such as a hal that is > >>> (required to be) nothing more than a wrapper around two other API > >>> calls of the same API is a waste. > >>> > >>> ppl make mistakes, APIs evolve, at least the ones that stay around > >>> for a while and want to stay relevant. This is a request to make > >>> things right and figuring out the process in how to go about > >>> it. > >> > >> The Mynewt policy for breaking backwards compatibility is > >> documented here: > >> https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy#ReleaseandSupportPolicy-BackwardsCompatibility > >> > >> So, users should be given plenty of heads up before anything > >> changes. I I think Will's idea of adding a new function is a good > >> way to start the process. > >> > >> Chris > >> > >>> > >>> > >>> On Wed, 17 Jan 2018 14:10:24 -0800 > >>> will sanfilippo <wi...@runtime.io> wrote: > >>> > >>>> Markus (and all): > >>>> > >>>> I think there may be some confusion here or misinterpretations. > >>>> > >>>> I think most would agree that there is no absolute requirement > >>>> for a hal_gpio_toggle() API if you can both read and write a > >>>> gpio. The API was added as a helper since toggling a gpio is a > >>>> fairly common construct. > >>>> > >>>> Regarding its being atomic, the HAL API was not necessarily > >>>> designed to be atomic. While some implementations of various HAL > >>>> API might be atomic, there is no guarantee that they are nor was > >>>> there a requirement that there be. This seems reasonable as > >>>> making something atomic on processors that do not provide HW > >>>> support for it require extra code. Consider a piece of firmware > >>>> where only one task toggles a particular GPIO. Making it atomic > >>>> by default would not be necessary. > >>>> > >>>> Addressing the API itself, whether it is void or returns a value, > >>>> is neither right nor wrong in my opinion. Simply because it is > >>>> used in a certain way in the repo does not mean that others are > >>>> not using it. If it is changed it would break existing code which > >>>> is why, in general, API’s are not changed frequently. > >>>> > >>>> It is for the above reasons that I suggested adding a new API. > >>>> This way, you have what you want and there is no breaking of > >>>> existing functionality. > >>>> > >>>> BTW: the fact that certain implementations do not return the > >>>> proper value or are incorrect is definitely an issue. These > >>>> should be addressed in a PR and appropriate modifications made. > >>>> > >>>> > >>>>> On Jan 17, 2018, at 1:48 PM, markus <mar...@bibi.ca> wrote: > >>>>> > >>>>> Hi Vipul, > >>>>> > >>>>>>> The point was to fix a broken API, not to do my own thing ;). > >>>>>>> > >>>>>>> Looking at the history hal_gpio_toggle was correctly declared > >>>>>>> initially and then changed with commit 274da3263 (no rational > >>>>>>> given as to why). > >>>>>> > >>>>>> The change request was sent on the mailing list and there were > >>>>>> no issues at the time from the community. If you take a look at > >>>>>> hw/mcu/nordic/nrf52xxx/src/hal_gpio.c, hal_gpi_toggle() reads > >>>>>> the gpio anyways because it needs to know the state of the > >>>>>> gpio before it toggles it. This read anyways goes waste. If it > >>>>>> is returned, it can be used by the calling code. If you want > >>>>>> to use the read value, you can do so. If you do not want to > >>>>>> use it. You can just ignore the return value. > >>>>> > >>>>> I don't think that crappy implementations of an API are a > >>>>> justification to change the API, they should be a reason to > >>>>> change the implementation. > >>>>>>> hal_gpio_toggle as it is adds no value to API and might as > >>>>>>> well be dropped entirely. > >>>>>> > >>>>>> I do not agree. > >>>>> > >>>>> I've stated my reasons why I think the current declaration is > >>>>> wrong and redundant - could you please explain why you think > >>>>> that's not the case? > >>>>> > >>>>> Thanks, > >>>>> Markus > >>>> > >>> > > >
Re: HAL API change request
any suggestions for a name of the new api? On Wed, 17 Jan 2018 14:41:08 -0800 Christopher Collins <ch...@runtime.io> wrote: > On Wed, Jan 17, 2018 at 02:33:09PM -0800, markus wrote: > > I do think there is a write and wrong about toggling a pin. The > > reason processors and HALs have an API for toggling a pin is to > > make sure that the pin actually gets toggled and do so in the least > > amount of processor cycles (precisely because it's such a common > > operation). Requiring a return value makes usage of such support > > impossible. > > > > Furthermore, an API call in a low level API such as a hal that is > > (required to be) nothing more than a wrapper around two other API > > calls of the same API is a waste. > > > > ppl make mistakes, APIs evolve, at least the ones that stay around > > for a while and want to stay relevant. This is a request to make > > things right and figuring out the process in how to go about it. > > The Mynewt policy for breaking backwards compatibility is documented > here: > https://cwiki.apache.org/confluence/display/MYNEWT/Release+and+Support+Policy#ReleaseandSupportPolicy-BackwardsCompatibility > > So, users should be given plenty of heads up before anything > changes. I I think Will's idea of adding a new function is a good > way to start the process. > > Chris > > > > > > > On Wed, 17 Jan 2018 14:10:24 -0800 > > will sanfilippo <wi...@runtime.io> wrote: > > > > > Markus (and all): > > > > > > I think there may be some confusion here or misinterpretations. > > > > > > I think most would agree that there is no absolute requirement > > > for a hal_gpio_toggle() API if you can both read and write a > > > gpio. The API was added as a helper since toggling a gpio is a > > > fairly common construct. > > > > > > Regarding its being atomic, the HAL API was not necessarily > > > designed to be atomic. While some implementations of various HAL > > > API might be atomic, there is no guarantee that they are nor was > > > there a requirement that there be. This seems reasonable as > > > making something atomic on processors that do not provide HW > > > support for it require extra code. Consider a piece of firmware > > > where only one task toggles a particular GPIO. Making it atomic > > > by default would not be necessary. > > > > > > Addressing the API itself, whether it is void or returns a value, > > > is neither right nor wrong in my opinion. Simply because it is > > > used in a certain way in the repo does not mean that others are > > > not using it. If it is changed it would break existing code which > > > is why, in general, API’s are not changed frequently. > > > > > > It is for the above reasons that I suggested adding a new API. > > > This way, you have what you want and there is no breaking of > > > existing functionality. > > > > > > BTW: the fact that certain implementations do not return the > > > proper value or are incorrect is definitely an issue. These > > > should be addressed in a PR and appropriate modifications made. > > > > > > > > > > On Jan 17, 2018, at 1:48 PM, markus <mar...@bibi.ca> wrote: > > > > > > > > Hi Vipul, > > > > > > > >>> The point was to fix a broken API, not to do my own thing ;). > > > >>> > > > >>> Looking at the history hal_gpio_toggle was correctly declared > > > >>> initially and then changed with commit 274da3263 (no rational > > > >>> given as to why). > > > >> > > > >> The change request was sent on the mailing list and there were > > > >> no issues at the time from the community. If you take a look at > > > >> hw/mcu/nordic/nrf52xxx/src/hal_gpio.c, hal_gpi_toggle() reads > > > >> the gpio anyways because it needs to know the state of the > > > >> gpio before it toggles it. This read anyways goes waste. If it > > > >> is returned, it can be used by the calling code. If you want > > > >> to use the read value, you can do so. If you do not want to > > > >> use it. You can just ignore the return value. > > > > > > > > I don't think that crappy implementations of an API are a > > > > justification to change the API, they should be a reason to > > > > change the implementation. > > > >>> hal_gpio_toggle as it is adds no value to API and might as > > > >>> well be dropped entirely. > > > >> > > > >> I do not agree. > > > > > > > > I've stated my reasons why I think the current declaration is > > > > wrong and redundant - could you please explain why you think > > > > that's not the case? > > > > > > > > Thanks, > > > > Markus > > > > >
Re: HAL API change request
Hi Vipul, > > The point was to fix a broken API, not to do my own thing ;). > > > > Looking at the history hal_gpio_toggle was correctly declared > > initially and then changed with commit 274da3263 (no rational given > > as to why). > > The change request was sent on the mailing list and there were no > issues at the time from the community. If you take a look at > hw/mcu/nordic/nrf52xxx/src/hal_gpio.c, hal_gpi_toggle() reads the > gpio anyways because it needs to know the state of the gpio before it > toggles it. This read anyways goes waste. If it is returned, it can > be used by the calling code. If you want to use the read value, you > can do so. If you do not want to use it. You can just ignore the > return value. I don't think that crappy implementations of an API are a justification to change the API, they should be a reason to change the implementation. > > hal_gpio_toggle as it is adds no value to API and might as well be > > dropped entirely. > > I do not agree. I've stated my reasons why I think the current declaration is wrong and redundant - could you please explain why you think that's not the case? Thanks, Markus
Re: HAL API change request
Sorry about the late response - I fell ill. The point was to fix a broken API, not to do my own thing ;). Looking at the history hal_gpio_toggle was correctly declared initially and then changed with commit 274da3263 (no rational given as to why). Looking at the current implementations (11): - 2 use the HW toggle and just return 0 - 7 perform a read-write cycle, none is atomic or interrupt safe - 2 perform a write-read cycle, also not atomic or interrupt safe The only apps (in the repo) using the return value are slinky and it's copy sisters, which isn't required because they are reading the pin beforehand anyway. hal_gpio_toggle as it is adds no value to API and might as well be dropped entirely. On Sun, 14 Jan 2018 18:11:56 -0800 will sanfilippo <wi...@runtime.io> wrote: > Personally I am not sure of the “official” way to get an API changed > but possibly another way to go about this is to add a new API that > does what you describe. This way existing functionality is not > changed. > > > On Jan 12, 2018, at 11:29 AM, markus <mar...@bibi.ca> wrote: > > > > I've been looking at hal_gpio_toggle and it's declaration could be > > improved by removing the return value: > > > > void hal_gpio_toggle(int pin); > > > > As it currently stands, by requiring a return value of the pin > > state one cannot use the HW support of most processors to toggle > > the pin, and it's also not possible to accomplish in an atomic > > manner. > > > > If the underlying HW support for toggling a pin cannot be used it > > makes the API call redundant, it can be accomplished by a > > hal_gpio_read/hal_gpio_write combo. > > > > Is there a chance the API can be changed? And how do we go about > > that? > > > > Markus >
HAL API change request
I've been looking at hal_gpio_toggle and it's declaration could be improved by removing the return value: void hal_gpio_toggle(int pin); As it currently stands, by requiring a return value of the pin state one cannot use the HW support of most processors to toggle the pin, and it's also not possible to accomplish in an atomic manner. If the underlying HW support for toggling a pin cannot be used it makes the API call redundant, it can be accomplished by a hal_gpio_read/hal_gpio_write combo. Is there a chance the API can be changed? And how do we go about that? Markus
stm32f3 support
I've tried to use the mynewt_stm32f3 package with little success. It seems to be so out of date that I'm wondering if it's even worth trying to fix it or if I should rather start over following the porting guides on web site? Any guidance appreciated, Markus
