drivers/power/bq2425x.c: The Battery Charger expects a battery_charger_dev_s not battery_charger_operations_s
drivers/power/bq2429x.c: The Battery Charger expects a battery_charger_dev_s not battery_charger_operations_s
1. lost data when receiving buffer is full;
2. low-water mask implement issue;
3. re-flush cdc buffer when enabling
4. serial dma is conflict with cdc , modify the serial.h
1. Configurable option to use named config items instead of enumerated ID/Instance numbers.
2. Ability to iterate through the existing configdata items in the /dev/config device.
3. Ability to "unset" a configdata item.
4. Ability to perform "flash_eraseall" on the /dev/config device.
sixlowpan: Fixes logic surrounding the Universal/Local bit. This bit represents whether the IID is locally/globally administered. The U/L bit is bit 1 of the MSB of the EUI-64. It should only be inverted in cases where there is a full EUI-64. In cases whe
* sixlowpan: Fixes logic surrounding the Universal/Local bit. This bit represents whether the IID is locally/globally administered. The U/L bit is bit 1 of the MSB of the EUI-64. It should only be inverted in cases where there is a full EUI-64. In cases where the IID is derived from say, a short address, this bit should be forced to 0, indicating that it is locally administered.
See:
https://tools.ietf.org/html/rfc4291#section-2.5.1https://tools.ietf.org/html/rfc4944#section-6https://tools.ietf.org/html/rfc2464#section-4
* sixlowpan: Account for endianness with U/L bit.
Approved-by: GregoryN <gnutt@nuttx.org>
arch/arm/src/tiva/hardware/cc13x0/cc13x0_fcfg1.h: Adjust cloned CC13x9 FCFG1 header file so that it reflects reality.
arch/arm/src/tiva/hardware/cc13x0/cc13x0_fcfg1.h: Add CC13x0 FCFG1 header file. Initial commit is the same as the CC13x2/CC26x2 FCFG1 header with a few name changes.
arch/arm/src/tiva/hardware/cc13x2_cc26x2/cc13x2_cc26x2_fcfg1.h: Initial FCFG1 header file for the cc13xx/cc26xx family.
The user of this invalidation are mmcsd_sdio currently. The mmcsd_sdio driver makes calls for dcache invalidation through the chip specific architecture function SDIO_DMARECVSETUP(). I changed the arch/arm/stm32f7 chips to use arch_invalidate_dcache_by_addr() instead of arch_invalidate_dcache().
This commit includes additional changes to mmcsd_sdio.c. I created SDIO_DMADELYDINVLDT() (DMA delayed invalidate) to invalidate store-into mode dcaches after the DMA transfer. I have been using SDIO_DMADELYDINVLDT() for several weeks now and it has fixed the problems that I previously reported regarding non-cache aligned buffer invalidation errors (for my store-through dcache). However, it does not permit use of unaligned DMA buffers for store-into mode dcaches.
SDIO_DMADELYDINVLDT() is a NoOp unless the chip specific Kconfig file selects CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT. I have modified all the stm32f7 chips to select it.
1. open CONFIG_DEBUG_FEATURES CONFIG_SYSTEM_TIME64 CONFIG_CLOCK_MONOTONIC
==> INITIAL_SYSTEM_TIMER_TICKS very big data, not zero
2. close CONFIG_SCHED_TICKLESS
==> use g_system_timer as system clock
3. pm_domain_s.stime init to zero
4. clock_systimer() - pm_domain_s.stime get big data, error
Pullreq FAT improvements
* NuttX: Add CONFIG_FAT_LFN_ALIAS_HASH to speed up creating long filenames.
Long filenames on FAT filesystems have associated 8.3 character alias
short filenames. The traditional form of these is FILENA~1.EXT with
a running count of the number of similar names. However creating this
unique count can take several seconds if there are many similarly named
files in the directory. Enabling FAT_LFN_ALIAS_HASH uses an alternative
format of FI0123~1.TXT where the four digits are a hash of the original
filename. This method is similar to what is used by Windows 2000 and
later.
* NuttX: Add CONFIG_FAT_LFN_ALIAS_TRAILCHARS alternative format for 8.3 filenames.
Traditional format for long filename 8.3 aliases takes first 6
characters of long filename. If this option is set to N > 0,
NuttX will instead take first 6-N and last N characters to form
the short name. This is useful for filenames like "datafile12.txt"
where the first characters would always remain the same.
* NuttX: FAT32: Fix file date corruption in fat_truncate().
* NuttX: if SD card wait seems to be a long one, give time for other threads to run.
Approved-by: GregoryN <gnutt@nuttx.org>
RNDIS composite support
* NuttX usb/composite.h: Forward-declare composite_devdesc_s.
This avoids "error: conflicting types for 'composite_initialize'"
on some versions of GCC. Because of the cross-inclusion between
usbdev.h and composite.h, the full declaration is not always
available.
* NuttX: USB Composite driver: Fix strid comparison
The last string ID used by composite driver is 4, and
the number of IDs used is 5 (0..4). The comparison
strid <= COMPOSITE_NSTRIDS caused composite driver to
reply with -EINVAL for id 5, even though it should be
available for subdevices to use.
* NuttX: RNDIS USB driver: Add support for composite configuration.
Approved-by: GregoryN <gnutt@nuttx.org>
These Microsoft-only descriptors help in loading the correct driver on Windows.
They are especially helpful to give libusb access to a custom device without
having to manually configure/install WinUSB driver.
With this change DFU interface works automatically on
Windows 10 with dfu-util 0.9 and libusb 1.0.22. On Windows 7
it still appears to need driver installation.
Xbee getset txpwr
* drivers/wireless/ieee802154/xbee: Minor improvements to debug facilities.
* drivers/wireless/ieee802154/xbee: Add support for setting/getting tx power.
TODO: The input/output arguments from the MLME primitive are intended to be an int32_t dbm value. However this change simply reports the power level register of the XBee. Need to add look-up table to back calculate the dbm value.
# Conflicts:
# drivers/wireless/ieee802154/xbee/xbee.c
Approved-by: GregoryN <gnutt@nuttx.org>
In addition to the problems that were previously identified there were a few other bits and pieces outstanding;
* Timing was dependent on CPU speed rather than absolute time
* End of transfer handling was a bit mixed up
* It's possible for data to still be in the FIFO (i.e. not have reached
the card) when a next write is requested, so we need to wait for that to
complete
* Interrupt Status could be carried over from one transfer episode to the
next, corrupting progress
* Multi-descriptor DMA writing simply wasn't implemented, but there were no
indications ... it just failed silently
