NuttX folks,

I have a collection of sensors that I need to poll fairly quickly (~1kHz). Traditionally, I'd just dedicate a timer and poll from the timer interrupt handler, or set the scheduling quantum to 1ms and use a high-priority thread to poll at every tick.

I'm curious as to whether some of the other NuttX primitives could be used to do this in a more canonical fashion. For example, the work_queue() interface looks interesting, but designed for longer-running workers that can be blocked, pre-empted, etc, and competition for the worker thread could easily lead to sensor data being lost.

Right now, since I'm running on STM32 it looks like the best approach is to extend the stm32_tim driver to support output compare interrupts on a timer, which I'm sure will work but is of course quite a platform-dependent solution.

Any thoughts?

= Mike

> I have a collection of sensors that I need to poll fairly quickly (~1kHz). Traditionally, I'd just dedicate a timer and poll from the timer interrupt handler, or set the scheduling quantum to 1ms and use a high-priority thread to poll at every tick.
>
> I'm curious as to whether some of the other NuttX primitives could be used to do this in a more canonical fashion. For example, the work_queue() interface looks interesting, but designed for longer-running workers that can be blocked, pre-empted, etc, and competition for the worker thread could easily lead to sensor data being lost.

The work queue is really intended to be a driver back-end. It is intended to support short processing and shouldn't really block (but, of course, may have to if necesssary.).

While the work queue was not planned to support periodic processing, it could. Work can be scheduled with a delay. If you reschedule the work each time with the same delay it will be periodic (but not exact).

> Right now, since I'm running on STM32 it looks like the best approach is to extend the stm32_tim driver to support output compare interrupts on a timer, which I'm sure will work but is of course quite a platform-dependent solution.

You don't say what kind of sensors you are polling. Analog signals? If so, the STM32 ADC supports collections of several samples periodically. If you drive the ADC with a timer, it can sample multiple sensors on each timer trigger.

That capability is already built into the NuttX STM32 ADC driver -- but it doesn't work yet for more than one signal. You have to have use DMA if you want obtain more than one sample per clock trigger. Otherwise, you will always get data overrun (if you set up to sample 3 signals, you will see the same value 3 times because the overrun).

Greg

Just to toss it out there (and I am well aware of the reasons on why not to do it) but with all these these 100+Mhz MCU's why not do something silly like crank it up to a 5 or 10Khz tick. Then with the added resolution you could possibly use more standard POSIX time calls and usleeps. You could make it as exact as your clock as long as your clocks were exact.

> That's definitely an option as well, though I was looking for something more like the BSD callout wheel or the Darwin timer_call interface just to keep things as light as possible (the CPU is largely spoken for already). I need to measure the actual cost of context switching to calibrate my expectations, I think - I may be trying to make things more complicated than necessary.

Context switches generated within interrupt handlers are quite efficient. In a context switch, you have to (1) save the register state of one thread, then (2) restore the restore state of another thread; that can be pricey. But in the interrupt handling, it has to do these same things anyway; the interrupt level context switch just plays a shell game so that when you return from the interrupt handler, you don't restore the state that you entered with, but instead the state of the new thread.

In fact, in most architectures, a user level context switch is also implemented with with a software interrupt that only plays the shell game.

So, for interrupt level context switches, the additional cost of a context switch is close to nothing.

[[If you use the STM32 F4 with floating point registers, however, then that will not be the case -- you will have to include the additional cost of saving and restoring floating point registers which would not have been done on the general interrupt handling case.]]

There are special, non-standard APIs that can be used to patch into the timer interrupt handler. There APIs are intended for use in device drivers but in an unprotected address space can be used anywhere: See http://nuttx.sourceforge.net/NuttxUserGuide.html#Watchdogs . Is this the kind of thing you are looking for?

But you shouldn't need to use those unless you want to. If you create a simple tasks that has an infinite sampling loop with usleep() at the top of the loop, you are using those watchdog APIs under the hood:

- usleep starts a watchdog time and sleeps.
- when the timer goes off, the watchdog callback runs at interrupt level, and
- usleep is awakened by one of those "efficient" interrupt level context switches
- then your loop executes and when it finishes, it calls usleep again

So that is basically the same thing, but using only standard interfaces.

There is a thread beginning here which talks more about timing facilities: http://tech.groups.yahoo.com/group/nuttx/message/1130

Greg

--- In nuttx-hHKSG33TihhbjbujkaE4pw@public.gmane.org, "Gregory N" <spudarnia <at> ...> wrote:
>
> NXWidgets is a commercial product that I have been co-developing over the past months. Unfortunately, it is not open source but it is still a resource that people developing NuttX based products should be aware of: http://nx-engineering.com/products.html

no problem mate,

You have contributed a lot to the embedded community with NuttX and nobody is denying you a chance to make a profit. My only suggestion is that you offer to sell a source code license for those risk adverse companies that may want to use it.

NuttX-6.14 was released today and is available for download here:

https://sourceforge.net/projects/nuttx/files/nuttx/nuttx-6.14/

