Date   

Re: DMA driver API, source_burst_length, dest_burst_length

Johann Fischer
 

Hi Baohong,

What are the data units? octets?
This is HW related. It can't specified here in the generic API.

Burst length should be used together with transfer width. Let me give an example.

For a single DMA data transfer, the source can only send data out at 2 bytes each transfer and the destination can only accept data at one byte each transfer (this is HW related.). The DMA engine will get 2 bytes from the source and sends the data to the destination one byte each time (do this twice). For this case, the DMA burst length will be 2 bytes long, since this is the minimum data unit the source side can deal with. So,
source_burst_length = 1
source_transfer_width = 2
dest_burst_length = 2
dest_transfer_width = 1
thanks for the clarification. I suppose:
source_transfer_width should be source_data_size ?
dest_transfer_width should be dest_data_size ?

It is a little redundant, what is the reason for two burst length variables? You can also pass the number of bytes per request and then calculate the burst length in the driver, if necessary.


Note: 1 or 2 in the above is absolute value. Since in the API, the enum starts from 0, 1 or 2 should be changed to 0 or 1.
Do you mean "enum dma_burst_length"? No driver seems to use it.

I would be glad if you would find time to review PR[1] and the fix for test_chan_blen_transfer (15757e1).

[1] https://github.com/zephyrproject-rtos/zephyr/pull/393

--
Best Regards,
Johann Fischer


Re: RFC on STM32 Ethernet driver

Erwin Rol
 

Hey Neil,

Thanks, somehow just didn't think about that. Will rewrite the eth
driver to use the CONTAINER_OF() construct.

BTW is that i2c driver going to be included in mainline? :-)

- Erwin

On 9-6-2017 13:25, Neil Armstrong wrote:
Hi Erwin,

You can use CONTAINER_OF() to get the parent structure like
https://github.com/superna9999/zephyr/blob/stm32f4_i2c/drivers/i2c/i2c_stm32.c#L93

Neil

On 06/09/2017 12:22 PM, Erwin Rol wrote:
Hey Erwan,

like you say some things are subjective when it comes to HAL's, but
somethings really bother me with the STM32 HAL.

The most important is how to deal with IRQ's. In Zephyr I have to setup
the ISR like this;

IRQ_CONNECT(ETH_IRQn, CONFIG_ETH_STM32_IRQ_PRI, eth_isr,
DEVICE_GET(eth0_stm32), 0);
irq_enable(ETH_IRQn);

Now the eth_isr will be called on IRQ. But to use everything from the
HAL we must call the;

void HAL_ETH_IRQHandler(ETH_HandleTypeDef *heth)

That function will than call;

__weak void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)

But as you can see we register a ISR to take a "struct eth0_stm32*" but
all the HAL functions only have "ETH_HandleTypeDef *heth" arguments.

So our driver ISR somehow needs something to go from ETH_HandleTypeDef
*heth to struct eth0_stm32*. The other way around is simple, the
eth0_stm32 struct just has a ETH_HandleTypeDef member.

I solved this to copy the HAL_ETH_IRQHandler handler to my driver and
change it to take my eth0_stm32 struct as argument.

But I really don't like the idea to use half the HAL and copy the other
half.

Would there be a better solution?

BTW: this applies to pretty much everything the uses STM32 IRQ's. I
already noticed the the UART does not use the HAL, but that would have
had the same problem.

It would have been nice if those ETH_HandleTypeDef structures had a
void* user_data member.

That directly brings me to the next point, how are things managed with
upstream (ST) if Zephyr finds problems/bugs in the HAL? Bugs they
probably would not mind to fix, but how to deal with things that are
Zephyr specific, will that mean the Zephyr STM32 HAL will diverge from
the official ST HAL ?

- Erwin

On 6-6-2017 11:19, Erwan Gouriou wrote:
Hi Erwin,


Thanks for proposing this driver, I think it will interest a lot of people.

About your last point, let me mention ST view on this:

