Date   

Re: [RFC]DMA API Update

Tomasz Bursztyka
 

Hi Baohong,

Very little comment on struct attributes.

Hi everyone,

Based on the feedbacks, I updated the RFC.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --enable/disable source gather
* dest_scatter_en [ 1 ] --enable/disable destination scatter
* source_inc_en [ 2 ] --enable/disable source address increment
* dest_inc_en [ 3 ] --enable/disable destination address increment
* source_reload_en [ 4 ] --reload source address at the end of block transfer
* dest_reload_en [ 5 ] --reload destination address at the end of block transfer
* fifo_mode_control [ 6 : 9 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 10 ] --source request is served when data available or
* wait until destination request happens.
* RESERVED [ 11 : 31 ]
Is there a need of that much reserved space? I am asking this because
maybe we could shrink some attributes to 16bits
like config (it would still give 5 bits left for reserved usage)

* source_address is block starting address at source
* source_gather_count is the continuous transfer count between gather boundaries
* source_gather_interval is the address adjustment at gather boundary
These 2 ones above for instance, is this necessary to put them on 32 bits?

* dest_address is block starting address at destination
* dest_scatter_count is the continuous transfer count between scatter boundaries
* dest_scatter_interval is the address adjustment at scatter boundary
Same here.

* block_size is the number of bytes to be transferred for this block.
*/
struct dma_block_config {
uint32_t config;
uint32_t source_address;
uint32_t source_gather_count;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_count;
uint32_t dest_scatter_interval;
uint32_t block_size;
struct dma_block_config *next_block;
}
I am also wondering how will we be able to use DMA efficiently in device
drivers.
They can't really use direct dma features. We will need something nicely
made, generic as possible, for
sg dma buffers, etc...

Tomasz


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 11:35 AM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:


That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus
Ah, that fixes things.

Now to the question about how uint32_t should be defined ;)

- k
I'm not seeing a problem here. When you print uint32_t, you use PRIu32. This goes for all the fixed-size types, its why inttypes.h exists.
Newlib and minimal libc both have their own inttypes.h which are defined properly for that C library.

Andrew
As Anas said, I don’t think we can expect 3rd party software to utilize PRIu32. The fact that newlib and minimal libc different in the way the typedef (u)int32_t seems like a pointless difference for us to maintain and have to deal with a lot of pain if one switches between them.

For example, trying building by setting CONFIG_NEWLIB_LIBC=y in tests/include/test.config and see how much breaks.

- k


