gmane.comp.embedded.nuttx

Re: Net poll logic fix

Gregory N — 2013-05-23T14:02:49

Hi, Max,


I have checked in the change to set POLLNVAL, but after studying the poll() description more carefully I did change poll() so that it will abort if a bad file descriptor is included in the descriptor set.

In the poll() description I see:

"POLLNVAL - The specified fd value is invalid. This flag is only valid in the revents member; it shall ignored in the events member."

"... poll() shall set the ... POLLNVAL flag in revents if the condition is true, even if the application did not set the corresponding bit in events."

"If none of the defined events have occurred on any selected file descriptor, poll() shall wait..."

"Upon successful completion, poll() shall return a non-negative value. A positive value indicates the total number of file descriptors that have been selected (that is, file descriptors for which the revents member is non-zero). A value of 0 indicates that the call timed out and no file descriptors have been selected...."

So the behavior if you provide a bad file descriptor to pol

Re: Net poll logic fix

Gregory N — 2013-05-23T13:30:38

Hi, Max,

I have checked the patches of both your last two messages.


0001-tcpecho-Don-t-allocate-dhcp_state-structure-when-no-.patch:  Not controversial.  That was an error I introduced in your last patch.  Some of the older, pre-C99 compilers that I work with will not handle data in C functions that is not declared before the executable statements.

0002-Ignore-negative-descriptors-in-pollfd-list.patch:  I did this slightly differently to avoid the 'continue'.  The logic should be the same.

Hmmm..  But according to POSIX definition (http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html), poll() should return POLLNVAL in revents if a file descriptor is bad.  I did not implement that in the check-in, but I am making that change now and will have it checked-in very soon.  It is not clear from that description if poll() should also return immediately???? I will assume not.


You are right.  Good find.  I debated using POLLIN instead of POLLRDNORM since nuttx does not prioritized inputs.  But POL

Net poll logic fix [1 Attachment]

Max Holtzberg — 2013-05-23T12:31:41

<*>[Attachment(s) from Max Holtzberg included below]

Hi Greg,

I think the net_poll logic should wakeup the poll logic with POLLRDNORM
instead of POLLOUT in the case of available data in readahead buffers.
See enclosed patch.

Max


<*>Attachment(s) from Max Holtzberg:


<*> 1 of 1 File(s) http://groups.yahoo.com/group/nuttx/attachments/folder/387569874/item/list 
  <*> 0003-Wakeup-poll-logic-with-POLLRDNORM-if-data-available-.patch

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    nuttx-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

Re: Re: Polling TCP echo server example [2 Attachments]

Max Holtzberg — 2013-05-23T10:09:26

Hi Greg,

thanks for you assistance!

Am 22.05.2013 16:07, schrieb Gregory N:
They are transmit timeouts from lm_ethernet.c
But as long as that does not close any connections its just ugly.

After some sleep I got it working this morning.
The poll call did not ignore negative file descriptors.
See enclosed patch.

Thanks,

Max

Re: Polling TCP echo server example

Gregory N — 2013-05-22T14:07:25


Hi, Max,


This are TCP timeouts?  Or receive/transmit timeouts?  For the latter, the Ethernet driver provides the time base with its "heartbeat" poll.  Perhaps there is a timing error in the poll.

This example seems similar to apps/examples/nettest (in that both echo data).  But I presume it serves some additional purpose?


This has to be a bug.  There are a pre-allocated number of callback structure determined by CONFIG_NET_NACTIVESOCKETS.

static struct uip_callback_s g_cbprealloc[CONFIG_NET_NACTIVESOCKETS];

These are put in the free list g_cbfreelist:

static FAR struct uip_callback_s *g_cbfreelist = NULL;

That is callback structure for each "active" socket.  Allocating a callback structure in uip_callbackalloc just takes the next free callback structure from the free list.  The error is reported when the free list is empty.

Notice that uip_callbackalloc has several aliases:

