lc823450 auto LED support
* arch/arm/src/lc823450: Add auto LED for CPU activity
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
* configs/lc823450-xgevk: Add auto LED support
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Approved-by: Gregory Nutt <gnutt@nuttx.org>
configs/stm32f429i-disco/ltdc: This configuration has been deleted because it violated the portable POSIX OS interface. It used apps/examples/ltdc and include ltdc.h and dma2d.h which were also removed for the same reason.
fs/userfs: This completes coding of the UserFS client and of the UserFS feature in general. This feature is being merged to main now because I believe it is innocuous. It is, however, untesed. The next step will be to develop a test case to verify the feature.
fs/userfs: Completes the request logic for the UserFS client. Still need the logic that receives the responses.
fs/userfs: Completes coding for most of the server side of the user filesystem logic.
fs/userfs: Big design changes, simplications. Use Unix domain local sockets instead of message queues. Easier to transfer big data in local sockets than message queues. Remove character drvier 'factory' it is not necessary.
fs/userfs: Minor reparitioning; volume private info does not need to be held on the OS client side.
libc/userfs: Add some of the server side logic.
fs/userfs: Add some UserFS initialization logic.
fs/userfs: Add frame work for the UserFS proxy. Remove all references to a block driver. There is no block dricer... what was I thinking?
fs/userfs: Add some initialization of the character driver, 'factory' device.
fs/userfs: Rename from fusefs to userfs to that we don't stomp on someone else's cool name.
Add a header file describing the fusefs interface.
Fix stm32 dmacapable on f20xx
* Fixed build for STM32F20XX platforms when CONFIG_STM32_DMACAPABLE is enabled
* Fixed build for STM32F20XX platforms when CONFIG_STM32_DMACAPABLE is enabled
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Port STM32F7 I2C driver to STM32L4
* arch/stm32l4: port STM32F7 I2C driver to STM32L4
STM32L4 I2C driver is in work-in-progress state (plentiful of
TODOs and #warnings) and lags many features found in more
up-to-date STM32 I2C drivers. The peripheral on STM32F7 and
STM32L4 are identical except for L4's 'wakeup from stop mode'
flag and STM32F7's I2C driver is in more 'ready to use' state.
Patch ports the STM32F7 I2C driver to STM32L4. The I2C clock
configuration is kept the same as before (I2CCLK = PCLK1 80 Mhz)
instead of switching to STM32F7 arch default that is I2CCLK=HSI.
Further work would be to add configuration option for choosing
I2C clock source instead of current hard-coded default.
* arch/arm/stm32f7: i2c: restore bus frequency after I2C reset
Copy frequency restoration fix from STM32L4 I2C driver to STM32F7 I2C driver.
* arch/arm/stm32f7: i2c: remove unused Kconfig option
* configs/nucleo-l496zg/nsh: enable I2C4 bus with i2ctool
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Master
* stm32_hrtim: fix warnings related with RCC
* stm32f33xxx_adc: add some publicly visable interfaces and some code to support injected channels
* stm32f33xxx_dma: add public interface to handle with DMA interrupts
* stm32_hrtim: change some names and add some coments
* chip/stm32f33xxx_adc.h: cosmetics
* nucleo-f334r8: add logic for zero latency high priority interrupts example
* stm32: update some ADC-related configuration in Kconfig
Approved-by: Gregory Nutt <gnutt@nuttx.org>
STM32L1, STM32L4 RTC: add periodic interrupts, update L1 RTC implementation
* STM32L4 RTC: add support experimental CONFIG_RTC_PERIODIC
* STM32 RTC: separate STM32L1 RTC into a separate file
STM32L1 RTC is very close to F4 or L4 versions, with two alarms
and periodic wakeup support so backported L4 peripheral to L1.
* RTC: add periodic alarms to upper and lower halves
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Master
* stm32f33xxx_adc.c: fix some warnings and compilation error when extsel not in use
* nucleo-f334r8/adc: change serial console to USART2 (STLINK COM)
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Lower part of STM32 CAN driver arch/arm/src/stm32/stm32_can.c uses all three hw tx mailboxes and clears TXFP bit in the CAN_MCR register (it means transmission order is defined by identifier and mailbox number).
This creates situation when order frames are put in upper part of CAN driver (via can_write) and order frames are sent on bus can be different (and I experience this in wild).
Since CAN driver API pretends to be "file like" I expect data to be read from fd the same order it is written. So I consider described behaviour to be a bug.
I propose either to set TXFP bit in the CAN_MCR register (FIFO transmit order) or to use only one mailbox.
Stm32 rtc small patches
* RTC: canceling an alarm marks it as inactive
* STM32L4, STM32F4, STM32F7 RTC: fix reading alarm value that is more than 24h in future
* STM32F0 RTC: fix backup register count in stm32_rtcc.h
All other STM32: SHIFTR_SUBFS_MASK was correct in STM32F0 only
* STM32L1: use correct EXTI line definitions
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Initial ADC support for the STM32F33XX
* stm32_adc.h: add JEXTSEL definitions and hrtim trigger configuration
* stm32_adc.c: move STM32F33 ADC logic to a separate file
Approved-by: Gregory Nutt <gnutt@nuttx.org>
STM32L4 small fixes to RTC
* STM32L4 RTC: init mode was never exited because nested locking in rtc_synchwait() disabled backup domain access
* STM32L4 RTC: use backup register magic value instead of INITS bit
The INITS (bit 4) of RTC_ISR register cannot be used to reliably
detect backup domain reset. This is because we can operate our
device without ever initializing the year field in the RTC calendar
if our application does not care about correct date being set.
Hardware also clears the bit when RTC date is set back to year 2000:
nsh> date -s "Jan 01 00:00:00 2001"
rtc_dumptime: Setting time:
rtc_dumptime: tm: 2001-01-01 00:00:00
rtc_dumpregs: New time setting:
rtc_dumpregs: TR: 00000000
rtc_dumpregs: DR: 00012101
rtc_dumpregs: CR: 00000000
rtc_dumpregs: ISR: 00000037
...
nsh> date -s "Jan 01 00:00:00 2000"
rtc_dumptime: Setting time:
rtc_dumptime: tm: 2000-01-01 00:00:00
rtc_dumpregs: New time setting:
rtc_dumpregs: TR: 00000000
rtc_dumpregs: DR: 0000c101
rtc_dumpregs: CR: 00000000
rtc_dumpregs: ISR: 00000027 <--- Bit 4 went missing!
...
This patch allows us to do:
stm32l4_pmstop(true);
/* Stop mode disables HSE/HSI/PLL and wake happens with default system
* clock. So reconfigure clocks early on Stop mode return.
*/
stm32l4_clockconfig();
without stm32l4_clockconfig() doing spurious and harmful backup domain
reset in rcc_resetbkp().
* STM32L4 RTC: put back the SSR race condition workaround
ST has confirmed that the issue has not been fixed, and that it applies
to STM32L4 too (was not in errata sheets due to documentation bug)
See discussion:
https://community.st.com/thread/43710-issue-with-rtc-maximum-time-resolution
* STM32F4, STM32L4, STM32F7 RTC: add more CONFIG_RTC_NALARMS > 1 to reduce code size
* STM32L4: rename stm32l4_rtcc.c to stm32l4_rtc.c to better match STM32F7
Cosmetic changes to comments
* STM32, STM32L4, STM32F7 RTC: stray comment and typos in chip/stm32_rtcc.h
* STM32L4 RTC: change maximum alarm time from 24h to one month
Approved-by: Gregory Nutt <gnutt@nuttx.org>