nuttx-6.14 Release Notes

The 81st release of NuttX, Version 6.14, was made on January 15, 2012, and is available for download from the SourceForge website. Note that the release consists of two tarballs: nuttx-6.14.tar.gz and apps-6.14.tar.gz. Both may be needed (see the top-level nuttx/README.txt file for build information).

Note also that all SVN information has been stripped from these tarballs. If you need the SVN configuration, you should check out directly from SVN. Revision 4301 should equivalent to release 6.14:

* svn co -r4301 https://nuttx.svn.sourceforge.net/svnroot/nuttx nuttx

Post Release Patches:

* There are no post-release patches as of this writing.

New features in this release include:

* Drivers. The upper-half PWM driver will now support a pulse count (as would be needed to control a stepper motor).

* STM32. The CAN driver has been verified in loopback mode. ADC driver support for the STM32 F4. Add support for UART4-5 and USART6 (Contributed by Mike Smith). The PWM driver now supports a pulse count for TIM1 and TIM8. Timer driver now supports the F4's 32-bit timers (Contributed by Mikhail Bychek)

* STM32F4Discovery. Support for the STM32F4-Discovery board contributed by Mike Smith.

* STM3240G-EVAL. Add support for user control of LEDs.

* LPC17xx. Add support for loopback mode to CAN driver. CAN TX done perations are now interrupt driver. Now supports configurable CAN bit rate.

* LPC1766-STK. Add support for on-board buttons. Add support for user control of LEDs.

* LM3S. Add support for the LM3S6432S2E on the TI RDK-S2E (Contributed by Mike Smith)

* PIC32MX. USB device-side driver (needs further testing). A partial Ethernet driver is also in place.

* Library. Support added for fixed floating point fieldwidths in output formatting (Contributed by Mikhail Bychek)

* Build. New targets apps_clean and apps_distclean to simplify working with application diretories.

Bugfixes include the following.

* Drivers. Fixed a buffer-full test in the upper-half CAN driver.

* STM32. GPIO initialize logic (submitted by Mike Smith). Fix the debug logic that dumps the GPIO configuration.

* LPC17xxx. Correct an integeter overlow in GPIO interrupt setup (prevented pins > 15 from being used as interrupt sources). Correct a value used in GPIO interrupt number range test.

* FAT. Now returns the correct error value when it is unable to recognize the file system.

* Build. MAC OS build fixes (submitted by Mike Smith)

See the change log for more detailed information.

nuttx-6.14 ChangeLog

6.14 2012-01-15 Gregory Nutt <gnutt AT gnutt.org>

* tools/Makefile.export, mkexport.sh, and configure.sh. Changes submitted by Mike Smith to support configuration and 'make export' on MAC OS.
* arch/arm/src/stm32/stm32_gpio.c. Disabled interrupts while configuring GPIO pins so that we have exclusive access to the GPIO configuration registers.
* arch/mips/src/pic32mx/pic32mx_usbdev.c. Add a USB device-side driver for the PIC32MX family.
* arch/arm/src/stm32/stm32_gpio.c. Correct an error in some of the GPIO initialization logic. Fix submitted by Mike Smith.
* configs/olimex-lpc1766stk/src/up_leds.c. Add new interfaces so that is CONFIG_ARCH_LEDS are not set, the LEDs may be controlled from application logic.
* configs/olimex-lpc1766stk/src/up_buttons.c. Add support for the buttons on the Olimex LPC1766-STK board.
* Makefile. Added apps_clean and apps_distclean target to simplify managing the state of the application directory while in the NuttX directory
* Documentation/NuttXGettingStarted.html. Added a "Getting Started" Guide for NuttX. At present, this is just a stub and it refers to the NuttX top-level README.txt file which is the only, real "Getting Started" Guide that exists at the time being.
* arch/arm/src/lpc17xx/lpc17_gpioint.c. Correct an value used as the lower end of an IRQ number range test.
* arch/arm/src/lpc17xx/lpc17_gpio.c. Fix a integer flow problem in shift. This error would prevent pins > 15 from being used as interrupt sources.
* arch/arm/src/stm32/stm32_can.c. The CAN driver has been verified in loopback mode on the STM3240G-EVAL board.
* configs/stm3240g-eval/src/up_adc.c. Complete coding of ADC support for the potentiometer on board the STM3240G-EVAL.
* arch/arm/src/lpc17_can.c. Several CAN driver improvements. Adds support for testing in loopback mode. now uses all three transmit buffers for better performance.
* confgs/olimex-lpc1766stk/nsh. Now supports the CAN loopback test as an optional "built-in" application.
* sched/irq_attach.c. Fix an issue with disabling interrupts when they are detached. For the PIC32, this can't be done because there is a 1-to-many relationship between vector numbers and interrupt numbers or different. Added a new configuration option CONFIG_ARCH_VECNOTIRQ to at least flag the architectures that have this issue and to (at least) avoid doing something too wrong.
* drivers/can.c. Fix a test for buffer full in the generic, "upper half", can driver.
* arch/arm/src/lm3s. Add support for the LM3S6432S2E (Contributed by Mike Smith)
* configs/lm3s6432-s2. Add support for the TI RDK-S2E (LM3S6432S2E) board (Contributed by Mike Smith)
* configs/stm3240g-eval/src. Add APIs support to support user access to the LEDs
* arch/arm/src/lpc17xx/lpc17_can.c. Add logic to change the CAN bit rate based on the NuttX configuration.
* arch/arm/src/lpc17xx/lpc17_can.c. PCLK divisor is now a configuration option.
* arch/arm/src/stm32/stm32_serial.c and stm32_lowputc.c. Support for UART4-5 and USART6 added by Mike Smith. Also includes a more flexible way of managing UART pin configurations.
* include/nuttx/pwm.h, drivers/pwm.c, and arch/arm/src/stm32/stm32_pwm.c. Add support for pulse count in order to better support stepper motors.
* arch/arm/src/stm32/stm32_dumpgpio.c. Checking wrong register to see if GPIO is enabled. Also not adding the GPIO base address to several offsets.
* configs/stm32f4discovery. Port to the STMicro STM32F4Discovery board (Contributed by Mike Smith).
* fs/fat/fs_fat32util.c. On a failure to recognize a FAT file system, the mount logic should return -EINVAL, not -ENODEV.
* arch/arm/src/stm32/stm32_tim.c. Support for STM32 F4 32-bit timers (Contributed by Mikhail Bychek)
* lib/stdio/lib_vsprintf.c. Add support for fixed-size fields with floating point numbers (Contributed by Mikhail Bychek)