uip/uip_icmpping.c:#define uip_icmpcallbackalloc()   uip_callbackalloc(&g_echocallback)
uip/uip-tcp.h:#define uip_tcpcallba

Polling TCP echo server example [2 Attachments]

Max Holtzberg — 2013-05-22T14:19:31

<*>[Attachment(s) from Max Holtzberg included below]

Hi Greg,

I added a polling TCP echo server example to check if the network stack
behaves properly.
I was wondering why there are always txtimeouts on my LM3S6965-EK, so I
wrote this example based upon W.Richard Steven UNIX Programming book to
ensure correct usage of the socket API.
The timeouts still occur with this simple example.
Maybe the timeouts are not a problem because tcp connections don't get
closed from the hardware reset caused by the timeout?

While playing around with this example I discovered that if a
connection is closed from server side, the following error occurs:
uip_callbackalloc: Failed to allocate callback
I tried to figure out why it happens but could not get it work.

Max


<*>Attachment(s) from Max Holtzberg:


<*> 2 of 2 File(s) http://groups.yahoo.com/group/nuttx/attachments/folder/935095763/item/list 
  <*> 0001-Polling-TCP-echo-server-example-added.patch
  <*> 0002-LM3S6965-EK-Polling-TCP-echo-server-configuration-ad.patch

-

Re: UDP discover tool

Gregory N — 2013-05-21T19:18:42

Hi, Max,


I applied both patches and checked them in.  Thanks!

I am not too concerned about adding configurations, new chip logic, or new board logic to NuttX.  I am dedicated to keeping the FLASH/RAM footprint as small as possible.  However, adding more configurations does not increase the binary footprint.  It just adds more options and increases the size of the tarball.

Technically we know that the size of the tarball is not an important technical issue.  For a tiny RTOS, the nuttx tarball is already quite large and that size does intimidate a few of people.  However almost all of that size is in the arch/ and config/ directories, i.e., it is all chip-specific and board-specific support.  It is flexibility and optional support.  But the larger tarball does create some fear-factor and possibly biases some people against using NuttX who have not done their proper homework.

Thanks again,
Greg

UDP discover tool [2 Attachments]

Max Holtzberg — 2013-05-21T19:43:40

<*>[Attachment(s) from Max Holtzberg included below]

Hi Greg,

I added runtime configuration to the UDP discover tool.
I also added an example configuration for the lm3s6965-ek board, but
maybe it's too bloating to add such example configs.

Max


<*>Attachment(s) from Max Holtzberg:


<*> 2 of 2 File(s) http://groups.yahoo.com/group/nuttx/attachments/folder/1327515173/item/list 
  <*> 0001-Make-discover-daemon-runtime-configurable.patch
  <*> 0002-lm3s6965-ek-discover-example-configuration-added.patch

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    nuttx-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an

Re: Disabling /dev/ttyS0 alias for USB serial

Gregory N — 2013-05-21T14:14:30

Hi, Lorenz,


Careful how you define the problem because your definition of the problem with determine how you try to solve it.

The UART and USB CDC/ACM do not share any implementation logic other than the file drivers/serial/serial.c.  And within serial.c, the logic operates on separate device instances.  So it is unlikely that there is any confusion at the device level (i.e., /dev/ttyS0 being confused with /dev/ttyACM0).  Those devices just should not have anything in common.

But your symptom does suggest that there is some resource that is shared within the OS or within your application betwee the serial driver instances.  This sounds like some kind of deadlock condition.  Debugging the problem will require tracing through the logic until you find the point were the block occurs.

Can you define what "start[ing] something on /dev/ttyS0" means?  Does this mean starting an application from NSH?  What does it mean "on /dev/ttyS0"?  Do you mean that you start an application via NSH and the applicaton opens

Re: Bootloader

Max Holtzberg — 2013-05-21T11:48:46

Am 21.05.2013 11:10, schrieb Mike Smith:

