Re: uint32_t typedef differences causes issues
Marcus Shawcroft <marcus.shawcroft@...>
#include <stdint.h>Not having much luck there, but its possible I’m missing something obvious because of lack of sleep: That would be my fault, my example above is missing: #include <inttypes.h> Cheers /Marcus
|
|
Daily Gerrit Digest
donotreply@...
NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10172 : board: add nucleo_401re board documentation - https://gerrit.zephyrproject.org/r/10235 : net: nbuf: Fix debug prints for memory allocations - https://gerrit.zephyrproject.org/r/10236 : net: context: Add status to connect callback - https://gerrit.zephyrproject.org/r/10234 : net: zperf: Add bluetooth support - https://gerrit.zephyrproject.org/r/10225 : net: samples: Add ENC28J60 pin numbers to documentation - https://gerrit.zephyrproject.org/r/10226 : net: samples: Print assigned address from DHCPv4 server - https://gerrit.zephyrproject.org/r/10233 : net: zoap-client: Add bluetooth support - https://gerrit.zephyrproject.org/r/10189 : Xtensa port: Added kernel arch dependent structs and functions. - https://gerrit.zephyrproject.org/r/10230 : Makefile (arc/soc/quark_se): New compiler options - https://gerrit.zephyrproject.org/r/10229 : Makefile (arc/soc/em*): New compiler options - https://gerrit.zephyrproject.org/r/10228 : arc: add -fno-delete-null-pointer-checks - https://gerrit.zephyrproject.org/r/10227 : Makefile.toolchain.zephyr: Modifications for SDK 0.9 - https://gerrit.zephyrproject.org/r/10231 : samples: sensor: fxos8700: use floating point for printing sensor values - https://gerrit.zephyrproject.org/r/10232 : sensor: fxos8700: fix missing dependency in Kconfig - https://gerrit.zephyrproject.org/r/10224 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET - https://gerrit.zephyrproject.org/r/10223 : build: have sysgen create SPDX license identifiers - https://gerrit.zephyrproject.org/r/10190 : samples/net/http: Move http write functionality to its own files - https://gerrit.zephyrproject.org/r/10219 : samples/net/http: Add the It works! web page - https://gerrit.zephyrproject.org/r/10220 : samples/net/http: Modify data pool size - https://gerrit.zephyrproject.org/r/10218 : samples/net/http: Increase the max number of network contexts - https://gerrit.zephyrproject.org/r/10178 : samples/net/http: Introduce routines to handle multiple contexts - https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition - https://gerrit.zephyrproject.org/r/10212 : net/ip: Do not modify the address for failure cases - https://gerrit.zephyrproject.org/r/10215 : scripts: quick script to determine candidates to own Coverity issues - https://gerrit.zephyrproject.org/r/10213 : doc: Fix :lines: references in docs - https://gerrit.zephyrproject.org/r/10188 : Xtensa port: Added Xtensa header generic files. - https://gerrit.zephyrproject.org/r/10176 : Add support for STM32Cube HAL_PCD USB driver - https://gerrit.zephyrproject.org/r/10175 : cdc_acm - Use endpoint 3 instead of endpoint 4 for IN BULK endpoint - https://gerrit.zephyrproject.org/r/10192 : x86: implement direct interrupts - https://gerrit.zephyrproject.org/r/10194 : sanity: switch sdk depending on branch - https://gerrit.zephyrproject.org/r/10187 : test - https://gerrit.zephyrproject.org/r/10186 : Zephyr 1.6-rc2 - https://gerrit.zephyrproject.org/r/10185 : Zephyr 1.6.0-rc1 - https://gerrit.zephyrproject.org/r/10181 : kernel.h: add prototype for private idle exit function - https://gerrit.zephyrproject.org/r/10184 : gen_idt: show vector assignments in debug output - https://gerrit.zephyrproject.org/r/10182 : kernel_event_logger: add additional function prototypes - https://gerrit.zephyrproject.org/r/10177 : samples: pwm: move pwm samples into one directory UPDATED within last 24 hours: - https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST - https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series - https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler - https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file - https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format. - https://gerrit.zephyrproject.org/r/9920 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET - https://gerrit.zephyrproject.org/r/10093 : samples/net/http: Add the server sample application - https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level - https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux - https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim - https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver - https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs - https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address - https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse - https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running - https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure - https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure - https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration - https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers - https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board - https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver - https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver - https://gerrit.zephyrproject.org/r/8922 : scripts: Add device tree parser script - https://gerrit.zephyrproject.org/r/7664 : second: test - https://gerrit.zephyrproject.org/r/9678 : http: add server sample - https://gerrit.zephyrproject.org/r/4457 : DONT: MERGE - cause checkpatch warnings - https://gerrit.zephyrproject.org/r/10136 : drivers: QMSI RTC: simplify driver reentrancy code using IS_ENABLED - https://gerrit.zephyrproject.org/r/10135 : drivers: QMSI SOC flash: simplify driver reentrancy code using IS_ENABLED - https://gerrit.zephyrproject.org/r/10134 : drivers: QMSI PWM: simplify driver reentrancy code using IS_ENABLED macro - https://gerrit.zephyrproject.org/r/4541 : DONT MERGE - break checkpatch - https://gerrit.zephyrproject.org/r/5475 : DONT MERGE - break sanity AND checkpatch - https://gerrit.zephyrproject.org/r/9981 : samples: spi_flash: remove an unnecessary config symbol - https://gerrit.zephyrproject.org/r/10117 : doc: move context back to doc/, fix broken links - https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP - https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use - https://gerrit.zephyrproject.org/r/10142 : net: tcp: fix buffer leak in tcp_synack_received - https://gerrit.zephyrproject.org/r/10144 : net: tcp: add timeout wait in net_context_connect - https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer - https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1 - https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS - https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly - https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: Convert DO_REBOOT to use CMSIS - https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: Convert systick to CMSIS - https://gerrit.zephyrproject.org/r/9971 : timer: nrf_rtc: Use CMSIS NVIC APIs directly - https://gerrit.zephyrproject.org/r/9972 : clock_control: nrf5_power: Use CMSIS NVIC APIs directly - https://gerrit.zephyrproject.org/r/9970 : arm: cmsis: Introduce CMSIS layer - https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Remove unused code from scb/scs layers - https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS MERGED within last 24 hours: - https://gerrit.zephyrproject.org/r/10222 : net: in newlib, ESHUTDOWN is considered an extension - https://gerrit.zephyrproject.org/r/10221 : net: buf: Use TCP sent_list variable only if needed - https://gerrit.zephyrproject.org/r/10217 : samples: net: Enable buffer warning and errors in echo apps on qemu - https://gerrit.zephyrproject.org/r/10216 : samples: net: Fix a format issues in echo_client - https://gerrit.zephyrproject.org/r/10195 : samples/zoap_server: Add support for the '/separate' resource - https://gerrit.zephyrproject.org/r/10196 : samples/zoap_server: Add support for blockwise GET tests - https://gerrit.zephyrproject.org/r/10197 : iot/zoap: Add response code for Continue status - https://gerrit.zephyrproject.org/r/10198 : samples/zoap_server: Add resouce for TD_COAP_BLOCK_03 - https://gerrit.zephyrproject.org/r/10199 : iot/zoap: Ignore non-request packets in zoap_handle_request - https://gerrit.zephyrproject.org/r/10200 : iot/zoap: Fix wrong byte-order when retrieving integer options - https://gerrit.zephyrproject.org/r/10201 : iot/zoap: Clarify the return value of zoap_register_observer() - https://gerrit.zephyrproject.org/r/10202 : iot/zoap: Add a helper to find an observer by address - https://gerrit.zephyrproject.org/r/10203 : samples/zoap_server: Fix responding messages with the wrong type - https://gerrit.zephyrproject.org/r/10204 : samples/zoap_server: Add support for messages with token - https://gerrit.zephyrproject.org/r/10205 : samples/zoap_server: Add Content-Format options to GET responses - https://gerrit.zephyrproject.org/r/10206 : samples/zoap_server: Include a path for the "created" resource - https://gerrit.zephyrproject.org/r/10207 : samples/zoap-server: Add support for the "location-query" resource - https://gerrit.zephyrproject.org/r/10208 : samples/zoap_server: Do not error if there's no payload or queries - https://gerrit.zephyrproject.org/r/10214 : Bluetooth: SPI: Replace Apache boilerplate with SPDX tag - https://gerrit.zephyrproject.org/r/10174 : arm: nvic: kill _NvicSwInterruptTrigger - https://gerrit.zephyrproject.org/r/10210 : license: Replace Apache boilerplate with SPDX tag - https://gerrit.zephyrproject.org/r/10173 : Merge bluetooth branch into master - https://gerrit.zephyrproject.org/r/10209 : drivers: i2c: remove an unnecessary condition check - https://gerrit.zephyrproject.org/r/10168 : net: shell: Use lighter printk() instead of printf() - https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse - https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board config files for Xtensa simulator paltform - https://gerrit.zephyrproject.org/r/10154 : net: dhcpv4: Remove dead code - https://gerrit.zephyrproject.org/r/10153 : net: 6lo: Fix dereferencing null pointer - https://gerrit.zephyrproject.org/r/10151 : net: nbuf: Check possible null pointer access - https://gerrit.zephyrproject.org/r/10122 : net: tcp: remove unused semaphore tcp_lock - https://gerrit.zephyrproject.org/r/10152 : net: 6lo: Handle destination address uncompression properly - https://gerrit.zephyrproject.org/r/10146 : net: Fix possible null pointer dereference in nbuf - https://gerrit.zephyrproject.org/r/10147 : net: icmpv6: Removing dead code - https://gerrit.zephyrproject.org/r/10148 : net: tcp: Allocate space for TCP header - https://gerrit.zephyrproject.org/r/10149 : net: ipv6: Check neighbor pointer in NS reply timeout - https://gerrit.zephyrproject.org/r/10150 : net: ipv6: Fix IPv6 prefix comparision - https://gerrit.zephyrproject.org/r/10120 : sanitycheck: improve terse output - https://gerrit.zephyrproject.org/r/10125 : build: remove obsolete sections from linker scripts - https://gerrit.zephyrproject.org/r/10138 : arm: set default vector table address in prep_c when XIP - https://gerrit.zephyrproject.org/r/10139 : arm/nordic_nrf5: enable SOC_FLASH_NRF5 by default if FLASH is enabled - https://gerrit.zephyrproject.org/r/10169 : Bluetooth: Don't select TinyCrypt RNG for combined builds - https://gerrit.zephyrproject.org/r/10111 : Bluetooth: L2CAP: Fix always using RX_BUF_COUNT as initial credits
|
|
Re: uint32_t typedef differences causes issues
Kumar Gala
On Jan 19, 2017, at 8:57 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote: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, ^ Here’s what BT_ERR looks like: BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err, sizeof(_radio)); - k
|
|
Re: uint32_t typedef differences causes issues
Hi Marcus,
On Thu, Jan 19, 2017, Marcus Shawcroft wrote: Does "correct" in this case have any practical significance? It worsensThe right format specifier for unsigned integers is %u and not %d, so asSince the type is 'uint32_t' rather than 'unsigned' the correct specifier is: 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. Johan
|
|
Re: uint32_t typedef differences causes issues
Kumar Gala
On Jan 19, 2017, at 8:52 AM, Johan Hedberg <johan.hedberg(a)intel.com> wrote:Thought that myself, but with %u you get: In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:23: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:387:10: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=] BT_ERR("Required RAM size: %u, supplied: %u.", err, - k
|
|
Re: uint32_t typedef differences causes issues
Marcus Shawcroft <marcus.shawcroft@...>
On 19 January 2017 at 14:52, Johan Hedberg <johan.hedberg(a)intel.com> wrote:
Hi Kumar,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); Cheers /Marcus
|
|
Re: uint32_t typedef differences causes issues
Hi Kumar,
On Thu, Jan 19, 2017, Kumar Gala wrote: It looks like newlib and our mini libc define uint32_t differently andThe 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 away. Johan
|
|
Re: uint32_t typedef differences causes issues
Marcus Shawcroft <marcus.shawcroft@...>
Hi,
toggle quoted messageShow quoted text
[Second attempt at responding, my arm email address seems to have triggered a moderator approval, sorry about the duplication for those of you that got a direct reply.] This is because the code is using the wrong format specifier, see JIRA-1181 https://jira.zephyrproject.org/browse/ZEP-1181 Cheers /Marcus
On 19 January 2017 at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:
It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:
|
|
Re: uint32_t typedef differences causes issues
Marcus Shawcroft <Marcus.Shawcroft@...>
On 19 Jan 2017, at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:Hi, This is because the code is using the wrong format specifier, see JIRA-1181 Cheers /Marcus IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
uint32_t typedef differences causes issues
Kumar Gala
It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:
/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:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=] As newlib typedef long unsigned int uint32_t; Mini libc: typedef unsigned int uint32_t; So wondering if we should change mini-libc to match and fix up all the build issues associated with this? Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains - k
|
|
Re: Any plan for OTA support?
Carles Cufi
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<mailto: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> [mailto:nvl1109(a)gmail.com<mailto:nvl1109(a)gmail.com>] Sent: Saturday, January 14, 2017 15:43 To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org> <devel(a)lists.zephyrproject.org<mailto: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: [RFC]DMA API Update
Jon Medhurst (Tixy) <tixy@...>
On Wed, 2017-01-18 at 23:15 +0000, Liu, Baohong wrote:
[...]From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org] So, when I add DMA support to my uart, everyone project that uses aThe DMA driver should have configuration entries for setting these parameters and 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
|
|
[USB] composite device
Alexey Belyaev <BeliaevAV@...>
Hello, is anybody tried to realize composite USB-device? Any hints? Examples?
Thank you.
|
|
Re: Suggestions for getting started
Kumar Gala
On Jan 18, 2017, at 12:29 PM, Abhinav Misra <abhitheextremeeng(a)gmail.com> wrote: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: [RFC]DMA API Update
Liu, Baohong
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]The DMA API can be used by drivers for DMA operations IMO, ideally the SPI driver should call the DMA API to implement the DMA support. However, I think this is up to the driver to decide to use the DMA API or to utilize a HAL driver it depends on Either one is fine. 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 The current API dma_channel_config can support this; when the channel is being used by a driver, if another driver calls the dma_channel_config API, the API should return an specific error code indicating the channel is not ready to be used. --
|
|
Re: [RFC]DMA API Update
Liu, Baohong
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]Just to clarify my previous answer which is meant to say that there are existing usage cases a driver use API from another driver. (e.g some sensor drivers uses I2C driver API) For the channel assignment, I think this should be decided and set by an app level Prj.conf, not by driver Kconfig. The DMA API is designed to solve that; ideally app or drivers should all use the DMA API to implement DMA support --
|
|
Re: [RFC]DMA API Update
Tseng, Kuo-Lang <kuo-lang.tseng@...>
Baohong,
toggle quoted messageShow quoted text
[...]-----Original Message-----From: Liu, Baohong [mailto:baohong.liu(a)intel.com] 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. Kuo
|
|
SSH on Galileo
Fábio Iaione <fabio.iaione at gmail.com...>
Dear Sirs,
Does Zephyr have SSH support? Thank you.
|
|
Re: Zephyr on STM32F042/072/405 with USB?
Christer Weinigel
Hi Erwan,
toggle quoted messageShow quoted text
well, it wasn't too hard. Almost everything is already implemented in the STM Cube drivers and only a little bit of glue code was needed. I've only implemented the functions needed by the cdc_acm driver so other higher level drivers such as mass storage will probably not work. It's not very heavily tested and might contain race conditions that will show up under load. But it's a start. https://gerrit.zephyrproject.org/r/#/c/10175/ Even if this driver doesn't break down under load, performance will suck due to the way I've implemented the usb_dc_ep_read function. The upper layers expect the usb_dc_read function to return data immediately while the STM32 Cube HAL_PCD_EP_Receive function only starts a read and data will not be available until HAL_PCD_DataOutStageCallback is called by the HAL. The way I have worked around this for the moment is to have an extra packet buffer in the usb_dc_stm driver that HAL_PCD_EP_Receive reads into, and then when usb_dc_ep_read is called data from this buffer is copied to higher level driver. In the case of cdc_acm driver, this will be done 4 bytes at a time, and then the data in the cdc_acm buffer is copied to yet another buffer one byte at a time and when data is read from the serial buffer it's copied again. To get decent performance out of the STM32 Cube drivers all higher level drivers ought to split usb_dc_ep_read into a usb_dc_ep_start_read and a usb_dc_ep_get_read_count function so that it matches what the HAL layer does. It's a bit painful, but shouldn't be that hard. If the higher level driver is also aware of USB packet boundaries and alighment this could also allow DMA directly into the driver buffers for hardware (such as the STM32F4xx) that supports it. /Christer
On 2017-01-16 11:31, Erwan Gouriou wrote:
Hi Christer, Before I spend a lot of time trying to do this, is anyone else working
|
|
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,
|
|