This is a question of trade-off. Using HAL has some drawbacks (some might
be objectives like footprint or more subjective like CamelCase), but it's
definitely possible in Zephyr.
Main interest is that it will help having a reliable driver working on
all STM32
SoCs supporting ethernet (today in zephyr: stm32f407, stm32f429, stm32f469,
stm32f7xx under review) faster. More supported SoCs also means more
interested people, which will help in getting the driver mature.
In the end, it should save time to work on end applications rather than
porting.

A native driver, specific to the IP (which might also be used on other
SoCs),
might be more optimized, but this might also take you some time before
having it mature for complex IPs such as ethernet (or USB..).

In any case, I think it would be great to have your driver upstreamed in
a first time. Then, time will tell if a native driver is nice to have or
required.

Erwan



On 3 June 2017 at 15:17, Erwin Rol <mailinglists@...
<mailto:mailinglists@...>> wrote:

Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
<https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54>
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


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

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


Re: RFC on STM32 Ethernet driver

Neil Armstrong
 

Hi Erwin,

You can use CONTAINER_OF() to get the parent structure like
https://github.com/superna9999/zephyr/blob/stm32f4_i2c/drivers/i2c/i2c_stm32.c#L93

Neil

On 06/09/2017 12:22 PM, Erwin Rol wrote:
Hey Erwan,

like you say some things are subjective when it comes to HAL's, but
somethings really bother me with the STM32 HAL.

The most important is how to deal with IRQ's. In Zephyr I have to setup
the ISR like this;

IRQ_CONNECT(ETH_IRQn, CONFIG_ETH_STM32_IRQ_PRI, eth_isr,
DEVICE_GET(eth0_stm32), 0);
irq_enable(ETH_IRQn);

Now the eth_isr will be called on IRQ. But to use everything from the
HAL we must call the;

void HAL_ETH_IRQHandler(ETH_HandleTypeDef *heth)

That function will than call;

__weak void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)

But as you can see we register a ISR to take a "struct eth0_stm32*" but
all the HAL functions only have "ETH_HandleTypeDef *heth" arguments.

So our driver ISR somehow needs something to go from ETH_HandleTypeDef
*heth to struct eth0_stm32*. The other way around is simple, the
eth0_stm32 struct just has a ETH_HandleTypeDef member.

I solved this to copy the HAL_ETH_IRQHandler handler to my driver and
change it to take my eth0_stm32 struct as argument.

But I really don't like the idea to use half the HAL and copy the other
half.

Would there be a better solution?

BTW: this applies to pretty much everything the uses STM32 IRQ's. I
already noticed the the UART does not use the HAL, but that would have
had the same problem.

It would have been nice if those ETH_HandleTypeDef structures had a
void* user_data member.

That directly brings me to the next point, how are things managed with
upstream (ST) if Zephyr finds problems/bugs in the HAL? Bugs they
probably would not mind to fix, but how to deal with things that are
Zephyr specific, will that mean the Zephyr STM32 HAL will diverge from
the official ST HAL ?

- Erwin

On 6-6-2017 11:19, Erwan Gouriou wrote:
Hi Erwin,


Thanks for proposing this driver, I think it will interest a lot of people.

About your last point, let me mention ST view on this:

This is a question of trade-off. Using HAL has some drawbacks (some might
be objectives like footprint or more subjective like CamelCase), but it's
definitely possible in Zephyr.
Main interest is that it will help having a reliable driver working on
all STM32
SoCs supporting ethernet (today in zephyr: stm32f407, stm32f429, stm32f469,
stm32f7xx under review) faster. More supported SoCs also means more
interested people, which will help in getting the driver mature.
In the end, it should save time to work on end applications rather than
porting.

A native driver, specific to the IP (which might also be used on other
SoCs),
might be more optimized, but this might also take you some time before
having it mature for complex IPs such as ethernet (or USB..).

In any case, I think it would be great to have your driver upstreamed in
a first time. Then, time will tell if a native driver is nice to have or
required.

Erwan



