|
Re: DMA driver API, source_burst_length, dest_burst_length
Johann Fischer
Hi Baohong,
thanks for the clarification. I suppose:What are the data units? octets?This is HW related. It can't specified here in the generic API. 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. 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,
toggle quoted messageShow quoted text
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,
|
|
|
|
Re: RFC on STM32 Ethernet driver
Neil Armstrong
Hi Erwin,
toggle quoted messageShow quoted text
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,
|
|
|
|
Re: RFC on STM32 Ethernet driver
Erwin Rol
Hey Erwan,
toggle quoted messageShow quoted text
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,
|
|
|
|
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
|
|
|
|
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
toggle quoted messageShow quoted text
-----Original Message-----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.
|
|
|
|
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. 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,
|
|
|
|
Re: OS abstraction
Tomasz Bursztyka
Hi Jon,
toggle quoted messageShow quoted text
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
|
|
|
|
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,
|
|
|
|
Re: [devel] STM32F7 Port
Lucas Tanure <tanure@...>
Would you like my review on this ? I can test on my board.
toggle quoted messageShow quoted text
Thanks
On Mon, Jun 5, 2017 at 2:30 AM, Fabien Parent <fparent@...> wrote:
Hi Lucas, --
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,
toggle quoted messageShow quoted text
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,
|
|
|
|
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,d) Use DTS overlays. If this requires multiple overlays, we can extend that to provide the feature.
|
|
|
|
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,
|
|
|
|
Re: [RFC] Mezzanine/Hat/Extension/Shield board support
Nashif, Anas
Hi Neil,
toggle quoted messageShow quoted text
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
|
|
|
