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

Re: JSON Encoding and Decoding

Hi Mynewt Team, I have been trying to decode JSON using the provided json decoding library. This particular library seems quite similar to mJSON, however there are difference regarding json_read_object etc. Also unlike mJSON, there is a requirement to write few more methods :- char

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

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

Re: recommendations for IO pin declarations

Hi markus, > `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. That sounds a lot driver/hw specific. Can you

Re: PWM API, new features should be driver specific or not?

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

Re: clarification about pwm_test

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

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

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

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

PWM API, new features should be driver specific or not?

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

Re: Device numbering clarification

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

Re: JSON Encoding and Decoding

I have been trying to use the same example as is; assuming that apache was also utilizing mJSON. However, it seems there are quite some differences from that library. For e.g. .addr.integer = PRN is no longer valid. It is now .arr.integers.store = PRN And json_read_object requires a struct

Re: JSON Encoding and Decoding

Hi Aditya, On Wed, Feb 28, 2018 at 06:35:04PM +0530, Aditya Xavier wrote: > Thanks got Encoding working for the required JSON. > > Any pointers on how to get the decoding working ? > > From the example >

Re: JSON Encoding and Decoding

Thanks got Encoding working for the required JSON. Any pointers on how to get the decoding working ? From the example https://github.com/apache/mynewt-core/blob/master/encoding/json/test/src/testcases/json_simple_decode.c

Re: JSON Encoding and Decoding

> On Feb 28, 2018, at 10:10 AM, Aditya Xavier wrote: > > Yes, that was derp from my end. > > Any clue on how to encode the JSON structure I mentioned ? > > Is this method correct ? You need to initialize the encoder; it needs to be told where to write the encoded data.

Re: JSON Encoding and Decoding

Yes, that was derp from my end. Any clue on how to encode the JSON structure I mentioned ? Is this method correct ? struct json_encoder *encoder, *module; struct json_value data; memset(, 0, sizeof(encoder)); memset(, 0, sizeof(module));