On 3 June 2017 at 15:17, Erwin Rol <mailinglists@...
<mailto:mailinglists@...>> wrote:

Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
<https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54>
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


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

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


Re: RFC on STM32 Ethernet driver

Erwin Rol
 

Hey Erwan,

like you say some things are subjective when it comes to HAL's, but
somethings really bother me with the STM32 HAL.

The most important is how to deal with IRQ's. In Zephyr I have to setup
the ISR like this;

IRQ_CONNECT(ETH_IRQn, CONFIG_ETH_STM32_IRQ_PRI, eth_isr,
DEVICE_GET(eth0_stm32), 0);
irq_enable(ETH_IRQn);

Now the eth_isr will be called on IRQ. But to use everything from the
HAL we must call the;

void HAL_ETH_IRQHandler(ETH_HandleTypeDef *heth)

That function will than call;

__weak void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)

But as you can see we register a ISR to take a "struct eth0_stm32*" but
all the HAL functions only have "ETH_HandleTypeDef *heth" arguments.

So our driver ISR somehow needs something to go from ETH_HandleTypeDef
*heth to struct eth0_stm32*. The other way around is simple, the
eth0_stm32 struct just has a ETH_HandleTypeDef member.

I solved this to copy the HAL_ETH_IRQHandler handler to my driver and
change it to take my eth0_stm32 struct as argument.

But I really don't like the idea to use half the HAL and copy the other
half.

Would there be a better solution?

BTW: this applies to pretty much everything the uses STM32 IRQ's. I
already noticed the the UART does not use the HAL, but that would have
had the same problem.

It would have been nice if those ETH_HandleTypeDef structures had a
void* user_data member.

That directly brings me to the next point, how are things managed with
upstream (ST) if Zephyr finds problems/bugs in the HAL? Bugs they
probably would not mind to fix, but how to deal with things that are
Zephyr specific, will that mean the Zephyr STM32 HAL will diverge from
the official ST HAL ?

- Erwin

On 6-6-2017 11:19, Erwan Gouriou wrote:
Hi Erwin,


Thanks for proposing this driver, I think it will interest a lot of people.

About your last point, let me mention ST view on this:

This is a question of trade-off. Using HAL has some drawbacks (some might
be objectives like footprint or more subjective like CamelCase), but it's
definitely possible in Zephyr.
Main interest is that it will help having a reliable driver working on
all STM32
SoCs supporting ethernet (today in zephyr: stm32f407, stm32f429, stm32f469,
stm32f7xx under review) faster. More supported SoCs also means more
interested people, which will help in getting the driver mature.
In the end, it should save time to work on end applications rather than
porting.

A native driver, specific to the IP (which might also be used on other
SoCs),
might be more optimized, but this might also take you some time before
having it mature for complex IPs such as ethernet (or USB..).

In any case, I think it would be great to have your driver upstreamed in
a first time. Then, time will tell if a native driver is nice to have or
required.

Erwan



On 3 June 2017 at 15:17, Erwin Rol <mailinglists@...
<mailto:mailinglists@...>> wrote:

Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
<https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54>
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


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


Re: Include directory

Tomasz Bursztyka
 

Hi Prasad,

Mostly driver dedicated public functions used by the system or by some specific board configuration.

Just talking about those I know:
Console ones for instance, you can register a different input callback function than the system default one (which uses these headers as well).

For ieee802154/cc2520.h it exposes how the driver gets configured from gpio point of view, that has to be made then in relevant
board.h/c etc...

That said there are misplaced headers, gpio/gpio_mmio.h for instance has nothing to do there.
serial/uart_nsim.h seems totally useless also etc..

Looks like some cleanup would be necessary.

Tomasz


Folks,

 

Could you please tell me why “include” directory is organized like this? I mean to say there is “drivers” folder and driver API header files are outside this directory(e.g. dma.h, adc.h etc..). What exactly the need of “driver” directory here? Are there any proprietary API’s for different boards/architecture??

 

 

Thanks

Prasad



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



Include directory

Prasad Hegde
 

Folks,

 