apps-6.14 ChangeLog

6.14 2012-01-15 Gregory Nutt <gnutt AT gnutt.org>

* apps/examples/buttons/main.c. The test needs to call up_buttoninit() to properly configure the button interrupt GPIOs.
* apps/examples/pwm. Add support to test the pulse count option recently added to the PWM interface.

Hi all:

I am trying to get started with NuttX, I thought I should just build it once with "./configure.sh sim/nsh" to get a first impression.

I am building on a 64-bit Ubuntu 10.04, so I got a weird assembler error about some jmp instruction.

I found out the solution in a README file, but if the NuttX build is known to fail on a 64-bit environment, some sort of user-friendly error message upfront would be nice.

Anyway, I've tried to apply this patch, which is mentioned in the same README file:

0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch

But that does not work either. At first look it seemed like white-space mismatches, but diff's option --ignore-whitespace did not work.

Thanks,
R. Diez

• New Members 1

> Anyway, I've tried to apply this patch, which is mentioned in the same README file:
>
> 0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch
>
> But that does not work either. At first look it seemed like white-space mismatches, but diff's option --ignore-whitespace did not work.

That patch is pretty old but still relevant. But since it is old, you may have to apply the patch manually by editing the files.

I have made this patch into permanent change because (1) I normally build the simulator under Cygwin which doesn't have the 32-/64-bit issues, and (2) the patch is really a work-around and a little more would be needed in a permanent change.

That basic problem is that the value LDFLAGS is "overloaded." LDFLAGS is only used in arch/sim/src/Makefile and it is used both with GCC and with LD:

Makefile:LDFLAGS = $(ARCHSCRIPT)
Makefile: <at> $(LD) -r $(LDFLAGS) $(LDPATHS) -o $ <at> $(REQUIREDOBJS) --start-group $(LDLIBS) --end-group $(EXTRA_LIBS)
Makefile: <at> $(CC) $(LDFLAGS) $(LDPATHS) -o $(TOPDIR)/$ <at> nuttx.rel $(HOSTOBJS) $(DRVLIB) $(STDLIB

So the correct fix will change these, perhaps defining a new CCLDLFLAGS which would include -m32 and be used only with $(CC) and LDFLAGS which would include -melf_i386 and only be used with $(LD).

If you want to manually apply the update and integrate this probably with arch/sim/src/Makefile, I will be happy to accept your patch and incorporate the changes into the NuttX SVN.

Greg

• New Members 1

> Anyway, I've tried to apply this patch, which is mentioned in the same README file:
>
> 0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch
>
> But that does not work either. At first look it seemed like white-space mismatches, but diff's option --ignore-whitespace did not work.

I just checked in all of the changes that should be required to build a 32-bit simulation executable on a 64-bit Linux target. The changes are basically the same as the the patch that you referred to.

I enable the changes by defining CONFIG_SIM_M32 in the .config file. That is awkward. It would be better if the 64-bit host machine were automatically detected and everything just worked right. Can anyone suggests a portable, foolproof way to know that I am running on a 64-bit Linux machine?

I am not working on a 64-bit Linux machine today so these changes are untested. I am using a Cygwin setup now and so I can't test these changes. If you would be kind enough to check out these changes from SVN and let me know if they work for you, I would appreciate it very much.

Greg

• New Members 1