vel;
^~~~
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 upd
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
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
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
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
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
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
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
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:5
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:
> >
M reserved for
application code?
Have fun,
Markus
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 ;)
> >
> >
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
rary ...
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
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
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 & Pau
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
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
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 fo
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
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
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 P
er 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
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
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 im
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"
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
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 &
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
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
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
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
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
33 matches
Mail list logo