Could you please tell me why “include” directory is organized like this? I mean to say there is “drivers” folder and driver API header files are outside this directory(e.g. dma.h, adc.h etc..). What exactly the need of “driver” directory here? Are there any proprietary API’s for different boards/architecture??

 

 

Thanks

Prasad


Re: DMA driver API, source_burst_length, dest_burst_length

Liu, Baohong
 

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Johann Fischer
Sent: Thursday, June 8, 2017 6:40 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] DMA driver API, source_burst_length, dest_burst_length

Hi,

The DMA API describes the source_burst_length and dest_burst_length of the
struct dma_config as:

...
* source_burst_length [ 0 : 15 ] - number of source data units
* dest_burst_length [ 16 : 31 ] - number of destination data units
...

What are the data units? octets?
This is HW related. It can't specified here in the generic API.

Burst length should be used together with transfer width. Let me give an example.

For a single DMA data transfer, the source can only send data out at 2 bytes each transfer and the destination can only accept data at one byte each transfer (this is HW related.). The DMA engine will get 2 bytes from the source and sends the data to the destination one byte each time (do this twice). For this case, the DMA burst length will be 2 bytes long, since this is the minimum data unit the source side can deal with. So,
source_burst_length = 1
source_transfer_width = 2
dest_burst_length = 2
dest_transfer_width = 1

Note: 1 or 2 in the above is absolute value. Since in the API, the enum starts from 0, 1 or 2 should be changed to 0 or 1.


From the test code, it is also not clear:

tests/drivers/dma/test_loop_transfer/src/dma.c:

initializes dma_cfg.dest_burst_length = 1;


tests/drivers/dma/test_chan_blen_transfer/src/test_dma.c

initializes dma_cfg.dest_burst_length = blen; /* blen = (8 | 16) */

--
Best Regards,
Johann Fischer
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


DMA driver API, source_burst_length, dest_burst_length

Johann Fischer
 

Hi,

The DMA API describes the source_burst_length and dest_burst_length of the struct dma_config as:

...
* source_burst_length [ 0 : 15 ] - number of source data units
* dest_burst_length [ 16 : 31 ] - number of destination data units
...

What are the data units? octets?

From the test code, it is also not clear:

tests/drivers/dma/test_loop_transfer/src/dma.c:

initializes dma_cfg.dest_burst_length = 1;


tests/drivers/dma/test_chan_blen_transfer/src/test_dma.c

initializes dma_cfg.dest_burst_length = blen; /* blen = (8 | 16) */

--
Best Regards,
Johann Fischer


Re: RFC on STM32 Ethernet driver

Erwan Gouriou
 

Hi Erwin,


Thanks for proposing this driver, I think it will interest a lot of people.

About your last point, let me mention ST view on this:

This is a question of trade-off. Using HAL has some drawbacks (some might
be objectives like footprint or more subjective like CamelCase), but it's
definitely possible in Zephyr.
Main interest is that it will help having a reliable driver working on all STM32
SoCs supporting ethernet (today in zephyr: stm32f407, stm32f429, stm32f469,
stm32f7xx under review) faster. More supported SoCs also means more
interested people, which will help in getting the driver mature.
In the end, it should save time to work on end applications rather than porting.

A native driver, specific to the IP (which might also be used on other SoCs),
might be more optimized, but this might also take you some time before
having it mature for complex IPs such as ethernet (or USB..).

In any case, I think it would be great to have your driver upstreamed in
a first time. Then, time will tell if a native driver is nice to have or required.

Erwan



On 3 June 2017 at 15:17, Erwin Rol <mailinglists@...> wrote:
Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


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


Re: OS abstraction

Tomasz Bursztyka
 

Hi Jon,

Zephyr has its own driver model, and its own APIs, but it accepts external HALs.

If you have an already existing "generic driver, you'll be able to put in it ext/hal/broadcom and write
a shim driver for Zephyr thus reusing the driver for Zephyr.

See how other HALs have been integrated this way.

Br,

Tomasz