Thanks for help,
I'll try that out.

Max



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    nuttx-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Bootloader

Mike Smith — 2013-05-21T09:10:45

The STM32 parts actually have a ROM-based bootloader that doesn't need the CONFIG_STM32_DFU defines, and the Stellaris bootloader is similar - there's no need to tweak the config for either of these, it "just works" (by design).  All that CONFIG_STM32_DFU does is reload the NVIC vector table address.

For an in-flash bootloader, most are happy just having the payload linked to run at the in-flash address; for this you just tweak the linker map to make space for the bootloader at the bottom of flash.

e.g. here's a snippet from an STM32F4 target that has a bootloader in the first 16KiB of flash:

MEMORY
{
    flash (rx)   : ORIGIN = 0x08004000, LENGTH = 1008K
    sram (rwx)   : ORIGIN = 0x20000000, LENGTH = 128K
    ccsram (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
}

 = Mike

On May 21, 2013, at 12:14 AM, Gregory Nutt <spudarnia-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> wrote:

Disabling /dev/ttyS0 alias for USB serial

Lorenz Meier — 2013-05-21T07:49:43

Hi Greg,

It's been a while, we've been quite busy attending conferences and on the application layer and going outdoors and flying things. I've got this config:


CONFIG_USART1_SERIAL_CONSOLE=n
CONFIG_USART2_SERIAL_CONSOLE=n
CONFIG_USART3_SERIAL_CONSOLE=n
CONFIG_UART4_SERIAL_CONSOLE=n

CONFIG_DEV_CONSOLE=n
CONFIG_DEV_LOWCONSOLE=n

CONFIG_CDCACM=y
CONFIG_CDCACM_CONSOLE=y


So essentially NSH via USB. The issue I face is that if USB is connected and I start something on /dev/ttyS0 (supposedly UART1), it starts on the USB console (or rather: It does not start, but blocks further operation of the USB console but also doesn't output anything on it).

I would in general think that re-ordering the /dev/ttySx devices according to which one the console currently is one is not helping (it has caused a lot of confusion and grief with our users), but in the case of the USB link it seems not even intended, since USB is already mapped to /dev/ttyACM0, right?

I did poke into the code, but I would appreciate guidance on w

Re: Bootloader

Gregory Nutt — 2013-05-20T22:14:52

Hi, Max,

The STM32 F1 has a bootloader that NuttX works with.  Look at these:

These architectures use the STM32 bootloader which is enabled with CONFIG_STM32_DFU:

$ cd configs/
$ find . -name defconfig | xargs grep _DFU=y
./stm3210e-eval/buttons/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/composite/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nsh/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nsh2/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nx/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nxconsole/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nxlines/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/nxtext/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/ostest/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/pm/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/usbserial/defconfig:CONFIG_STM32_DFU=y
./stm3210e-eval/usbstorage/defconfig:CONFIG_STM32_DFU=y
./stm3220g-eval/dhcpd/defconfig:CONFIG_STM32_DFU=y
./stm3220g-eval/nettest/defconfig:CONFIG_STM32_DFU=y
./stm3220g-eval/nsh/defconfig:CONFIG_STM32_DFU=y
./stm3220g-eval/ns

Bootloader

Max Holtzberg — 2013-05-20T23:45:35

Hi list,

I wonder if it is possible to use NuttX with a bootloader.
In my case the lm3s6965 has a preprogrammed serial loader in flash
but I think NuttX has to be linked with this loader in mind to run.

Is it possible to relocate portions of the OS to RAM and let NuttX
rewrite the flash itself?

I think a firmware upgrade mechanism integrated into the NuttX stack
would be useful.


Max


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    nuttx-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:

Re: Texas Stellaris series internal flash MTD driver

Gregory N — 2013-05-20T18:54:18

Hi, Max,


Thanks for the patch.  It has been incorporated and checked in.

I am glad that you decided to use an MTD driver.  Most contributed FLASH drivers use the ad hoc interface in include/nuttx/progmem.h.  That interface is still useful for FLASH that has sectors too large for a file system (or when you just want to overwrite an entire LFASH region).  But an MTD driver is much more flexible.

Greg

Texas Stellaris series internal flash MTD driver [1 Attachment]

Max Holtzberg — 2013-05-20T20:25:47

<*>[Attachment(s) from Max Holtzberg included below]

Hi Greg,

see enclosed patch.

Max


<*>Attachment(s) from Max Holtzberg:


<*> 1 of 1 File(s) http://groups.yahoo.com/group/nuttx/attachments/folder/1193807790/item/list 
  <*> 0001-MTD-driver-for-stellaris-series-added.patch

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    nuttx-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: CONFIG_NUTTX_KERNEL mode compile error when CONFIG_SCHED_ONEXIT=y

Gregory N — 2013-05-17T20:46:59

Ken,


Okay, I just pushed those changes as well.

Greg

git tags (was Re: Re: Bug fix: DMA regression for STM32 f10x)

llatil — 2013-05-17T20:34:39

  Greg,

Many thanks for having added tags in the GIT history !
They would be very useful should anybody need to dig in previous releases  (even back to v1.0...   :-)  ).

Thanks to Gerd also for his infos & best practices hints on GIT tags usage.

  - Laurent -

Re: Re: CONFIG_NUTTX_KERNEL mode compile error when CONFIG_SCHED_ONEXIT=y

Ken Pettit — 2013-05-17T18:10:56

Hi Greg,


--snip--
 and "nuttx/syscall/syscall_lookup.h", but not the updates to SYS_onexit in
"nuttx/include/sys/syscall.h".  This may be because in my original email, I
had the pathname of this file incorrect.  There are several (six)
references to SYS_onexit in that file which need to be updated also.

Ken

Re: CONFIG_NUTTX_KERNEL mode compile error when CONFIG_SCHED_ONEXIT=y

Gregory N — 2013-05-17T17:41:51


Hi, Ken,


Yes.  The kernel test space, .data, .bss and heap are protected.  Without an MMU, you cannot allocate pages from a common allocator and then use them for either kernel or user memory.  Well, technically you could do this with just an MPU, but the Cortex-M family MPUs only have 8 regions.  So it is really the limitation in the number of protect-able regions that prevents do ingthis.  Instead, NuttX has to use two separate allocators in this case:  A kernel mode allocator and a user mode allocator.


So you need to be careful which allocator you use.  In the kernel build, there are two families of allocators used by the kernel:

1) kmalloc, kzalloc, kfree, krealloc all allocate protected kernel memory
2) kumalloc, kuzalloc, kufree, kurealloc all allocate unprotected user memory.

The way the kernel code gets user memory is a little Rube Goldberg.  The user mode allocator links in the user .text space.  The kernel calls through a little vtable at the beginning of the user blob to allocate memory (s

Re: CONFIG_NUTTX_KERNEL mode compile error when CONFIG_SCHED_ONEXIT=y

Gregory N — 2013-05-17T17:18:41

Ken,

... snip ...

There is another way to fix this:

-"on_exit","stdlib.h","defined(CONFIG_SCHED_ONEXIT)","int","CODE void (*func)(int, FAR void *)","FAR void *
+"on_exit","stdlib.h","defined(CONFIG_SCHED_ONEXIT)","int","CODE void (*)(int, FAR void *)","FAR void *"

That will generate:

int on_exit(CODE void (*)(int, FAR void *) parm1, FAR void *parm2);

Which should work fine (and that is how all of the other function pointers are handled).


I have made the changes.  No patch needed.


If the frequency of system calls is low, then the overhead is tolerable.  The real issue is the following is those three I mention which occur at a very high rate:


I will probably make this latter change in the next few days because it is so easy.

Greg