Re: Suggestions for getting started
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?
Re: [RFC]DMA API Update
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
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.
SSH on Galileo
Fábio Iaione <fabio.iaione at gmail.com...>
Does Zephyr have SSH support?
Re: Zephyr on STM32F042/072/405 with USB?
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.
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.
On 2017-01-16 11:31, Erwan Gouriou wrote:
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.
On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Suggestions for getting started
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
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.
Re: RFC: ieee802154 radio api
Ok sound like it could use the actual RAW use of the driver.No, it just for the PHY (RF Testing, simular to BT DTM, e.g.Isn't this kind of test made out of any 15.4 network? (i.e.: does itIt would be turned off by default (return -ENOTSUPP). It is useful forint (*set_rf_test_mode)(struct device *dev, uint32_t mode),What's the use case for it?
So you would need 2 function:
- one returning the supported modes
- one running the test with requested mode as you proposed.
this would be exposed only on Kconfig option condition.
Re: [RFC] STM32 pinmux - simplify pinmux logic
On 2017-01-17 13:38, Erwan Gouriou wrote:
I agree with the observation that gpio/pinmux configuration isIt looks quite similar, if I understood this correctly, he's also added
some macros to combine the pull up/pull down/function with the alternate
function in one word:
Although I think it's nicer to do what I did and put the pin information
in drivers/pinmux/stm32/pinmux_stm32f4.h since it puts everything in one
Other than that it looks like a nice patchset to add support for the
After thinking a bit more about this, I'm actually not too fond of magic
macros like my STM32F4_PINMUX_ENCODE. Sometimes abstractions can be
nice, but in this case I actually thinks that it obscures more than it
helps. I would actually prefer to change the defines to have the a
shift built in, that is change the stm32f4x_pin_config_mode enum to defines:
#define STM32F4X_PIN_CONFIG_AF_PUSH_MASK (15 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_PULL (0 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_UP (1 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_DOWN (2 << 8)
STM32F4X_PIN_CONFIG_ANALOG (15 << 8)
so that the defines in pinmux_stm32.h can be a bit more explicit not
have to use the STM32F4_PINMUX_ENCODE macro:
(STM32F4X_PIN_CONFIG_AF_PUSH_UP | STM32_PINMUX_FUNC_ALT_7)
this also allows more flexibility, we're no longer limited to just two
axes of parameters. For example AF_PUSH_UP actually combines three
different settings. We can split that into MODE_AF, PULL_UP and
#define STM32F4X_PIN_MODE_MASK (3 << 8)
#define STM32F4X_PIN_MODE_INPUT (0 << 8)
#define STM32F4X_PIN_MODE_OUTPUT (1 << 8)
#define STM32F4X_PIN_MODE_AF (2 << 8)
#define STM32F4X_PIN_MODE_ANALOG (3 << 8)
#define STM32F4X_PIN_PULL_MASK (3 << 10)
#define STM32F4X_PIN_PULL_NONE (0 << 10)
#define STM32F4X_PIN_PULL_UP (1 << 10)
#define STM32F4X_PIN_PULL_DOWN (2 << 10)
#define STM32F4X_PIN_OTYPE_MASK (1 << 12)
#define STM32F4X_PIN_OTYPE_PUSH_PULL (0 << 12)
#define STM32F4X_PIN_OTYPE_OPEN_DRAIN (1 << 12)
and for completeness we could also expose the speed settings:
#define STM32F4X_PIN_SPEED_MASK (3 << 13)
#define STM32F4X_PIN_SPEED_LOW (0 << 13)
#define STM32F4X_PIN_SPEED_MEDIUM (1 << 13)
#define STM32F4X_PIN_SPEED_FAST (2 << 13)
#define STM32F4X_PIN_SPEED_HIGH (3 << 13)
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.
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.
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 canI'll see if I can clean up my ideas and push a few patches for review in
Re: RFC: ieee802154 radio api
No, it just for the PHY (RF Testing, simular to BT DTM, e.g.Isn't this kind of test made out of any 15.4 network? (i.e.: does itIt would be turned off by default (return -ENOTSUPP). It is useful forint (*set_rf_test_mode)(struct device *dev, uint32_t mode),What's the use case for it?
DTM_PKT_PRBS9 or CARRIER_TEST ...). It would also needs a shell command.
Re: RFC: ieee802154 radio api
On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:Good to know. Does it behave like that because it can do some/all of the<snip>For example, if the hardware can automatically perform CCA before the TXNo. L2 has to call that, unless hw can perform part or all of the radio
CSMA job directly?
For now I'd say disable auto-CCA in driver by default, then.
Basically manual CCA is meant for the fully soft-CSMA radio strategy,
as it is right now.
If only auto-cca does not mess up with the manual one, then keep it enabled.
But soon, we'll have to figure out a way to hand-over CSMA parts to
relevant hw that can
Hum, MAC and L2 in our case is the same. What I call L2 here isWhat if the MAC needs full control over L2 retransmissions (e.g. in a TDMA- IEEE802154_HW_FRAME_RETRIESUp to the driver to handle it. L2 does not have to care about it.
ieee802.15.4 soft-MAC L2 stack.
Anyway, TDMA is not part of IEEE 802.15.4 <= 2011, so we can put it aside.
TSCH is for IEEE 802.15.4 >= 2012. So at this point we can put it aside.Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this isIn addition, I would insert following flags:Always enable it if the hw supports it.
Or is your point only about setting these capabilities at runtime? Is it stillWe had autoack, and crc and all being disabled at compile time for a
while. But at this stage
it was just useless, so it got removed.
Re: RFC: ieee802154 radio api
Oliver Hahm <oliver.hahm@...>
On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:
<snip>For example, if the hardware can automatically perform CCA before the TXNo. L2 has to call that, unless hw can perform part or all of the radio
Not sure, I understand you correctly here, but some transceivers (e.g. the- IEEE802154_HW_LBT (listen before transmit or CCA before TX)Always enable it if the hw supports it, at built time.
at86rf2xx) does not allow you to perform manual CCA if automatic CCA is
What if the MAC needs full control over L2 retransmissions (e.g. in a TDMA- IEEE802154_HW_FRAME_RETRIESUp to the driver to handle it. L2 does not have to care about it.
Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this isIn addition, I would insert following flags:Always enable it if the hw supports it.
not a viable solution.
Or is your point only about setting these capabilities at runtime? Is it still
possible to disable these flags at compile time?
Re: RFC: ieee802154 radio api
It's a left-over. Just keep it that way. Drivers are setting the MTU took I agree. What bothers me is the IEEE802154_MTU of 127, the frameIs there any hw which is unable to do the chksum?
125 mostly due to net buf. (it's possible to reserve header part, not
tail part, and that was generating issuse)
Up to the driver to not write the fcs into buffer's data. (L2 does not
care about it anyway).
And anyway driver don't push bigger frames than what they are supposed
to, so the check in frame is really superfluous.
No I mean the promiscuous feature should be Kconfig set, and disabled byIt makes a difference what CCA mode the HW uses. It should beNot convinced to expose these 2.
Isn't this kind of test made out of any 15.4 network? (i.e.: does itIt would be turned off by default (return -ENOTSUPP). It is useful forWhat's the use case for it?
require L2? I don't think so).
Re: RFC: ieee802154 radio api
Ok, then I will implement the cca function, which then execute aFor example, if the hardware can automatically perform CCA before theNo. L2 has to call that, unless hw can perform part or all of the radio
ok I agree. What bothers me is the IEEE802154_MTU of 127, the frameIs there any hw which is unable to do the chksum?
length is 127 octets (including FCS field), should it not be 125?
> ...- IEEE802154_HW_LBT (listen before transmit or CCA before TX)Always enable it if the hw supports it, at built time.
It makes a difference what CCA mode the HW uses. It should be prescribedNot convinced to expose these 2.
somewhere or the L2 sets it to runtime.
For the threshold, the default value of the PHY may be ok.
You mean the timestamps should be inserted by the driver?Ok on that one. But it should be built time set feature.
okThat one we are missing yes. So it could be used once neighbors are
What's the use case for it?
commissioning the hardware and is required for the test during the CE or
FCC certification. Of course, there are tools from the manufacturers for
it, but they are usually not so nice and they are almost always bound to
an OS, which I do not want to use. Natively implemented, it is also
useful in driver development, e.g. to check whether PLL was set
correctly after the channel was switched or to test CCA :-). Mostly only
four modes are useful: Idle, continues RX, carrier wave, PRBS9. It must
be clearly marked that it is only for testing.
ok, got it :-)
Daily JIRA Digest
NEW JIRA items within last 24 hours: 2
[ZEP-1588] I2C doesn't work on Arduino 101
[ZEP-1586] menuconfig: Backspace is broken
UPDATED JIRA items within last 24 hours: 18
[ZEP-819] 6LowPAN-GHC: Generic Header Compression for IPv6
[ZEP-1103] Propose and implement synchronization flow for multicore power management
[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
[ZEP-1321] Glossary of Terms needs updating
[ZEP-878] 6LoWPAN - Unicast-Prefix based IPv6 Multicast (dst) address compression
[ZEP-1558] Support of user private data pointer in Timer expiry function
[ZEP-513] extern declarations of small microkernel objects in designated sections require __attribute__((section)) in gp-enabled systems
[ZEP-1561] Implement _tsc_read for NiosII
[ZEP-802] DNS Configuration Options for DHCPv6
[ZEP-1532] Wrong accelerometer readings
[ZEP-1579] external links to zephyr technical docs are broken
[ZEP-1566] WDT: Interrupt is triggered multiple times @ARC
[ZEP-1585] "legacy.h" should be disabled in "kernel.h" with CONFIG_LEGACY_KERNEL=n
[ZEP-1358] BMI160 accelerometer gives 0 on all axes
[ZEP-1587] sensor.h still uses legacy APIs and structs
[ZEP-1583] ARC: warning: unmet direct dependencies (SOC_RISCV32_PULPINO || SOC_RISCV32_QEMU)
[ZEP-1548] Python script invocation is inconsistent
[ZEP-1064] Fix wiki section coding standards/include paths
CLOSED JIRA items within last 24 hours: 11
[ZEP-801] (Fixed) DNS Extensions to support IPv6
[ZEP-1208] (Fixed) Create test for Timer kernel object using native unified kernel API
[ZEP-964] (Fixed) Add a (hidden?) Kconfig option for disabling legacy API
[ZEP-630] (Won't Do) Features support matrix for supported boards
[ZEP-1497] (Fixed) Cortex-M0 port exception and interrupt priority setting and getting is broken
[ZEP-1512] (Fixed) doc-theme has its own conf.py
[ZEP-872] (Fixed) Unable to flash Zephyr on Arduino 101 using Ubuntu and following wiki instructions
[ZEP-1370] (Fixed) There's a wiki page for arduino_due but no zephyr/boards support folder
[ZEP-1363] (Done) Missing wiki board support page for arm/arduino_101_ble
[ZEP-1443] (Fixed) Samples/net/zperf: Build fail as net_private.h can not be founld
[ZEP-1575] (Won't Do) Getting warning messages due to Macro SYS_LOG_DOMAIN defined in bmi160.h file
RESOLVED JIRA items within last 24 hours: 0
Daily Gerrit Digest
NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10168 : net: shell: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10169 : Bluetooth: Don't select TinyCrypt RNG for combined builds
- https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address
- https://gerrit.zephyrproject.org/r/10122 : net: tcp: remove unused semaphore tcp_lock
- https://gerrit.zephyrproject.org/r/10150 : net: ipv6: Fix IPv6 prefix comparision
- https://gerrit.zephyrproject.org/r/10152 : net: 6lo: Handle destination address uncompression properly
- 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/10149 : net: ipv6: Check neighbor pointer in NS reply timeout
- https://gerrit.zephyrproject.org/r/10148 : net: tcp: Allocate space for TCP header
- https://gerrit.zephyrproject.org/r/10147 : net: icmpv6: Removing dead code
- https://gerrit.zephyrproject.org/r/10146 : net: Fix possible null pointer dereference in nbuf
- https://gerrit.zephyrproject.org/r/10140 : tests/gpio: enable gpio cases to run on more platforms
- https://gerrit.zephyrproject.org/r/10139 : arm/nordic_nrf5: enable SOC_FLASH_NRF5 by default if FLASH is enabled
- https://gerrit.zephyrproject.org/r/10144 : net: tcp: add timeout wait in net_context_connect
- https://gerrit.zephyrproject.org/r/10142 : net: tcp: fix buffer leak in tcp_synack_received
- https://gerrit.zephyrproject.org/r/10143 : boards/pinmux: fix typo
- https://gerrit.zephyrproject.org/r/10141 : tests: fix invoke k_timer_stop issue inside timeout expiry_fn
- https://gerrit.zephyrproject.org/r/10138 : arm: set default vector table address in prep_c when XIP
- 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/10120 : sanitycheck: improve terse output
- https://gerrit.zephyrproject.org/r/10125 : build: remove obsolete sections from linker scripts
- https://gerrit.zephyrproject.org/r/10117 : doc: move context back to doc/, fix broken links
UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10093 : net/samples: HTTP server sample application
- https://gerrit.zephyrproject.org/r/10111 : Bluetooth: L2CAP: Fix always using RX_BUF_COUNT as initial credits
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/10077 : net: buf: introduce NET_BUF_ALIGNMENT macro
- https://gerrit.zephyrproject.org/r/10091 : net/mqtt: Add the testcase.ini file to the MQTT Publisher sample app
- https://gerrit.zephyrproject.org/r/10075 : net/mqtt: Add the MQTT Publisher sample application
- https://gerrit.zephyrproject.org/r/10074 : net/mqtt: Add the "malformed" callback to the MQTT ctx structure
- https://gerrit.zephyrproject.org/r/10072 : net/mqtt: Move upwards buffer size validation
- https://gerrit.zephyrproject.org/r/10073 : net/mqtt: Simplify the MQTT high-level API
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/6716 : Bluetooth: SDP: Server: Refactor data element structure header
- https://gerrit.zephyrproject.org/r/9692 : doc: Include main Network APIs doxygen documentation
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- 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/9964 : Xtensa port: Added board config files for Xtensa simulator paltform
- https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler
- https://gerrit.zephyrproject.org/r/9982 : drivers: spi: enable gpio driver automatically when needed
- https://gerrit.zephyrproject.org/r/9827 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9516 : drivers: Add Atmel SAM family GMAC Ethernet driver
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9680 : quark_se: Fix restore info address
- https://gerrit.zephyrproject.org/r/9980 : tests: include: Move timestamp.h into common location
- https://gerrit.zephyrproject.org/r/9681 : quark_se: Add shared GDT in RAM memory to linker
- https://gerrit.zephyrproject.org/r/9979 : kernel: sysclock: Add an API to get tick delta
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/9682 : quark_d2000: Add shared GDT memory to linker
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: shell: Add SDP client support
- https://gerrit.zephyrproject.org/r/8803 : benchmarks: boot_time: Move to unified kernel
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attrbute internals
- https://gerrit.zephyrproject.org/r/9714 : Bluetooth: shell: Add getting ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: shell: Add getting ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9717 : Bluetooth: SDP: Add getting A2SRC in BTshell
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: SDP: Use SupportedFeature attr API in BTshell
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- 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/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/9363 : arch: nrf5: Add option for enabling internal DCDC
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/9110 : test message: please ignore
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10124 : Makefile: Streamline building of CoAP-related projects.
- https://gerrit.zephyrproject.org/r/10131 : net: tcp: When retransmitting, hold an extra, temporary reference
- https://gerrit.zephyrproject.org/r/10119 : Bluetooth: SMP: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10116 : Bluetooth: L2CAP: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10115 : Bluetooth: conn: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10145 : Bluetooth: drivers/nble: Remove bogus BT_DBG manipulation
- https://gerrit.zephyrproject.org/r/10126 : echo_server: Remove unnecessary config from prf_frdm_k64f.conf
- https://gerrit.zephyrproject.org/r/10121 : Install pre-release SDK 0.9 on minions
- https://gerrit.zephyrproject.org/r/10118 : branch: add 'core' branch to verify jobs
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9937 : net: tcp: Get rid of `recv_mss` field from TCP struct
- https://gerrit.zephyrproject.org/r/9944 : net: tcp: Reduce size of `state` member from 32 to 4 bits
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added params to AVDTP Request structure
- https://gerrit.zephyrproject.org/r/9653 : net: slip: Do not remove fragments when sending data
- https://gerrit.zephyrproject.org/r/9929 : net: tcp: Ensure all timers are disposed of when releasing context
- https://gerrit.zephyrproject.org/r/9930 : net: tcp: Use an uint8_t for retry timeout instead of an uin32_t
- https://gerrit.zephyrproject.org/r/9936 : net: tcp: Remove unused `recv_ack` field from TCP context
- https://gerrit.zephyrproject.org/r/10110 : Bluetooth: L2CAP: Make sure state is correctly updated
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/10105 : samples: net: Fix DHCPv4 config options and run on its own thread
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/10104 : Bluetooth: hci_core: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10095 : Bluetooth: Add __printf_like annotation for bt_log
- https://gerrit.zephyrproject.org/r/10094 : Bluetooth: Take advantage of IS_ENABLED macro for BT_DBG
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/9703 : boards: prepare for integration of board documentation
- https://gerrit.zephyrproject.org/r/9960 : Xtensa port: Started port to for Xtensa cores family.
- https://gerrit.zephyrproject.org/r/8961 : drivers: QMSI AON counter: Simplify driver reentrancy code
- https://gerrit.zephyrproject.org/r/10099 : tests: do not use RC_OK, use 0 instead
- https://gerrit.zephyrproject.org/r/10108 : kernel: use __ticks_to_ms directly
- https://gerrit.zephyrproject.org/r/10101 : kernel: make legacy calls depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10100 : kernel: build legacy timer only conditionally
- https://gerrit.zephyrproject.org/r/10103 : kernel: include limits.h for UINT_MAX
- https://gerrit.zephyrproject.org/r/10102 : kernel: mailbox: legacy calls depend on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10097 : legacy: Move TICKS_UNLIMITED -> K_FOREVER
- https://gerrit.zephyrproject.org/r/10112 : tests: footprint: set ARCH correctly and provide defaults
- https://gerrit.zephyrproject.org/r/10113 : samples: legacy: enable legacy kernel
- https://gerrit.zephyrproject.org/r/10096 : legacy: use k_cycle_get_32 instead of legacy sys_cycle_get_32
- https://gerrit.zephyrproject.org/r/10114 : sensor: remove unused legacy macros
- https://gerrit.zephyrproject.org/r/10098 : net: zoap_client: fix usage of legacy APIs
- https://gerrit.zephyrproject.org/r/10107 : kernel: including legacy.h depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10109 : Bluetooth: IPSP: Reuse buffer fragments instead of copying
- https://gerrit.zephyrproject.org/r/10088 : riscv32: fix KConfig selection of ATOMIC_OPERATIONS_C
Re: [RFC]DMA API Update
Jon Medhurst (Tixy) <tixy@...>
On Wed, 2017-01-18 at 01:14 +0000, Liu, Baohong wrote:
Where? I can only assume you have in mind the things in?What you said is the scenario of driver over driver. There are existing examples
ext/hal/qmsi/drivers which is only occurrence of DMA in the Zephyr tree
I can find. Those drivers look hard coded for use on a single SoC and
have driver specific APIs for DMA, and nothing in-tree uses those APIs.
Also, there is no app in-tree that actually uses DMA apart from
test_loop_transfer which just does a simple memory-to-memory DMA test.
If the idea is that people should follow the Quark example, then it
looks to me that your saying DMA support in drivers is something
everyone has to design for themselves on a per-driver basis? If so,
there'll be no API consistency between drivers and every app will be
hard coded to a particular set of drivers.
But I can't believe that is what is intended, so I must have mis-
understood something fundamental.
Re: RFC: ieee802154 radio api
The transceivers can have different capabilities (csma, autoack ...).L2 behavior can avoid using any flags, at least for now (see below).
There is no reason to copy the way it's done elsewhere.
Moreover from Linux which really does not have the same constraints as
Not to say about the design obviously.
That said, current L2 does lack of some features below.
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time,
Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.
- IEEE802154_HW_LBT (listen before transmit or CCA before TX)Always enable it if the hw supports it, at built time.
- IEEE802154_HW_CSMA_PARAMSThat's when the hw support csma strategy on its own. Afaik, we don't
have any yet.
- IEEE802154_HW_FRAME_RETRIESUp to the driver to handle it. L2 does not have to care about it.
- IEEE802154_HW_AFILTAbout hw filtering I guess?
- IEEE802154_HW_PROMISCUOUSSee below, at the end of this mail.
- IEEE802154_HW_RX_OMIT_CKSUMSame as above about chksum on tx.
Is there any hw that cannot do cksum by itself and thus drop relevant
If not, then we can forget about it.
Always enable it if the hw supports it.
That said, if the hw does not support it, one will want the L2 to handle it.
It is handled currently, enabled at built time. But it does not mix at
all if we have 2 15.4 devices:
one supporting autoack, not the other.
But then again: is there any hw around that is unable to do such thing?
(At least for 15.4 >= 2012, I guess not many can do. But we are not
- IEEE802154_HW_RX_ACKREQ (RX ACK frame is expected after TX)Already handled. That's part of the radio strategy.
- IEEE802154_RF_TESTMODE (disabled by default, Modes: RX, CW, PRBS9 ...)For now the hardware are only 2.4Ghz. That will come when other band
will be supported.
Other suggestions and comments are welcome.No. If the device can do it, just enable it all the time.
I don't see any point in being able, at runtime, to play with it.
As long as there is no hw supporting it, no need to add that yet.
Not convinced to expose these 2.
Ok on that one. But it should be built time set feature.
driver/hw side, at built time. No need to play with it at runtime.
That one we are missing yes. So it could be used once neighbors are
But it means improving nbr management also. It's really not the biggest
No, that's set at built time. And imo, there is no point in playing with it.
For now it should be always enabled.
(will see when newer spec will have to be implemented)
What's the use case for it?
...As long as it's semantically relevant, and we don't export any code from
For now I don't see much point for exposing capabilities, besides maybe
the autoack one but I want
a real hw example that does not support it first. (pushing awai the
newer specs for now).
Point is, all drivers are exposing the same API. For instance, if it
does not support promiscuous mode, then
it sets the relevant api function pointer to NULL. If the user asks "set
promiscuous" (let's say through the 15.4 shell),
l2 verify that and return -ENOTSUPP accordingly. No need of any flag here.
Same for hw filtering etc etc... There is no need of checking any flag
Re: [RFC]DMA API Update
toggle quoted messageShow quoted text
-----Original Message-----I updated the RFC.
The sequence is dma_channel_config, dma_transfer_start, and then callback.
dma_transfer_stop is to abort an existing transfer.
?What you said is the scenario of driver over driver. There are existing examples
dma_slot is the one to dynamically connect a dma channel to a device. But, the
responsibility to prevent conflict is on user.