On 05/06/2017 16:53, Jon Mason via Zephyr-devel wrote:
Stated alternatively, Would it be acceptable usptream to have a
HAL-like layer that would abstract the OS dependent calls in a driver
(thus allowing for the drivers to be used in other RTOSes)?

Thanks,
Jon

On Sun, Jun 4, 2017 at 11:52 PM, Prasad Hegde Nagapati via
Zephyr-devel <zephyr-devel@...> wrote:
Guys,



I would like to know, how easily I can port any other OS(If we have any
other proprietary OS) into this architecture.



Best Regards

Prasad


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


Zephyr vs FreeRTOS drivers and interrupt

Anders Dam Kofoed <adk@...>
 

Hi all,

I cannot seem to find any info on this question, so I thought I'd ask here.

My question is this: When a driver (eg. SPI or UART)  is invoked through FreeRTOS, it is using the vendor HAL (or registers directly). Then there are two options for calling it: 1) busy waiting and 2) busy-waiting. If the FreeRTOS task busy-waits and FreeRTOS has a preemptive scheduler, then my question is this: FreeRTOS does not have knowledge of the busy-waiting, hence the task gets allocated a timeslot (for doing busy-waiting). Is this correct?

Now in Zephyr, I can see that when the driver is called, Zephyr keeps track of the calling task (which is then suspended), and in the drivers interrupt routine it puts the calling thread into the run-queue, ready to proceed. This way no cycles are waisted.

Thanks
Anders Dam Kofoed


Re: OS abstraction

Jon Mason <jon.mason@...>
 

Stated alternatively, Would it be acceptable usptream to have a
HAL-like layer that would abstract the OS dependent calls in a driver
(thus allowing for the drivers to be used in other RTOSes)?

Thanks,
Jon

On Sun, Jun 4, 2017 at 11:52 PM, Prasad Hegde Nagapati via
Zephyr-devel <zephyr-devel@...> wrote:
Guys,



I would like to know, how easily I can port any other OS(If we have any
other proprietary OS) into this architecture.



Best Regards

Prasad


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


Re: [devel] STM32F7 Port

Lucas Tanure <tanure@...>
 

Would you like my review on this ? I can test on my board.

Thanks

On Mon, Jun 5, 2017 at 2:30 AM, Fabien Parent <fparent@...> wrote:
Hi Lucas,

There is a pull request that adds support for STM32F7 + STM32F723E
Discovery board: https://github.com/zephyrproject-rtos/zephyr/pull/187
. I plan to finish upstreaming it in a week when I will be back from
vacation. This should easier your work for the STM32F746G-DISCO.

Fabien

On Sat, Jun 3, 2017 at 4:07 AM, Lucas Tanure <tanure@...> wrote:
Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

--
Lucas Tanure
Embedded Developer
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
--
Lucas Tanure
Embedded Developer
+55 19 988176559


OS abstraction

Prasad Hegde
 

Guys,

 

I would like to know, how easily I can port any other OS(If we have any other proprietary OS) into this architecture.

 

Best Regards

Prasad


Re: [devel] STM32F7 Port

Fabien Parent <fparent@...>
 

Hi Lucas,

There is a pull request that adds support for STM32F7 + STM32F723E
Discovery board: https://github.com/zephyrproject-rtos/zephyr/pull/187
. I plan to finish upstreaming it in a week when I will be back from
vacation. This should easier your work for the STM32F746G-DISCO.

Fabien

On Sat, Jun 3, 2017 at 4:07 AM, Lucas Tanure <tanure@...> wrote:
Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

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


RFC on STM32 Ethernet driver

Erwin Rol
 

Hello,

I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.

It can be found at github;

https://github.com/lowlander/zephyr/commit/6a49b0e0c435f0529b97255c675fb57e54d23a54
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.

The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.

For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.

With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.

The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.

I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.

- Erwin


[devel] STM32F7 Port

Lucas Tanure <tanure@...>
 

Hi,

