Post by Gregory Nutt
How do I in the system to hang in mmcsd0?
stm32f107vc memory only 64k, and I the configuration mkrd-s 128 64 can
/ Mnt directory will not be able to mount mmcsd0
I am not sure that I understand the connection betwen mkrd (make ram disk) and /dev/mmcsd0.
On boards that do not support SD card detection through a GPIO, the system
cannot know if there is an SD card in the card slot or not. The start up
logic assumes that there 'might' be a card present so the driver tries to
initialize it. The driver tries very hard. It times out and retries many
times. That is why it takes a long time to boot if you cannot detect if
there is a card in the SD slot or not.
That time could be improved, but has never been optimized.
Another think you can do is this: Don't initialize the SD card when you
boot, instead use apps/system/sdcard to look for the SD card later. Or you
can optimize the delay so that it is not so bad. Or you can disable MMC/SD
The sizes used in mkrd are in blocks. -s 128 specifies a block size of 128
bytes. 64 specifies 64 blocks. Then means it RAM disk will requires 128 x
64 = 8K of SRAM. That works right? But then mkfatfs does not work? What
error does it report?
Can I binfs to solve problems mount point?How do I do that?
apps/namedapps/binfs.c will not be useful to you. That is just another way
to access the NSH named applications. It uses apps/namedapp/namedapp_list.h
and namedapp_proto.h create a file system at /bin. binfs does not do
anything other than give you an alternative way to looked at the named
In addition, I configured
CONFIG_WATCHDOG = y
CONFIG_STM32_WWDG = y
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY = 20
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT = 49
CONFIG_EXAMPLES_WATCHDOG = y
After Generated nuttx.hex file size unchanged. nsh shell can not find
commands of wdog.
But the example / watchdog c language program is compiled. In my view
has also been added to the library of libapps.a.
Suspected correlation function (watchdog_main) is not referenced by the
program. Therefore, there is no real link this function.
Reading apps readme.Seems to prompt should be configured apps / namedapp
namedapp_list.h and namedapp_proto.h
Do not know that understanding is correct.
These two files is currently empty. So I do not know how to do that.
1. You need to have CONFIG_EXAMPLES_WATCHDOG and CONFIG_NSH_BUILTIN_APPS
defined in your .config file
2. During the build, there are several phases. One of the first phases is
called the context phase. During the 'make context' phase, the system
creates autogenerated files, symbolic links, etc.
During the 'make context' phase, apps/Makefile will execute 'make -C
examples context' and, if CONFIG_NSH_BUILTIN_APPS is defined,
apps/examples/Makefile will execute 'make -C watchdog context'.
3. In apps/examples/watchdog/Makefile is where information should have
been added to namedapp_list.h and namedapp_proto.h
APPNAME = wdog
PRIORITY = SCHED_PRIORITY_DEFAULT
STACKSIZE = 2048
If that is not working then you will need to debug it. Everything that you
need know is above.
One thing to remember is that this context phase is only executed one
time. After you 'make context', you cannot change the .config file and make
again. That will not work and is the source of constant confusion.
If you change the .config configuration file and want to rebuild the
make apps_disclean clean_context all
Otherwise, the namedapp_list.h and namedapp_proto.h will not be regenerated.
And, if all else fails, you can just manually edit namedapp_list.h and
namedapp_proto.h to add the required information.
In addition to the above functions.
I also need to test the ADC, DHCPC, WGET, Webserver, thttpd, telnetd
function, as well as the DNS.
DNS is not no need to configure?
If you use 'make menuconfig', then all of these options are available
under the Applications->netutils menu.
the nsh bound telnetd.Connection at the time, found the characters one
by one to jump out.Not smooth.Normal?
I thought NSH telnetd was pretty fast after those recent
optimizations/fixes to the recvfrom delay logic by Max Holtzberg. But most
of the transfers coming from the board will still be of only one character
per packet. This is discussed in some other emails on this forum. It is
caused because there is no buffering on the outgoing Telnet connection.
Each character is sent as it becomes available.