[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

Based on the feedbacks, I updated the RFC.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --enable/disable source gather
* dest_scatter_en [ 1 ] --enable/disable destination scatter
* source_inc_en [ 2 ] --enable/disable source address increment
* dest_inc_en [ 3 ] --enable/disable destination address increment
* source_reload_en [ 4 ] --reload source address at the end of block transfer
* dest_reload_en [ 5 ] --reload destination address at the end of block transfer
* fifo_mode_control [ 6 : 9 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 10 ] --source request is served when data available or
* wait until destination request happens.
* RESERVED [ 11 : 31 ]
* source_address is block starting address at source
* source_gather_count is the continuous transfer count between gather boundaries
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_count is the continuous transfer count between scatter boundaries
* dest_scatter_interval is the address adjustment at scatter boundary
* block_size is the number of bytes to be transferred for this block.
*/
struct dma_block_config {
uint32_t config;
uint32_t source_address;
uint32_t source_gather_count;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_count;
uint32_t dest_scatter_interval;
uint32_t block_size;
struct dma_block_config *next_block;
}

/**
* @brief DMA channel configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* channel_direction [ 6 : 8 ] --0-memory to memory, 1-memory to peripheral,
* 2-peripheral to memory ...
* complete_int_en [ 9 ] --completion interrupt enable
* block_int_en [ 10 ] --block completion interrupt enable
* source_int_en [ 11 ] --source completion interrupt enable
* dest_int_en [ 12 ] --destination completion interrupt enable
* error_int_en [ 13 ] --error interrupt enable
* source_handshake [ 14 ] --HW or SW
* dest_handshake [ 15 ] --HW or SW
* channel_priority [ 16 : 19 ] --DMA channel priority
* source_chaining_en [ 20 ] --enable/disable source block chaining
* dest_chaining_en [ 21 ] --enable/disable destination block chaining
* RESERVED [ 22 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data units
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *head_block;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

Remove struct dma_transfer_config

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_channel_config(struct device *dev, uint32_t channel,
struct dma_channel_config *config)
{
}

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_transfer_start(struct device *dev, uint32_t channel)
{
}

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_transfer_stop(struct device *dev, uint32_t channel)
{
}

Remove API interface dma_transfer_config().

Suggestions and comments are welcome.

-----Original Message-----
From: Liu, Baohong
Sent: Tuesday, January 17, 2017 4:52 PM
To: 'devel(a)lists.zephyrproject.org' <devel(a)lists.zephyrproject.org>
Subject: [RFC]DMA API Update


Hi everyone,

Based on the feedbacks, I updated the RFC.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --enable/disable source gather
* dest_scatter_en [ 1 ] --enable/disable destination scatter
* source_inc_en [ 2 ] --enable/disable source address
increment
* dest_inc_en [ 3 ] --enable/disable destination
address increment
* source_reload_en [ 4 ] --reload source address at the end
of block transfer
* dest_reload_en [ 5 ] --reload destination address at the
end of block transfer
* fifo_mode_control [ 6 : 9 ] --How full of the fifo before
transfer start. HW specific.
* flow_control_mode [ 10 ] --source request is served when
data available or
* wait until destination request
happens.
* RESERVED [ 11 : 31 ]
* source_address is block starting address at source
* source_gather_count is the continuous transfer count between gather
boundaries
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_count is the continuous transfer count between scatter
boundaries
* dest_scatter_interval is the address adjustment at scatter boundary
* block_size is the number of bytes to be transferred for this block.
*/
struct dma_block_config {
uint32_t config;
uint32_t source_address;
uint32_t source_gather_count;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_count;
uint32_t dest_scatter_interval;
uint32_t block_size;
struct dma_block_config *next_block;
}

/**
* @brief DMA channel configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory ...
* complete_int_en [ 10 ] --completion interrupt enable
* block_int_en [ 11 ] --block completion interrupt
enable
* source_int_en [ 12 ] --source completion interrupt
enable
* dest_int_en [ 13 ] --destination completion interrupt
enable
* error_int_en [ 14 ] --error interrupt enable
* source_handshake [ 15 ] --HW or SW
* dest_handshake [ 16 ] --HW or SW
* channel_priority [ 17 : 20 ] --DMA channel priority
* source_chaining_en [ 21 ] --enable/disable source block
chaining
* dest_chaining_en [ 22 ] --enable/disable destination block
chaining
* RESERVED [ 23 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data
units
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *block_head;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

Remove struct dma_transfer_config

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for
the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_channel_config(struct device *dev, uint32_t channel,
struct dma_channel_config *config) { }

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer
will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_transfer_start(struct device *dev, uint32_t channel) { }

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer
was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_transfer_stop(struct device *dev, uint32_t channel) { }

Remove API interface dma_transfer_config().

Suggestions and comments are welcome.


Re: [RFC]DMA API Update

Liu, Baohong
 

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Thursday, January 19, 2017 3:06 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]DMA API Update

On Wed, 2017-01-18 at 23:15 +0000, Liu, Baohong wrote:
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

That still leaves the question as to who calls dma_channel_config
and how the parameters for that get into the system. Is each driver
that implements DMA support going to have a bunch of KConfig entries
to dma_slot, hankshake_polarity etc? Or will the SoC have a bunch of
Just to clarify.

The driver that implements DMA support (e.g. SPI driver) will need to determine
where it needs to get the parameters values for calling the DMA API. This is
beyond the scope of this RFC.

#defines (like we currently have for IRQ numbers) for setting these
DMA attributes (assuming they are fixed in hardware).
The DMA driver should have configuration entries for setting these
parameters and the values of these configurations should be determined
and set by an app level prj.conf, not by the SPI or DMA driver
So, when I add DMA support to my uart, everyone project that uses a UART,
or device attached through a UART, needs know the magic device specific
configuration required and add it their prj.conf?

E.g, to run the Zephyr UART tests I edit tests/drivers/uart/prj.conf to add the
DMA slot, handshaking polarity, etc., that are used for the UART + DMA
driver combination on the device I'm interested in?

Does prj.conf support #includes? That way we could at least provide an
include files per SoC for people to include to get all this config. Then again, if
we did that, why not just add the config direct to the SoC defconfig? Or even
better, just add it to SoC headers files like IRQ assignments and device
addresses? At least that way this SoC specific knowledge is more together in
one place. Currently it's spread between SoC and board files, and leaking into
device drivers, and now starting to push some of it into project files as well
seems like completely the wrong direction to take.

--
Tixy


Re: [USB] composite device

Joseph, Jithu
 

By composite device I think you are referring to USB device configurations which support multiple interfaces.

I took a quick look of the USB stack, and it seems that presently we support single interface configurations only.

Few things I found missing are:
-> provisions to specify class handlers for multiple interfaces
-> switching class handlers based on the directed interface of incoming requests
Those are probable areas you can look at if you are interested.

More analysis is required to gauge the effort involved in making the stack multiple interface aware .

Thanks
Jithu

-----Original Message-----
From: Alexey Belyaev [mailto:BeliaevAV(a)gmail.com]
Sent: Thursday, January 19, 2017 1:49 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [USB] composite device

Hello, is anybody tried to realize composite USB-device? Any hints?
Examples?
Thank you.


Re: [RFC]DMA API Update

Liu, Baohong
 

-----Original Message-----
From: Tseng, Kuo-Lang
Sent: Wednesday, January 18, 2017 3:06 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; 'devel(a)lists.zephyrproject.org'
<devel(a)lists.zephyrproject.org>
Subject: RE: [RFC]DMA API Update

Baohong,

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 17, 2017 4:52 PM


Hi everyone,

Based on the feedbacks, I updated the RFC.
[...]

/**
* @brief DMA channel configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW
specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to
peripheral,
* 2-peripheral to memory ...
* complete_int_en [ 10 ] --completion interrupt enable
* block_int_en [ 11 ] --block completion interrupt
enable
* source_int_en [ 12 ] --source completion interrupt
enable
* dest_int_en [ 13 ] --destination completion interrupt
enable
* error_int_en [ 14 ] --error interrupt enable
* source_handshake [ 15 ] --HW or SW
* dest_handshake [ 16 ] --HW or SW
I thought the original idea (from ZEP-873) was to minimize the
dma_channel_config structure by removing SoC or driver specific entries like
the handshake interface above which may not be common in other DMA
engines. IMO, those should be kept inside the driver and not to be exposed
in API.
Probably, you was talking about handshake_polarity. I will remove it. By the way,
The elimination will not save any memory usage.

handshake_interface which is having a new name "dma_slot" can't be removed.
All the SoCs I have reviewed so far have this feature.


Kuo


Re: Suggestions for getting started

Abhinav Misra
 

Hi Kumar,

I have STM32F407VG board.
Interest in developing the drivers.But can start with anything.
Worked on i2c and spi drivers.Developed code for userspace drivers for both.
Currently working on bluetooth. Implemented few profiles using some vendor
stack.

Any kind of related stuff would be fine.

Regards,
Abhinav
.

On Thu, Jan 19, 2017 at 9:12 AM, Kumar Gala <kumar.gala(a)linaro.org> wrote:


On Jan 18, 2017, at 12:29 PM, Abhinav Misra <abhitheextremeeng(a)gmail.com>
wrote:

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the
documentation and other starters stuffs as being new to open source
development.

I want to contribute to the project.Please suggest me some ways how to
get started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav
Which STM32 discovery board do you have, this is possibly the best
starting point to try and get zephyr up and running.

What kinda of work or code have you developed in the past? Any particular
area of interest?

- k


Re: uint32_t typedef differences causes issues

Boie, Andrew P
 

That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus
Ah, that fixes things.

Now to the question about how uint32_t should be defined ;)

- k
I'm not seeing a problem here. When you print uint32_t, you use PRIu32. This goes for all the fixed-size types, its why inttypes.h exists.
Newlib and minimal libc both have their own inttypes.h which are defined properly for that C library.

Andrew


Re: git describe of v1.5.0-3830-gecd209f

David Brown
 

On Thu, Jan 19, 2017 at 11:17:21AM -0500, Anas Nashif wrote:
On Tue, Jan 17, 2017 at 11:58 AM, Paul Sokolovsky
I see, apparently, we used a local release branch based on
v1.6.0-branch, that's why I saw "v1.6.0-27-gb6fb798" previously.
> I know git describe won’t work with this model, we need to find an
> alternative way. Probably when we change the version to 1.x.99, we
> could tag master so we can get something like:
v1.6.99-1772-g003a46a

Yes, that would be nice. I'm just afraid that makes the release
process
more and more complicated, but I guess as Zephyr grows, it would
become
such anyway.

It is just a tag we will put on master the minute we create the
release branch basically.
Should we merge the release branch back into master after the release
is made? This would make describe work again, and should we really be
having changes on the release branch that don't get brought in?

David


Re: Any plan for OTA support?

David Brown
 

No decision has been made, but I'm certainly going to be investigating
Mynewt's serial protocol.

The intent is that the bootloader won't be upgradeable. Ideally, it should
be protected so that even debug pins won't be able to update it. Without it
being protected, there really isn't any security to the rest of the boot
process.

David

On Thu, Jan 19, 2017 at 5:46 AM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

Hi David,



If I’m not mistaken the Mynewt bootloader includes support for serial
“DFU” (more like app image management and transfer). Are you planning to
port that as well as part of the mcuboot project? The reason I ask is that
there have been some conversations regarding the future protocol that will
be used to provide DFU over the different transports (serial, USB, BLE,
15.4, etc) and it would be good to know if you have taken any sort of
decision in this regard.

If I’m not mistaken the serial code in the Mynewt bootloader uses parts of
what’s called the Newt management protocol currently, so it’d be
interesting to know if you plan to incorporate that into the project.

Also could you confirm that the mcuboot image will only be able to be
overwritten using debug pins? (i.e. no DFU, OTA or otherwise of the
bootloader itself).



Thanks,



Carles



*From:* David Brown [mailto:david.brown(a)linaro.org]
*Sent:* Wednesday, January 18, 2017 19:32
*To:* Cufi, Carles <Carles.Cufi(a)nordicsemi.no>; nvl1109(a)gmail.com;
devel(a)lists.zephyrproject.org
*Subject:* Re: [devel] Re: Any plan for OTA support?



We are working on the Mynewt bootloader (which is going to be its own
project, called mcuboot). I have the OTA update as something that needs to
be done, but I'm not aware of currently plans to implement anything.



David



On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

Hi Linh,



I was actually asking myself the same question recently. I think Linaro
has started working on making the Mynewt bootloader usable with Zephyr, but
that is only the first step I assume.



Also, to add a bit to your question, are there plans for IP-based OTA
only, or is “regular” BLE OTA support also planned? By regular I mean
similar to the proprietary solutions that vendors offer today, where one
can update the firmware using only GATT, without requiring IPSP or LE
Connection-Oriented Channels.



Thanks,



Carles



*From:* nvl1109(a)gmail.com [mailto:nvl1109(a)gmail.com]
*Sent:* Saturday, January 14, 2017 15:43
*To:* devel(a)lists.zephyrproject.org <devel(a)lists.zephyrproject.org>
*Subject:* [devel] Any plan for OTA support?



Hi all,



Do you have any plans to support OTA framework on Zephyr?



Thank & Regards,
Linh Nguyen




Re: uint32_t typedef differences causes issues

Oliver Hahm <oliver.hahm@...>
 

Hi!

Generally I'm a big fan of doing things correctly & properly, but this
stuff just uglifies the format strings too much IMO :)
Unless you don't want to exclude the possibility to run Zephyr on 8-bit and
16-bit architectures.

Cheers,
Oleg


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Anas,

On Thu, Jan 19, 2017, Anas Nashif wrote:
On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.
I'd just like to add to this that while working with Linux and BlueZ
we've used %u extensively for uint8_t, uint16_t and uint32_t without any
issues (I'd think those projects have been run on a larger set of
architectures and C libraries than what Zephyr supports). The only case
where we've had resort to PRI* is uint64_t, and if you check the actual
definition of these in your /usr/include/inttypes.h you'll see that it's
the only one that evaluates to something else than just "u".

Generally I'm a big fan of doing things correctly & properly, but this
stuff just uglifies the format strings too much IMO :)

Johan


Re: git describe of v1.5.0-3830-gecd209f

Anas Nashif
 

On Tue, Jan 17, 2017 at 11:58 AM, Paul Sokolovsky <
paul.sokolovsky(a)linaro.org> wrote:

Hello Anas,

On Tue, 17 Jan 2017 16:34:15 +0000
"Nashif, Anas" <anas.nashif(a)intel.com> wrote:

<snip>


I see, apparently, we used a local release branch based on
v1.6.0-branch, that's why I saw "v1.6.0-27-gb6fb798" previously.

I know git describe won’t work with this model, we need to find an
alternative way. Probably when we change the version to 1.x.99, we
could tag master so we can get something like: v1.6.99-1772-g003a46a
Yes, that would be nice. I'm just afraid that makes the release process
more and more complicated, but I guess as Zephyr grows, it would become
such anyway.

It is just a tag we will put on master the minute we create the release
branch basically.

Anas



Anas
Thanks for the reply!

--
Best Regards,
Paul

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


Re: SSH on Galileo

Anas Nashif
 

On Wed, Jan 18, 2017 at 5:34 PM, Fábio Iaione <fabio.iaione(a)gmail.com>
wrote:

Dear Sirs,
Does Zephyr have SSH support?
No. Zephyr does not support SSH.

Anas




Thank you.


Re: [RFC] STM32 pinmux - simplify pinmux logic

Erwan Gouriou
 

Hi Christer,


The above pin definition would look like this:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX (STM32F4X_PIN_FUNC_AF |
STM32F4X_PIN_PULL_UP | STM32_PINMUX_FUNC_ALT_7)

It's a bit more verbose, but it's obvious what it does, especially if
you look at the corresponding definitions in the data sheet since this
is how the hardware registers look.
I agree this might be clearer for users. Since pinmux is something users
might
have to play with, the easier to read, the better.


If we do this we can rip out stm32_get_pin_config completely and also
simplify the __func_to_foo functions in soc_gpio.c

It might also be a good idea to unify these defines between STM32
families. If I recall correctly many STM32F1xx, STM32F2xx and STMF4xx
packages are mostly pin compatible. The same PCB could have a STM32Fxx
or STM32F4xx MCU mounted on it (with a zero ohm resistor or capacitor to
account for any differences between them) and it would be nice if they
could use the same board file.
I can only agree here. It will help a lot on maintenance and porting of new
families.
There could be unexpected differences between quite similar boards, but
these could
be handled easily.


Some functions might not be supported on all families, for example, I
don't think the STM32F1xx can have a pull-up/pull-down at the same tie
as a pin is an output or alternate function, but that shouldn't be problem.

Btw, I think that you could submit your RFC as a patch in Gerrit, so we
can
better appreciate the differences and comment easily.
I'll see if I can clean up my ideas and push a few patches for review in
gerrit.

Thanks a lot for your contribution!

/Christer


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 January 2017 at 15:39, Anas Nashif <nashif(a)gmail.com> wrote:


On Thu, Jan 19, 2017 at 10:03 AM, Johan Hedberg <johan.hedberg(a)intel.com>
wrote:

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.
We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.
We will likely find either immediately, or with future additions to
/ext that each blob of third party code does something different:
- Some will use %u for uint32_t
- Some will use %lu for uint32_t
- Some might even actually use the inttypes.h defs.
- Some will have hacked the problem already with stuff like "%lu",
(long int) some_uint32_variable
...

Clearly we can't appease the first two simultaneously by futzing with
newlib, gcc etc

If we want to get diagnostic clean from the compiler we may end up
needing to explicitly disable -Wformat on /ext

Cheers
/Marcus


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 4
[ZEP-1597] no good way to include library code outside of $(PROJECT_BASE)
https://jira.zephyrproject.org/browse/ZEP-1597

[ZEP-1594] 0.9.0 IAMCU compiler doesn't support __attribute__((interrupt)) on x86
https://jira.zephyrproject.org/browse/ZEP-1594

[ZEP-1595] arch-specific inline functions cannot manipulate _kernel
https://jira.zephyrproject.org/browse/ZEP-1595

[ZEP-1591] wiki: add Networking section and point https://wiki.zephyrproject.org/view/Network_Interfaces
https://jira.zephyrproject.org/browse/ZEP-1591


UPDATED JIRA items within last 24 hours: 6
[ZEP-1474] BLE Connection Parameter Request/Response Processing
https://jira.zephyrproject.org/browse/ZEP-1474

[ZEP-1038] Hard real-time interrupt support
https://jira.zephyrproject.org/browse/ZEP-1038

[ZEP-1251] Abstract driver re-entrancy code
https://jira.zephyrproject.org/browse/ZEP-1251

[ZEP-513] extern declarations of small microkernel objects in designated sections require __attribute__((section)) in gp-enabled systems
https://jira.zephyrproject.org/browse/ZEP-513

[ZEP-723] Sanity Crashes with "FileNotFound" exception when running samples/static_lib/test
https://jira.zephyrproject.org/browse/ZEP-723

[ZEP-1460] Sanity check reports some qemu step failures as 'build_error'
https://jira.zephyrproject.org/browse/ZEP-1460


CLOSED JIRA items within last 24 hours: 3
[ZEP-1428] (Won't Do) support ARC V1
https://jira.zephyrproject.org/browse/ZEP-1428

[ZEP-1564] (Done) 6lo uncompress_IPHC_header overwrites IPHC fields
https://jira.zephyrproject.org/browse/ZEP-1564

[ZEP-1584] (Cannot Reproduce) Fail to connect IPSP node on Arduino101
https://jira.zephyrproject.org/browse/ZEP-1584


RESOLVED JIRA items within last 24 hours: 0


Re: uint32_t typedef differences causes issues

Anas Nashif
 

On Thu, Jan 19, 2017 at 10:03 AM, Johan Hedberg <johan.hedberg(a)intel.com>
wrote:

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.


Anas





Johan


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 9:15 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:

#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus
Ah, that fixes things.

Now to the question about how uint32_t should be defined ;)

- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

That would be my fault, my example above is missing:

#include <inttypes.h>

Cheers
/Marcus

5821 - 5840 of 8118