I would like to develop the port for stm32f7, in order to use zephyr
in my STM32F746G-DISCO.
I saw some code related to stm32f7 under "ex" folder, and one thread
in november of 2016 : "Porting to ARM Cortex-M7 / Atmel SAM E70
support"

How is the status for that ?

I was thinking write the source for the CPU first, like copy
arch/arm/soc/st_stm32/stm32f4 to arch/arm/soc/st_stm32/stm32f7
and modify it acording to :
RM0385 Reference manual STM32F75xxx and STM32F74xxx advanced ARM ®
-based 32-bit MCUs

Can I work on it ? Or already there is someone working on that ?

Thanks

--
Lucas Tanure
Embedded Developer


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Andy Gross
 

+1


On 2 June 2017 at 04:02, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least
3 options:
a) Keep board independant pinmuxing, and up to each board to present
pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then
boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the
fly
d) Use DTS overlays. If this requires multiple overlays, we can
extend that to provide the feature.


In any case, boards should provide a "compatible" field at some point to
document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@...> wrote:

Hi Neil,
I think this is a great idea to support another layer for shields and
extensions on top of existing boards. This will also allow usage for custom
test shields that can specified for testcases, i.e. to test IOs and
peripherals. Not sure about the naming and structure yet and if it should
go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@...
[mailto:zephyr-devel-bounces@...] On Behalf Of Neil
Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the
Arduino or ST Morpho connectors for example, but there is no simple way to
explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and
config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with
Arduino Uno R3 connector, but a cfg for each supported board should be
supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like
SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


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


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Erwan Gouriou
 

Hi Neil,

+1 for me too. This would really be handy in long range.

Obviously, one point to solve is how to deal with pinmuxing. I see at least 3 options:
a) Keep board independant pinmuxing, and up to each board to present pinmuxing(s)
compatible with required shield(s)
b) Define generic pinmuxing profiles(arduino_pinmux for instance). Then boards and
shields would include these profiles (when compatible)
c) Shield activation (with EXTBOARD=..) would configure board pinmux on the fly

In any case, boards should provide a "compatible" field at some point to document
the supported shields (or pinmux profiles).


Erwan

On 1 June 2017 at 22:41, Nashif, Anas <anas.nashif@...> wrote:
Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals.  Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
      ext/
         x-nucleo-iks01a1/
                          Kconfig.ext
                          Kconfig.defconfig
                          ext.h
                          Makefile
                          x_nucleo_iks01a1.nucleo_f103rb_defconfig
                          x_nucleo_iks01a1.nucleo_f334r8_defconfig
                          x_nucleo_iks01a1.nucleo_f401re_defconfig
                          x_nucleo_iks01a1.nucleo_l476rg_defconfig
                          doc/
                              x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Nashif, Anas
 

Hi Neil,
I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for testcases, i.e. to test IOs and peripherals. Not sure about the naming and structure yet and if it should go under boards, but you get a +1 from me on the general idea.

Thanks,
Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Neil Armstrong
Sent: Thursday, June 1, 2017 11:06 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] [RFC] Mezzanine/Hat/Extension/Shield board support

Hi,

Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr codebase.

Would it be possible to add a boards/ext tree with Kconfig, docs and config parameters for each supported boards ?

For example for the X-NUCLEO-IKS01A1 board, it will concern all board with Arduino Uno R3 connector, but a cfg for each supported board should be supplied :

boards/
ext/
x-nucleo-iks01a1/
Kconfig.ext
Kconfig.defconfig
ext.h
Makefile
x_nucleo_iks01a1.nucleo_f103rb_defconfig
x_nucleo_iks01a1.nucleo_f334r8_defconfig
x_nucleo_iks01a1.nucleo_f401re_defconfig
x_nucleo_iks01a1.nucleo_l476rg_defconfig
doc/
x_nucleo_iks01a1.rst


And for build options, a new options along BOARD= could be supplied, like SHIELD= or EXTBOARD=.

Waiting for some advices !

Neil
--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux www.baylibre.com _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

5641 - 5660 of 8640