Using external libraries with NuttX
Hello all, I am currently facing the problem of using external library with NuttX. The support is already prepared in mainline in directory external/ which is compiled if Kconfig and Makefile are present in the directory. This is all fine as I symlink my library to external/ directory so I get to compile the source code and have all the configuration I need. The directory looks somewhat like: external my_project Make.defs and Kconfig Kconfig and Makefile The problem is with the headers. If I use the same approach as in drivers/ or so libraries and add my headers to CFLAG, they are not accessible from an application. The only thing that works so far is adding the CFLAGs in top level Make.defs linked from the board directory; then the headers are exported and everything works fine. Is this the only possible solution so far or is there some other flag/approach how to do it more nicely? The ideal approach from my point of view would be not to edit top level Make.defs at all. Am I missing some additional flag? Thanks. Michal
Re: System time issue with external RTC
Hi, the right way to keep the system time in sync with external RTC is adjtime() function. https://man7.org/linux/man-pages/man3/adjtime.3.html NuttX also has its own implementation of adjtime() https://github.com/apache/nuttx/blob/master/sched/clock/clock_adjtime.c, so you can use it. Just enable CONFIG_CLOCK_ADJTIME option to include it into compiled functions. You will need some periodic calculations of time difference between adjtime and RTC clock in your application (some thread that wakes up from time to time) and then to call adjtime() to adjust the system clock. The function does not do time jump here, it just speeds up or slows down hardware timer to adjust the time. Best regards, Michal On 5/31/24 10:03, cheshmedzh...@gmail.com wrote: > Hi all, > > > > The testing conditions are: nuttx 2.12 runs on NUCLEO-U5A5ZJ-Q board. I have > high accurate external RTC connected to one of i2c busses. > > When system runs for a long time - 2-3 days or more the time returned by > date command is not accurate. When I reboot the system the system time > become accurate (this is normal it is adjusted with RTC in boot process). > > So, the question is: What is right way to keep system time in sync with > external RTC? > > > > Best regards > > > >
Access GPIO pins over Lua
Hello, has anyone tried accessing GPIO pins over Lua? I have tried LED example presented at NuttX workshop a year or two ago and userled driver is working fine, but using the same code on GPIO registered pin fails (assert on open). I suppose io.open is implemented only for userleds and does not work for GPIO? Thanks. Best regards, Michal Lenc
Re: PCF8575 driver for NuttX
Hi,
Perhaps I am too late to the discussion and some of those stuffs were
already said but I use PCF8575 on a custom board so I think a can help a bit
with that.
> I'm trying to access the PCF8575 device from my application on NuttX to
make it light up LEDs. I'm not really sure how to implement it, but this is
what I've got:
The easiest way if you want to use PCF8575 for LEDs is to register those as
GPIOs using CONFIG_GPIO_LOWER_HALF. First you have to initialize I2C and
register the expander (you can do it in BSP layer).
struct pcf8575_config_s g_pcf8575_cfg =
{
.address = PCF8575_I2C_ADDRESS,
.frequency = PCF8575_I2C_FREQ,
};
struct i2c_master_s *i2c;
struct ioexpander_dev_s *ioe;
i2c = sam_i2cbus_initialize(TWIHS0_BUS);
ioe = pcf8575_initialize(i2c, _pcf8575_cfg);
Then you can register the pins.
IOEXP_SETDIRECTION(ioe, 0, IOEXPANDER_DIRECTION_OUT);
gpio_lower_half_byname(ioe, 0, GPIO_OUTPUT_PIN, "led_red");
IOEXP_WRITEPIN(ioe, 0, 1);
etc.
The pin is registered as dev/led_red and you can access it from your
application using classic GPIO interface (take a look at examples/gpio).
Writing multiple pins is a bit trickier, you can use IOEXP_MULTIWRITEPIN but
this requires ioexpander_dev_s structure to be available in application
layer (which is possible, but you would have to do the whole
initialization in application layer and as someone already mentioned, this
might not be thread safe).
But accessing pins one by one should be straightforward with CONFIG_GPIO_
LOWER_HALF option. Hope this helps.
Best regards,
Michal Lenc
Re: RTC synchronization with system time
> You wouldn't really do this from application level, right? No, I don't want to do this from application level hence why I am looking for an alternative. NuttX also has function clock_resynchronize() that should solve the problem with time going backwards but not sure if it has ever been tested and used. Thank you for the link and issue about adjtime(), that seems like a good alternative and way to go. Best regards, Michal Lenc -- Původní e-mail -- Od: Gregory Nutt Komu: dev@nuttx.apache.org Datum: 21. 3. 2023 0:20:43 Předmět: Re: RTC synchronization with system time "You wouldn't really do this from application level, right? There is currently no POSIX-compatible application interface to do that. But you could implement a kernel thread that is started in your board initialization logic that can call clock_synchronize() according to whatever criteria you need. I suppose a standard kernel thread could also be implemented in sched/clock if such a one-size-fits-all solution can be imagined. You might check out logic in sched/clock for CONFIG_CLOCK_TIMEKEEPING. That is used primarily for adjusting the time to properly track time from NTP. Seems to me that that is essentially the same issue: Keeping two clocks in agreement. On 3/20/2023 4:20 PM, Michal Lenc wrote: > Hello all, > > > > NuttX offers a function clock_synchronize() that synchronizes system clock > with clock from RTC (internal or external). The synchronization is done > during board initialization and I suppose this can also be called from an > application level if required. However I was not able to find any > implementation that would automatically synchronize system time with > (correct) values from RTC if system clock drifts from real time. It seems > the only possible option is to "force" the synchronization by calling the > mentioned clock_synchronize() function periodically from application level. > > > > > What is your view on adding some sort of automatic synchronization that > would ensure system clock stays in sync with RTC (or at least error is less > than some value) even when i drifts away from "real time"? Quite simple > solution is to let clock_gettime() to update base time after N reads however > this would add some computation complexity to gettime (I2C communication > delay for external RTC etc.) and I am not sure if we really want this inside > clock_gettime(). > > > > > Best regards, > Michal Lenc > "
RTC synchronization with system time
Hello all, NuttX offers a function clock_synchronize() that synchronizes system clock with clock from RTC (internal or external). The synchronization is done during board initialization and I suppose this can also be called from an application level if required. However I was not able to find any implementation that would automatically synchronize system time with (correct) values from RTC if system clock drifts from real time. It seems the only possible option is to "force" the synchronization by calling the mentioned clock_synchronize() function periodically from application level. What is your view on adding some sort of automatic synchronization that would ensure system clock stays in sync with RTC (or at least error is less than some value) even when i drifts away from "real time"? Quite simple solution is to let clock_gettime() to update base time after N reads however this would add some computation complexity to gettime (I2C communication delay for external RTC etc.) and I am not sure if we really want this inside clock_gettime(). Best regards, Michal Lenc
Configuration of external RTC results in build error
Hello, there seems to be a possible build error hidden in configuration of external RTC. If configure CONFIG_RTC and CONFIG_RTC_EXTERNAL to use external RTC the build ends with following error: undefined reference to `up_rtc_initialize' This is caused by lines https://github.com/apache/nuttx/blob/master/sched/clock/clock_initialize.c#L 218 and https://github.com/apache/nuttx/blob/master/include/nuttx/arch.h#L2272 that declare and call function up_rtc_initialize which however I suppose is not used since external RTC is to be configured. This happens since pull request #5232 (https://github.com/apache/nuttx/pull/5232) which removed && ! defined(CONFIG_RTC_EXTERNAL) from files mentioned above. The quick fix so far is to add the constrain of disabled CONFIG_RTC_EXTERNAL back as suggested here (https://github.com/michallenc/incubator-nuttx/commit/bc04eb9 d891c44a6b41bb0badf34636e24e63b61). Some ideas or objections? I am not sure if there was not some other change that would require different configuration of external RTC. Best regards, Michal Lenc
Re: W25Nx NAND flash support
Hi, thank you all for your inputs and links. I will take a look into it. Best regards, Michal Lenc -- Původní e-mail -- Od: Simon Filgis Komu: dev@nuttx.apache.org Datum: 25. 2. 2023 14:43:33 Předmět: Re: W25Nx NAND flash support "Hi Michael, In addition, if you want to load your elf directly to the memory mapped flash storage, you need some flashloader for your debug tool. I can help with segger's flashloader if that is of interest. (dsk) https://www.segger.com/products/debug-probes/j-link/technology/j-link-dsk/ Simon -- Ingenieurbüro-Filgis USt-IdNr.: DE305343278 -- sent by mobile phone Alan C. Assis schrieb am Sa., 25. Feb. 2023, 14:29: > Hi Michal, > > There is some discussion about it here: > https://www.mail-archive.com/dev@nuttx.apache.org/msg04981.html > > and here: > https://lists.apache.org/thread/kh5t6fn24q97d3qxzthksld4l3jtw27c > > In a nutshell: > > 1) If parallel NAND Flash is used your MCU will need first the NAND > Flash controller driver. SPI and QSPI NAND are different story; > 2) NuttX needs the basic NAND Bad-Block search function infrastructure > (look nand_devscan() is not updating the bad-block table) > 3) NuttX needs a File System able to handle NAND Flash > > Currently there is no FS on NuttX able to handle NAND. > So you can port the CHFS from NetBSD or take a look at dhara > (https://github.com/dlbeer/dhara). > > Maybe LittleFS or SmartFS could be extended to handle NAND. > > BR, > > Alan > > On 2/25/23, Michal Lenc wrote: > > Hello, > > > > > > > > I am looking into usage of w25nx NAND flash communicating over QSPI. What > > is > > the current support of NAND flash memories in NuttX? I found out some > > warnings in drivers/mtd/README.txt regarding the lack of a file system > that > > > > could handle NAND memories but I am not sure if they are still actual or > > those problems were solved. There are some header files and source code > > files for NAND memory support but some of them seem to be incomplete > (like > > nand_initialize() function for example > > https://github.com/apache/nuttx/blob/ > > master/include/nuttx/mtd/nand.h#L105). > > > > > > > > > > Would the implementation of w25nx flash require some further involvement > in > > > > file system support or just the implementation of w25nx driver itself > > (similar to already implemented w25q NOR flash)? > > > > > > > > > > Thanks. > > > > Best regards, > > Michal Lenc > > > "
W25Nx NAND flash support
Hello, I am looking into usage of w25nx NAND flash communicating over QSPI. What is the current support of NAND flash memories in NuttX? I found out some warnings in drivers/mtd/README.txt regarding the lack of a file system that could handle NAND memories but I am not sure if they are still actual or those problems were solved. There are some header files and source code files for NAND memory support but some of them seem to be incomplete (like nand_initialize() function for example https://github.com/apache/nuttx/blob/ master/include/nuttx/mtd/nand.h#L105). Would the implementation of w25nx flash require some further involvement in file system support or just the implementation of w25nx driver itself (similar to already implemented w25q NOR flash)? Thanks. Best regards, Michal Lenc
Re: ADC device close and IRQ
Hi, > The easy option is to comment out the two calls, but I don't know if that' s > deemed acceptable, especially as other adc drivers do the same? I do not think this is correct since it is better to disable and detach the interrupt when we close the device. Instead I think the the enabling and attaching should be moved from sam_adc_ initialize() to sam_adc_setup() which is called every time the driver is opened from the application. Similar to SAMv7 ADC driver: https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam _afec.c#L845 This would ensure the interrupt is enabled and attached when the driver is opened and disabled and detached when it is closed. Best regards, Michal Lenc
Re: Wikipedia: "Proposal deletion of NuttX"
Hi Alan, as a former administrator on Czech Wikipedia I personally do not see a reason for a deletion. But it may be the standards on English Wiki are different, each language mutation has its own rules. What could help from my point of view would be an addition of "history" chapter or something like that and a deletion of the long lists of key futures, platforms and drivers. Those generally should not be included in a good Wikipedia article. If the readed wants to know for example all supported platforms he should refer to NuttX documentation. Still I do not see this as a reason to delete the page. For now I would reccomend to ask user MrsSnoozyTurtle on his talk page (https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle) what parts of the article does he consider to be promotional so we know what we need to change. Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev Datum: 21. 7. 2022 13:10:12 Předmět: Wikipedia: "Proposal deletion of NuttX" "Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki "
Re: Anyone using SAMv7 PWM?
Hello > CONFIG_EXAMPLES_PWM=y > CONFIG_PWM=y > CONFIG_SAMV7_PWM0=y > CONFIG_SAMV7_PWM0_CH2=y I used your configuration options and there indeed seems to be a problem. I also wasn´t able to get any PWM output if the driver was configured as a single channel with CONFIG_PWM_MULTICHAN disabled. The PWM works if CONFIG_ PWM_MULTICHAN is selected and CONFIG_PWM_NCHANNELS is set as 2 or more. So far I am not sure what causes this, my initial debugging did not reveal any issues: correct functions are called, correct pin is configured, value is written to correct registers etc. Or at least it seems to be correct. I will need to take a further look into this during a weekend. So far a quick workaround is to enable multiple channel support and set two or more channels. The additional channel does not need to have an actual output, if you set the channel number to 0 it will be skipped. I will let you know when I discover what causes this. The driver is mostly a derivate from imxRT PWM driver and single PWM worked fine there if I recall correctly. Best regards, Michal Lenc" "
Re: Anyone using SAMv7 PWM?
Hello, > Recently I've tried to use PWM on SAMe70 based board. I tried to execute > PWM example from apps. The PWM on SAMv7 seems to be not functional, at > least I observe only that pin goes high when PWM start is executed and the > goes to low when PWM stop is executed. what king of configuration have you tried? I tested the configuration same70 -xplained:pysim on a real time control of RC plant <https://gitlab.fel.cvut.cz/otrees/nuttx-demos/-/tree/master/ platforms/same70/rc-control> with SAM E70 Xplained board few days ago. You should be able to run a PWM example app in this config too. The pins setup in board level section can be found here: <https://github.com/apache/incubator-nuttx/blob/master/boards/arm/samv7/same 70-xplained/include/board.h#L345> I will double check tomorrow if the configuration does not work for you. Best regards, Michal Lenc -- Původní e-mail -- Od: Petro Karashchenko Komu: dev@nuttx.apache.org Datum: 16. 5. 2022 18:36:49 Předmět: Anyone using SAMv7 PWM? "Hello, Recently I've tried to use PWM on SAMe70 based board. I tried to execute PWM example from apps. The PWM on SAMv7 seems to be not functional, at least I observe only that pin goes high when PWM start is executed and the goes to low when PWM stop is executed. Is anyone using PWM with SAMv7 based board? Maybe I'm missing something? Best regards, Petro "
RE: Serial RX DMA polling
Hi David, > https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 that´s exactly what I was looking for, thanks! Best regards, Michal Lenc -- Původní e-mail -- Od: David Sidrane Komu: dev@nuttx.apache.org Datum: 7. 3. 2022 15:20:08 Předmět: RE: Serial RX DMA polling "Hi Michal, > rather from board level section Yes Have a look at this example. https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 -Original Message- From: Michal Lenc Sent: Sunday, March 6, 2022 2:38 PM To: dev@nuttx.apache.org Subject: Serial RX DMA polling Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc "
Serial RX DMA polling
Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc
Re: SPI with DMA on SAME70
Hello Simon, I had noticed your DMA fix PR (https://github.com/apache/incubator-nuttx/ pull/5513) so I tested it with HSMCI SD card interface. There are still some problems when I undef HSCMI_NOTXDMA at https://github.com/apache/incubator- nuttx/blob/master/arch/arm/src/samv7/sam_hsmci.c#L122. The card unmounts itself as soon as I try to write to it with 'echo' command. I think this might be quite a different problem that can be sam_hsmci.c related as some other TX DMAs are working. I tested DMA with SPI and it works (althought I can write only to one half of the display but that might be some my problems in configuration if all your tests were fine) as well as DMA with USB device. I will take a look into HSCMI with DMA in the future, currently more critical problem for our implementation at Elektroline.cz company is DMA support for U(S)ART. That will also be a nice way to find if there are some further DMA TX bugs. Best regards, Michal Lenc -- Původní e-mail -- Od: Simon Filgis Komu: dev@nuttx.apache.org Datum: 14. 2. 2022 16:33:32 Předmět: Re: SPI with DMA on SAME70 "Dear all, I started to follow up this topic. Found that one in sam_hsmci.c: /* There is some unresolved issue with the SAMV7 DMA. TX DMA is currently * disabled. */ #undef HSCMI_NORXDMA /* Define to disable RX DMA */ *#define HSCMI_NOTXDMA 1 /* Define to disable TX DMA */* That fits my (and Michael Lenc's) experience that DMA peripheral to memory works. Memory to the peripheral seems broken though. I will therefore debug *sam_xdmax.c*. Even if I find some odd comments on DMA timeouts in sam_spi.c. If anybody has a better idea, or remembers details ;), please give feedback. BR, Simon -- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278 On Tue, Feb 8, 2022 at 11:52 AM Simon Filgis wrote: > Dear all, > > I'm using ST7789.c in combination with lvgl-lib. > > The bottleneck to the display is the SPI communication. But even if I > increase the SPI frequency to 24MHz, it does not get faster. This is > because of constant delay between the bytes. > > I guessed that this can be improved using DMA. But that does not seem to > work out of the box. In the SPI TX callback the result of the DMA transfer > is -4. The transfer is not executed. > > Can anybody give me a hint on what to do? > > Best regards, > > Simon > > -- > Hard- and Softwaredevelopment Consultant > Ingenieurbüro-Filgis > USt-IdNr.: DE305343278 > "
Re: SPI with DMA on SAME70
Hello Simon, I did take a look into SPI driver for SAME70 a few months ago. The one thing that was a little bit weird to me was the lack of DMA flags passed to sam_ dmachannel() function (somewhere here https://github.com/apache/incubator- nuttx/blob/master/arch/arm/src/samv7/sam_spi.c#L2043) compared to the flags I needed to select for ADC DMA support to function correctly (https:// github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam_afec.c# L1125). I didn't invest more time into it as we had other priorities back then and I think we sticked with SPI without DMA. But it could be one of the problems. You can also take a look into sam_afec.c file, the DMA is working fine there. Hope this helps. Best regards, Michal Lenc -- Původní e-mail -- Od: Simon Filgis Komu: dev@nuttx.apache.org Datum: 8. 2. 2022 11:52:38 Předmět: SPI with DMA on SAME70 "Dear all, I'm using ST7789.c in combination with lvgl-lib. The bottleneck to the display is the SPI communication. But even if I increase the SPI frequency to 24MHz, it does not get faster. This is because of constant delay between the bytes. I guessed that this can be improved using DMA. But that does not seem to work out of the box. In the SPI TX callback the result of the DMA transfer is -4. The transfer is not executed. Can anybody give me a hint on what to do? Best regards, Simon -- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278 "
Re: Implementing QSPI driver in SPI mode
Hi, yes, I think the code duplication should not be that bad. Having separate drivers sam_spi.c for classic SPI, sam_qspi.c for QSPI in serial memory mode (current implementation) and sam_qspi_spi.c or something like that for SPI over QSPI would be an option then. Thanks. Best regards, Michal Lenc -- Původní e-mail -- Od: Gregory Nutt Komu: dev@nuttx.apache.org Datum: 15. 10. 2021 0:01:34 Předmět: Re: Implementing QSPI driver in SPI mode "> > The QSPI would need to support the SPI interface defined in struct spi_dev_s > in order to ensure compatibility with existing applications and drivers (LCD > displays for example) which use SPI. The option would be to add this > structure next to qspi_dev_s in arch specific drivers (in SAM case here > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam > _qspi.c#L159) and implements the specific SPI operations (send, exchange, > command/data etc.) in that file. The driver would then access either qspi_ > dev_s structure or spi_dev_s structure based on the configuration option for > the chip and would operate with that structure. Would this be a suitable > option or were there some other plans regarding implementing SPI functions > to QSPI? Thanks I would be inclined to implement this as a separate SPI driver rather that to try to make the QSPI driver to both roles. That would be cleaner and much less complex. I think that the amount of code duplication would not be very much since there is not a lot of overlap in data structures, interface functions, etc. INVIOLABLES.md: "Sometimes Code Duplication is OK" "
Implementing QSPI driver in SPI mode
Hello all, some chips from SAME70 family (J21 for example) do not have an SPI driver but use QSPI that can be run either in serial memory mode or in Master SPI mode. The config options in samv7 arch seems to be already prepared for that as SAMV7_QSPI_IS_SPI is selected for some chips but current sam_qspi.c implements only serial memory mode. There seems to be no working example of QSPI working as SPI in NuttX generally (all the implementions seems to be written just for the memory access) so I´d like to consult which implementation is prefered as I am not sure whether some similar discussions took place in the past. The QSPI would need to support the SPI interface defined in struct spi_dev_s in order to ensure compatibility with existing applications and drivers (LCD displays for example) which use SPI. The option would be to add this structure next to qspi_dev_s in arch specific drivers (in SAM case here https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam _qspi.c#L159) and implements the specific SPI operations (send, exchange, command/data etc.) in that file. The driver would then access either qspi_ dev_s structure or spi_dev_s structure based on the configuration option for the chip and would operate with that structure. Would this be a suitable option or were there some other plans regarding implementing SPI functions to QSPI? Thanks Best regards, Michal Lenc
Re: Possibility of merging few lcd drivers into one file
Hi, > I think this is a good idea, case they are really similar and you don't need to use tons of #ifdef. I think few of the #ifdefs would be used in pre processor definition section as It would be great to let predefined displays resolutions but other than that there should not be many of them. I will get into this perhaps later this week or during the next, firstly I want to figure out what went wrong with Tickless Mode for iMXRT (desrcibed here https://github.com/apache/ incubator-nuttx/issues/4442). Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev@nuttx.apache.org Datum: 30. 8. 2021 15:22:21 Předmět: Re: Possibility of merging few lcd drivers into one file "Hi Michael, I think this is a good idea, case they are really similar and you don't need to use tons of #ifdef. Other driver that needs some care is the OLED SSD1106/SSD1306, there are many entries in the menuconfig for the same driver. It is using some specific manufacturer name instead of the IC controller. BR, Alan On 8/30/21, Michal Lenc wrote: > > Hi all, > > > > > I was taking a look into the current state of files for LCD drivers > (drivers/lcd/) and I am wondering about your opinion about this. Is there > any particulal reason not to merge few of those drivers into one file? I am > > talking mostly about merging files st7735.c, st7789.c and st7796.c (not > merged into mainline yet, just in my repo) into file st77xx.c (and do the > same with header files). It still could be configurable in menuconfig > separately as ST7735 or ST7789, but source codes would be in one file. It > should not be that hard to change this as st7789.c and st7796 are mostly > copies of st7735.c. Perhaps drivers for ST7565 and ST7567 could be also > merged into ST75XX, but that would take more job as the source codes seems > to be different. Thanks > > > Best regards, > Michal Lenc "
Possibility of merging few lcd drivers into one file
Hi all, I was taking a look into the current state of files for LCD drivers (drivers/lcd/) and I am wondering about your opinion about this. Is there any particulal reason not to merge few of those drivers into one file? I am talking mostly about merging files st7735.c, st7789.c and st7796.c (not merged into mainline yet, just in my repo) into file st77xx.c (and do the same with header files). It still could be configurable in menuconfig separately as ST7735 or ST7789, but source codes would be in one file. It should not be that hard to change this as st7789.c and st7796 are mostly copies of st7735.c. Perhaps drivers for ST7565 and ST7567 could be also merged into ST75XX, but that would take more job as the source codes seems to be different. Thanks Best regards, Michal Lenc
Option to break for loop in PWM driver code by -1 channel number
Hello,
the PWM driver currently uses channel number 0 for channels that are not
supposed to be used. During the meeting for Google Summer of Code project
NuttX Support for Rapid Control Applications Development with pysimCoder
(information about the project can be found here https://cwiki.apache.org/
confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+
Applications+Development+with+pysimCoder) with Professor Bucher and Dr. Píša
we discussed an option to add channel number -1 as a "stop" value. That
would indicate that it is not necessary to check the other channels and that
they all can be skipped. This can be useful when for example just one
channel out of x is used and thus there is no need to waste time by checking
the others. The example of the code can be found here <https://github.com/
michallenc/incubator-nuttx/blob/teensy-dc/arch/arm/src/imxrt/imxrt_flexpwm.
c#L920>. The key part is:
for (int i = 0; ret == OK && i < CONFIG_PWM_NCHANNELS; i++)
{
/* Enable PWM output for each channel */
if (info->channels[i].channel == -1)
{
break;
}
if (info->channels[i].channel != 0)
{
...
The advantage is that this addition would not damage current drivers or
already developed applications in any way but would just add the possibility
to break the loop from the application level code. It would be great if the
options like 0 and -1 would be standardized and documented somewhere
(probably extend this page https://nuttx.apache.org/docs/latest/components/
drivers/character/pwm.html).
If there is no major problem with adding -1 as a "stop" value to all PWM
drivers I can create a PR during the following days.
Best regards,
Michal Lenc
Using PWM with less channels than defined in CONFIG_PWM_NCHANNELS
Hello, currently most of the PWM drivers (STM32, NRF52, iMXRT etc.) use for loop from 0 to CONFIG_PWM_NCHANNELS when setting multiple channels in function pwm_start, for example here in STM32 code <https://github.com/apache/ incubator-nuttx/blob/master/arch/arm/src/stm32/stm32_pwm.c#L4386>. This works fine when CONFIG_PWM_NCHANNELS is equal to the number of used channels, but there can be situations when less channels are used. For example if I configure PWM1 with 2 channels and PWM2 with 3 channels, CONFIG _PWM_NCHANNELS would have to be 3, but that would mean the loop would go from 0 to 3 also for PWM1 instead of just from 0 to 2. This resulted in hard fault when I tried something similar in an application designed in pysimCoder as info->channels[2].channel is not defined because channel 3 is not used for PWM1. I was thinking about adding something like int used_channels; to include/ nuttx/timers/pwm.h <https://github.com/apache/incubator-nuttx/blob/master/ include/nuttx/timers/pwm.h#L137> and then defined number of used channels in the application (the same way as defining frequency, channel number and duty cycle) rather than to have a global definition CONFIG_PWM_NCHANNELS. That would also mean replacing the for loops in pwm_start function (and maybe some other lines of code) so there would be something like "for (i = 0; ret == OK && i < info->used_channels; i++)" instead of "for (i = 0; ret == OK && i < CONFIG_PWM_NCHANNELS; i++)". The tricky part of this is multiplatform change that would probably result in some bugs that I would not be able to test as I don´t have all the boards with those MCUs. Or am I missing something and using less channels than defined in CONFIG_PWM_NCHANNELS should actually work? Thanks for your inputs. Best regards, Michal Lenc
Re: Tickless mode for iMXRT MCU
Hi Greg, thanks for your advices. > If you use 32.768KHz clock source, then there is a small error in every > time conversion since 1/32768 cannot be represented in microseconds. > Normally, this will result in small errors as you have noted. However, > in a very busy system with man timers, that error builds up and can be > quite large... like 50% error! See the above reference. I managed to find the (hopefully) right clock value for the GPT timer. If I use peripheral clock at 16.6 MHz (which is already the set value for iMXRT MCU) as a clock source, this value can be divided by 1660 prescaler for 100 usec CONFIG_USEC_PER_TICK or by 166 prescaler for 10 usec CONFIG_USEC_PER_ TICK. Both values would mean that the clock frequency of GPT timer is equal to CONFIG_USEC_PER_TICK (or to its frequency more precisely). I did some tests and it seems that those inaccuracies I was having with 32.768 kHz clock source are not a problem now. I will do some further tests before creating the PR thought. Best regards, Michal Lenc
Re: Tickless mode for iMXRT MCU
Hi Alan, thanks for the link! I will take a look into it. Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev@nuttx.apache.org Datum: 11. 7. 2021 16:19:59 Předmět: Re: Tickless mode for iMXRT MCU "Hi Michal, Please take a look at this wiki page, it could help you to understand the issue with sleep take one more context switch cycle: https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays Unfortunately the Timer Hook that could help you in this case will not work in Tickless mode (according with the wiki). BR, Alan On 7/11/21, Michal Lenc wrote: > > Hello, > > > > > I´ve finished the implementation of tickless mode support for iMXRT MCU, > which is a part of my Google Summor of Code project (https://cwiki.apache. > org/confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+ > Applications+Development+with+pysimCoder). The source code can be found > here > in my NuttX fork (https://github.com/michallenc/incubator-nuttx/blob/imxrt - > tickless/arch/arm/src/imxrt/imxrt_tickless.c), I used the alarm option to > take the advantage of using just one timer running in free-run mode. I did > some tests with applications (ADC reading example and control application > of > DC motor designed with pysimCoder) and they are working fine, but command > "sleep" bothers me a little bit. > > > > > When I compile normal NuttX nsh configuration with tickless mode, "sleep 2" > > is accurate and takes about 2.0001 seconds. But when I use some bigger > configuration (like configurating PWM, qencoder, GPIO, ethernet and so on > for DC motor control), "sleep 2" is much less accurate. Sometimes it really > > takes 2 seconds, but sometimes I get values like 1.9947 (I am using "time" > command). I did found out that sleep command takes one tick more in normal > mode, can some of those inaccuracies also happen in tickless mode? > > > > > The other source of the inaccuracy can be in clock frequency. I use 32 kHz > clock source, but this value cannot be properly represented by CONFIG_USEC _ > PER_TICK, which I set to 31 (which is aproximately 32.25 kHz). But 32 kHz > clock source seems to be the only possible in iMXRT as others are to hight > (tens or hundreds of MHz) and can´t be represended by the timer prescaler > divider. Did anyone have similar problems when implementing tickless mode > for some platforms? > > > > > Thanks for your inputs. > > > Best regards, > Michal Lenc "
Tickless mode for iMXRT MCU
Hello, I´ve finished the implementation of tickless mode support for iMXRT MCU, which is a part of my Google Summor of Code project (https://cwiki.apache. org/confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+ Applications+Development+with+pysimCoder). The source code can be found here in my NuttX fork (https://github.com/michallenc/incubator-nuttx/blob/imxrt- tickless/arch/arm/src/imxrt/imxrt_tickless.c), I used the alarm option to take the advantage of using just one timer running in free-run mode. I did some tests with applications (ADC reading example and control application of DC motor designed with pysimCoder) and they are working fine, but command "sleep" bothers me a little bit. When I compile normal NuttX nsh configuration with tickless mode, "sleep 2" is accurate and takes about 2.0001 seconds. But when I use some bigger configuration (like configurating PWM, qencoder, GPIO, ethernet and so on for DC motor control), "sleep 2" is much less accurate. Sometimes it really takes 2 seconds, but sometimes I get values like 1.9947 (I am using "time" command). I did found out that sleep command takes one tick more in normal mode, can some of those inaccuracies also happen in tickless mode? The other source of the inaccuracy can be in clock frequency. I use 32 kHz clock source, but this value cannot be properly represented by CONFIG_USEC_ PER_TICK, which I set to 31 (which is aproximately 32.25 kHz). But 32 kHz clock source seems to be the only possible in iMXRT as others are to hight (tens or hundreds of MHz) and can´t be represended by the timer prescaler divider. Did anyone have similar problems when implementing tickless mode for some platforms? Thanks for your inputs. Best regards, Michal Lenc
Re: Troubles with CAN bus on STM32 Nucleo-F446RE
Hi, I contributed the board level CAN driver support for Nucleo F446RE board few months ago and I did some tests of receiving and transmitting CAN messages with a low cost WCMCU-230 transceiver (https://www.aliexpress.com/item/ 32686393467.html). It was working fine, actually if you configure and compile ./tools/configure.sh nucleo-f446re:can and run an example application "can", it should send 100 messages over CAN1 (RX PB_8 pin, TX PB _9 pin) unless there were some recent major changes to STM32 CAN driver. If I remember correctly, I noticed some problems when the application was in read and write mode instead of just single read or single write mode. I am not sure whether it was the same problem you describe as it was some time ago. I also did small tests with pysimCoder using maxon motor CAN block and it was also transmitting messages without any obvious problems. I haven´t tried receiving thought. I hope this helps. Best regards, Michal Lenc -- Původní e-mail -- Od: Roberto Bucher Komu: dev@nuttx.apache.org Datum: 7. 7. 2021 17:23:35 Předmět: Troubles with CAN bus on STM32 Nucleo-F446RE "Hi I'm trying to send messages using the CAN bus on the nucleo-f446re. The RX and TX of the STM32 is connected to a MIKROE transceiver (the same working without problems with the nucleo-STM32F746ZG board, but the bus stop after 8 messages (I think that stops because of the full output buffer...) Does somebody reaches to communicate with CAN bus using this board? Thanks in advance BR Roberto "
iMXRT boards linker scrips
Hi everyone, I was taking a look into Teensy 4.x ld scripts. They are mainly copied from imxrt1060-evk and they seem to be working fine, but I´ve run into some problems during recent work on imxrt_flexcan <https://github.com/michallenc/ incubator-nuttx/commits/can-rewrite/arch/arm/src/imxrt/imxrt_flexcan.c> so I ´ve also checked ld scripts. Pavel Píša sugested to change section alignement to 16 byte and to remove _eronly = ABSOLUTE(.); as it might couse free space after alignement. We also added _eronly = LOADADDR(.data); after data sections. The whole change is in this commit <https://github.com/ michallenc/incubator-nuttx/commit/77a1c157907eff75e514125c5be09a2671342cae> (do not mind the changes in memory size). The question is we are not sure whether these changes are actually correct (my problems with CAN were coused by my mistakes during rewrite process and wer not related to ld scripts). It seems there is no change in running NuttX on Teensy with old or new ld scripts. It would be great if someone with more understading of binutuls could shed some light into this. If these changes are correct, then they should be also made into imxrt1060-evk, imxrt1050-evk and imxrt1020-evk aswell. PS: There has been some discussion about NuttX being involded in GsoC under Apache flag, was there any further development? Best regards, Michal Lenc
