WIP: Documentation: replace first person perspectives
Documentation containing first person perspective phrasing may be understood as belonging to a single person project (instead of a community project).
This commit is contained in:
Lars Kruse
Xiang Xiao
parent
9520f5bfc8
commit
ccc974b224
19 changed files with 85 additions and 87 deletions
|
|
@ -24,9 +24,9 @@ the display. This only works for ``RGB23`` (``888``), ``RGB16`` (``656``), ``RGB
|
|||
|
||||
How was that run-length encoded image produced?
|
||||
|
||||
1. I used GIMP output the image as a ``.c`` file.
|
||||
2. I added some C logic to palette-ize the RGB image in the GIMP ``.c`` file.
|
||||
3. Then I add some simple run-length encoding to palette-ized image.
|
||||
1. Use GIMP to output the image as a ``.c`` file.
|
||||
2. Add some C logic to palette-ize the RGB image in the GIMP ``.c`` file.
|
||||
3. Then add some simple run-length encoding to palette-ized image.
|
||||
|
||||
But now there is a tool that can be found in the NxWidgets package at
|
||||
``NxWidgets/tools/bitmap_converter.py`` that can be used to convert any graphics
|
||||
|
|
|
|||
|
|
@ -260,7 +260,7 @@ Work-Arounds
|
|||
Build Issues
|
||||
............
|
||||
|
||||
1. I have seen this error on Cygwin building C++ code::
|
||||
1. This error was reported on Cygwin building C++ code::
|
||||
|
||||
LD: nuttx.rel
|
||||
ld: skipping incompatible /home/patacongo/projects/nuttx/nuttx/trunk/nuttx/libxx//liblibxx.a when searching for -llibxx
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ minimal resources. For example, no assumption is made about the availability of
|
|||
a file system; no ``.twmrc`` file is used. Bitmaps are not used (other than for
|
||||
fonts).
|
||||
|
||||
The TWM license is, I believe compatible with the BSD license used by NuttX. The
|
||||
The TWM license is probably compatible with the BSD license used by NuttX. The
|
||||
origin TWM license required notice of copyrights within each file and a full
|
||||
copy of the original license which you can find in the ``COPYING`` file. within
|
||||
this directory.
|
||||
|
|
@ -34,8 +34,8 @@ Progress
|
|||
~~~~~~~~
|
||||
|
||||
- ``2019-04-28`` This port was brutal. Much TWM logic was removed because it
|
||||
depended on X11 features (or just because I could not understand how to use
|
||||
it). The replacement logic is only mostly in place but more needs to be done
|
||||
depended on X11 features (or just because it was not obvious how it should be
|
||||
used). The replacement logic is only mostly in place but more needs to be done
|
||||
to have a complete system (hence, it is marked ``EXPERIMENTAL``). The kinds of
|
||||
things that need to done are:
|
||||
|
||||
|
|
@ -49,12 +49,12 @@ Progress
|
|||
connection. The server is no longer connected so Twm4Nx constipates and and
|
||||
eventually hangs.
|
||||
|
||||
- ``2019-05-08`` I abandoned the VNC interface and found that things are much
|
||||
- ``2019-05-08`` After abandoning the VNC interface, things are much
|
||||
better using a direct, hardware framebuffer. The background comes up properly
|
||||
and the Icon Manager appears properly in the upper right hand corner. The Icon
|
||||
Manager Window can be iconified or de-iconified. The Icon Manager window can
|
||||
be grabbed by the toolbar title and moved about on the window (the movement is
|
||||
not very smooth on the particular hardware that I am working with).
|
||||
not very smooth on the particular hardware used for testing).
|
||||
|
||||
- ``2019-05-10`` A left click on the background brings up the main menu. At
|
||||
present there are only two options: _Desktop_ which will iconify all windows
|
||||
|
|
@ -166,9 +166,8 @@ Issues
|
|||
~~~~~~
|
||||
|
||||
``2019-05-16`` Twm4Nx is in a very complete state but only at perhaps _alpha_ in
|
||||
its maturity. You should expect to see some undocumented problems. If you see
|
||||
such problems and can describe a sequence to actions to reproduce the problem,
|
||||
let me know and I will try to resolve the problems.
|
||||
its maturity. You should expect to see some undocumented problems.
|
||||
Please report any problems you may encounter.
|
||||
|
||||
Here are all known issues and features that are missing:
|
||||
|
||||
|
|
@ -182,7 +181,7 @@ TWM Compatibilities Issues:
|
|||
|
||||
There are no near-term plans to address these compatibility issues.
|
||||
|
||||
Other issues/bugs. All-in-all, I would say that Twm4Nx is maturing well and is
|
||||
Other issues/bugs. Twm4Nx is maturing well and is
|
||||
attaining stability. That being said, there are some issues and untested
|
||||
functionality that should be addressed:
|
||||
|
||||
|
|
@ -194,22 +193,22 @@ functionality that should be addressed:
|
|||
though the are configured to be borderless).
|
||||
3. Most Twm4Nx configuration settings are hard-coded in ``*_config.hxx`` header
|
||||
files. These all need to be brought out and made accessible via Kconfig files
|
||||
4. I have seen some odd behavior when many NxTerm windows have been opened
|
||||
(around 15). Specifically, I see failures to start NSH in the windows so they
|
||||
4. There is some odd behavior when many NxTerm windows have been opened
|
||||
(around 15). Specifically, failures to start NSH in the windows so they
|
||||
come up blank. All other behaviors seem normal. Most likely, some NxTerm
|
||||
resource allocation is failing silently and leaving things in an unusable
|
||||
state. The board I am using has 128Mb of SDRAM so I can't believe that memory
|
||||
is the limiting factor. These are, however, RAM-backed windows and will use
|
||||
state. The board used for testing has 128Mb of SDRAM so memory is probably
|
||||
not the limiting factor. These are, however, RAM-backed windows and will use
|
||||
significant amounts of memory. The primary issue is that the number of
|
||||
windows should probably be managed in some way to assure that the end-user
|
||||
does not experience odd behaviors when resource usage is high.
|
||||
5. Menus with sub-menus have not been verified. There is no use of sub- menus in
|
||||
the current code base so I expect that there are issues when, for example,
|
||||
5. Menus with sub-menus have not been verified. There is no use of sub-menus in
|
||||
the current code base so issues may be expected when, for example,
|
||||
and item from a sub-menu item: That menu and all of its antecedent menus
|
||||
should be closed.
|
||||
6. There is an optional MENU button that may appear at the far left on the
|
||||
toolbar. It is not used by any window in the current code base and, hence, is
|
||||
unverified. I would expect some issues with generating and routing the MENU
|
||||
unverified. Some issues may be expected with generating and routing the MENU
|
||||
button events to applications. There are likely other unverified features.
|
||||
7. X/Y input may be either via a touchscreen or a mouse. Only touchscreen input
|
||||
has been verified. There is, however, very little difference. The primary
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@
|
|||
|
||||
The Mini Basic implementation at ``apps/interpreters`` derives from version ``1.0``
|
||||
by Malcolm McLean, Leeds University, and was released under the Creative Commons
|
||||
Attibution license. I am not legal expert, but this license appears to be
|
||||
Attibution license. This license appears to be
|
||||
compatible with the NuttX BSD license see:
|
||||
https://creativecommons.org/licenses/. I, however, cannot take responsibility
|
||||
for any actions that you might take based on my understanding. Please use your
|
||||
https://creativecommons.org/licenses/. However, no responsibility can be taken
|
||||
for any actions that you might take based on this understanding. Please use your
|
||||
own legal judgement.
|
||||
|
|
|
|||
|
|
@ -174,9 +174,9 @@ start-up script. We can then piggyback the passwd file into the ``/etc``
|
|||
file system already mounted for the NSH start up file as described above
|
||||
`above <#custinit>`__.
|
||||
|
||||
I use the sim/nsh configuration to create a new password file, but other
|
||||
The sim/nsh configuration can be used to create a new password file, but other
|
||||
configurations could also be used. That configuration already supports a
|
||||
ROMFS file system, passwords, and login prompts. First, I make these
|
||||
ROMFS file system, passwords, and login prompts. First make these
|
||||
changes to that configuration.
|
||||
|
||||
#. Disable logins:
|
||||
|
|
|
|||
|
|
@ -175,6 +175,6 @@ There are currently be three ways to execute applications from NSH:
|
|||
|
||||
**Next Steps**
|
||||
|
||||
In the longer term, I would like to see an option to move most of the larger
|
||||
In the longer term, it would be good to optionally move most of the larger
|
||||
NSH commands out of RAM and built them as standalone programs that can reside,
|
||||
for example, on an SD card (**NOT implemented**).
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ or::
|
|||
|
||||
nsh> i2c ?
|
||||
|
||||
Here is an example of the help output. I shows the general form of the command
|
||||
Here is an example of the help output. It shows the general form of the command
|
||||
line, the various I2C commands supported with their unique command line options,
|
||||
and a more detailed summary of the command I2C command options::
|
||||
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ Advanced Usage
|
|||
~~~~~~~~~~~~~~
|
||||
|
||||
In order to achieve a faster transmission speed,
|
||||
I added a specific HEADER ``STC`` to the YMODEM protocol to represent the custom length.
|
||||
a specific HEADER ``STC`` was added to the YMODEM protocol to represent the custom length.
|
||||
Using the ``sb`` and ``rb`` commands on the board, you can use the ``-k`` option to set the length
|
||||
of the custom packet, and the unit is KB. Therefore, you need to use ``sbrb.py`` for file transfer,
|
||||
and you need ``sbrb.py`` -k to set the same length as the board. According to my test,
|
||||
and you need ``sbrb.py`` -k to set the same length as the board. According to tests,
|
||||
when using -k 32, it can reach 93% of the baud rate,
|
||||
and is fully compatible with the original ymodem protocol.
|
||||
First, you need to add a soft link to sbrb.py, for example ``sudo ln -s /home/<name>/.../<nuttxwork>/apps/system/ymodem/sbrb.py /usr/bin``
|
||||
|
|
|
|||
|
|
@ -27,11 +27,11 @@ Hardware Flow Control
|
|||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Hardware flow control must be enabled in serial drivers in order to prevent data
|
||||
overrun. However, in the most NuttX serial drivers, hardware flow control only
|
||||
overrun. However, in most NuttX serial drivers, hardware flow control only
|
||||
protects the hardware RX FIFO: Data will not be lost in the hardware FIFO but
|
||||
can still be lost when it is taken from the FIFO. We can still overflow the
|
||||
serial driver's RX buffer even with hardware flow control enabled! That is
|
||||
probably a bug. But the workaround solution that I have used is to use lower
|
||||
probably a bug. But the currently implemented workaround solution is to use lower
|
||||
data rates and a large serial driver RX buffer.
|
||||
|
||||
Those measures should be unnecessary if buffering and hardware flow control are
|
||||
|
|
@ -70,7 +70,7 @@ Buffer Recommendations
|
|||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Based on the limitations of NuttX hardware flow control and of the Linux sz
|
||||
behavior, I have been testing with the following configuration (assuming ``UART1``
|
||||
behavior, testing was conducted with the following configuration (assuming ``UART1``
|
||||
is the ZModem device):
|
||||
|
||||
1) This setting determines that maximum size of a data packet frame::
|
||||
|
|
@ -215,9 +215,9 @@ Status
|
|||
|
||||
- ``2013-7-15``: Testing against the Linux ``rz``/``sz`` commands.
|
||||
|
||||
I have tested with the ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk``
|
||||
configuration. I have been able to send large and small files with the target
|
||||
``sz`` command. I have been able to receive small files, but there are problems
|
||||
Performed tests with the ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk``
|
||||
configuration. Large and small files were transferred with the target
|
||||
``sz`` command. It was possible to receive small files, but there are problems
|
||||
receiving large files using the Linux ``sz`` command: The Linux ``sz`` does not
|
||||
obey the buffering limits and continues to send data while ``rz`` is writing the
|
||||
previously received data to the file and the serial driver's RX buffer is
|
||||
|
|
@ -235,9 +235,9 @@ Status
|
|||
|
||||
- ``2013-7-16``. More Testing against the Linux ``rz``/``sz`` commands.
|
||||
|
||||
I have verified that with debug off and at lower serial BAUD (``2400``), the
|
||||
transfers of large files succeed without errors. I do not consider this a
|
||||
_solution_ to the problem. I also found that the LPC17xx hardware flow control
|
||||
Verified that with debug off and at lower serial BAUD (``2400``), the
|
||||
transfers of large files succeed without errors. This is considered a
|
||||
_solution_ to the problem. In addition the LPC17xx hardware flow control
|
||||
caused strange hangs; ZModem works better with hardware flow control disabled
|
||||
on the LPC17xx.
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ Status
|
|||
|
||||
Verified correct operation with hardware flow control using the
|
||||
``olimex-stm32-p407/zmodem`` configuration with target-to-host transfers was
|
||||
verified. Again, there are issues remaining if I tried the NuttX ``rz`` utility
|
||||
verified. Again, there are issues remaining when using the NuttX ``rz`` utility
|
||||
running on Linux.
|
||||
|
||||
- ``2018-6-26``
|
||||
|
|
|
|||
|
|
@ -22,8 +22,7 @@ supports resizing via pixel replication instead of interpolation).
|
|||
When a simple graphics image does not encode well, the symptom is that the
|
||||
resulting RLE data structures are quite large. The palette structure, in
|
||||
particular, may have hundreds of colors in it. There is a way to fix the graphic
|
||||
image in this case. Here is what I do (in fact, I do this on all images prior to
|
||||
conversion just to be certain):
|
||||
image in this case. Here is what can be done:
|
||||
|
||||
- Open the original image in GIMP.
|
||||
- Select the option to select the number of colors in the image.
|
||||
|
|
|
|||
|
|
@ -36,9 +36,9 @@ How To Use
|
|||
The i8sak app has a series of CLI functions that can be invoked. The default
|
||||
i8sak command is ``i8`` to make things quick and easy to type.
|
||||
|
||||
In my test setup I have 2 Clicker2-STM32 boards from MikroElektronika, with the
|
||||
BEE-click (MRF24J40) radios. Choose one device to be the PAN Coordinator. We'll
|
||||
refer to that as device A.
|
||||
A test setup contained 2 Clicker2-STM32 boards from MikroElektronika, with the
|
||||
BEE-click (MRF24J40) radios. Choose one device to be the PAN Coordinator.
|
||||
This device is referred to as device A.
|
||||
|
||||
On that device, run::
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ the ``-d`` option.
|
|||
|
||||
**Note**: Currently, the indirect transaction timeout is disabled. This means
|
||||
frames must be extracted or space may run out. This is only for the testing
|
||||
phase as it is easier to debug when I am not fighting a timeout. Re-enabling the
|
||||
phase as it is easier to debug when not fighting a timeout. Re-enabling the
|
||||
timeout may effect the behavior of the indirect transaction features in the
|
||||
``i8sak`` app.
|
||||
|
||||
|
|
|
|||
|
|
@ -1481,7 +1481,7 @@ the naming of `enumeration values <#enumerations>`__.
|
|||
- **Uppercase**. Macro names are always in upper case.
|
||||
- **Lowercase Exceptions**. There are a few lower case values in NuttX
|
||||
macro names. Such as a lower-case ``p`` for a period or decimal point
|
||||
(such as ``VOLTAGE_3p3V``). I have also used lower-case ``v`` for a
|
||||
(such as ``VOLTAGE_3p3V``). The lower-case ``v`` is also used for a
|
||||
version number (such as ``CONFIG_NET_IPv6``). However, these are
|
||||
exceptions to the rule rather than illustrating a rule.
|
||||
- **Macros that could be functions**. Lower-case macro names are also
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ Making Changes Using Git
|
|||
The Apache NuttX project uses the `Git version control system <https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control>`_
|
||||
to track changes, and the source code is hosted on `GitHub <https://www.github.com>`_.
|
||||
|
||||
If you want to make changes to NuttX, for your own personal use, or to submit them back to project to improve NuttX,
|
||||
that's easy. For the purposes of this guide, you'll need a `GitHub <https://www.github.com>`_ account, since
|
||||
If you want to make changes to NuttX, for your own personal use, or to submit them back to the project to improve NuttX, that's easy. For the purposes of this guide, you will need a `GitHub <https://www.github.com>`_ account, since
|
||||
the Apache NuttX team uses GitHub. (You could also use git locally, or save your changes to other sites like
|
||||
`GitLab <https://about.gitlab.com/>`_ or `BitBucket <https://bitbucket.org>`_, but that's beyond the scope of this
|
||||
guide).
|
||||
|
|
@ -71,10 +70,10 @@ Git Workflow With an Upstream Repository
|
|||
The main NuttX git repository is called an "upstream" repository - this is because it's the main source of truth, and
|
||||
its changes flow downstream to people who've forked that repository, like us.
|
||||
|
||||
Working with an upstream repo is a bit more complex, but it's worth it since you can submit fixes and features
|
||||
Working with an upstream repo is a bit more complex, but it is worth the effort since you can submit fixes and features
|
||||
to the main NuttX repos. One of the things you need to do regularly is keep your local repo in sync
|
||||
with the upstream. I work with a local branch, make changes, pull new software from the upstream and merge it in,
|
||||
maybe doing that several times. Then when everything works, I get my branch ready to do a Pull Request. Here's how:
|
||||
with the upstream. While working with a local branch you can make changes, pull new software from the upstream and merge it in,
|
||||
maybe doing that several times. Then when everything works, the branch is ready to be proposed as a Pull Request. That is how it works:
|
||||
|
||||
#. Fetch upstream changes and merge into my local master:
|
||||
|
||||
|
|
@ -171,10 +170,10 @@ Submitting Your Changes to NuttX
|
|||
|
||||
Before you do a Pull Request, the NuttX team will usually want all the changes you made in your branch "squashed" into
|
||||
a single commit, so that when they review your changes, there's a clean view of the history. If there are changes
|
||||
after Pull Request review feedback, they can be separate commits. Here's the easiest way I found to do that initial
|
||||
after Pull Request review feedback, they can be separate commits. Here is the easiest way to do this initial
|
||||
squash before submitting the Pull Request:
|
||||
|
||||
#. Check out my branch
|
||||
#. Check out ``my-branch``
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -268,7 +267,7 @@ So, someone will ask you some enigmatic thing: "Please rebase and squash these c
|
|||
Basically what they are saying is that you need to update your repository
|
||||
and fuse your commits in a single commit.
|
||||
|
||||
Let walk through the steps to do it!
|
||||
Let us walk through the steps to do it!
|
||||
|
||||
Move to upstream branch and pull the new commits from there:
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,8 @@ If you want to access a host device driver, then the code that does that has to
|
|||
Toward a General Design
|
||||
=======================
|
||||
|
||||
There is no design in place for accessing Host devices from the simulation. Here are some directions that I would investigate, however.
|
||||
There is no design in place for accessing Host devices from the simulation.
|
||||
Here are some directions that could be worth investigating, however.
|
||||
|
||||
Perhaps you could create a NuttX FIFO in the NuttX blob. It would reside at, say, ``/dev/mydevice`` in the NuttX VFS. Perhaps this FIFO could be used in the NuttX world as your character device? Perhaps it could read and write from FIFOs to intermediate the interaction with the host PC device?
|
||||
|
||||
|
|
@ -96,13 +97,13 @@ The current NuttX host simulation has no interrupts and, hence, is non-preemptib
|
|||
|
||||
Currently, all timing and serial input is simulated in the IDLE loop: When nothing is going on in the simulation, the IDLE loop runs and fakes timer and UART events.
|
||||
|
||||
I have been thinking about how to implement simulated interrupts in the simulation. I think a solution would work like this.
|
||||
The simulation of interrupts needs some thought. A possible solution could look like this:
|
||||
|
||||
* In the earliest initialization, simulator could start a host simulation interrupt thread and setup a signal handler to catch signals on the main thread. One signal, say ``SIGUSER`` could indicate a context switch. This would be a type ``SA_SIGINFO`` and the context switch information would be provided in the ``sival_t`` field of the ``siginfo``.
|
||||
|
||||
* Interrupt logic could be implemented on a host pthread. The host pthread, like a hardware interrupt, executes asynchronously outside of the operating system. The interrupt thread could wait for a host signal or a host message and, upon receipt, perform simulated interrupt logic.
|
||||
|
||||
* ``up_interrupt_context()`` would need to be implemented; it is only a stub now. I think this could be done with a simple global boolean like:
|
||||
* ``up_interrupt_context()`` would need to be implemented; it is only a stub now. This could probably be done with a simple global boolean like:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -132,7 +133,7 @@ The threading is a little mind-bending. The signal handler needs to run in the
|
|||
|
||||
When ``up_longjmp()`` is executing, operation will continue under the main thread, but the context including the stack are different for the new NuttX thread. When the context finally switches back to this thread, it will appear as an appear return from ``up_setjmp()`` with a non-zero return value. In that case, the signal handler will just return and the normal execution of the preempted NuttX task will resume.
|
||||
|
||||
**Issues**. My only real technical questions involve signal masking. When the ``SIGUSER`` signal handler executes, the ``SIGUSER`` interrupt will be masked. That would prevent any further context switches until the signal handler returns. Can we simply *unmask* ``SIGUSER`` signal to get more context switches? I would need to experiment to know for sure.
|
||||
**Issues**. My only real technical questions involve signal masking. When the ``SIGUSER`` signal handler executes, the ``SIGUSER`` interrupt will be masked. That would prevent any further context switches until the signal handler returns. Can we simply *unmask* ``SIGUSER`` signal to get more context switches? This detail needs to be clarified by experiments.
|
||||
|
||||
Supported Devices
|
||||
=================
|
||||
|
|
@ -167,7 +168,7 @@ SMP
|
|||
|
||||
There is a simulator configuration has basic support for SMP testing. The simulation supports the emulation of multiple CPUs by creating multiple pthreads, each run a copy of the simulation in the same process address space.
|
||||
|
||||
At present, the SMP simulation is not fully functional: It does operate on the simulated CPU threads for a few context switches then fails during a setjmp() operation. I suspect that this is not an issue with the NuttX SMP logic but more likely some chaos in the pthread controls. I have seen similar such strange behavior other times that I have tried to use setjmp/longmp from a signal handler! Like when I tried to implement simulated interrupts using signals.
|
||||
At present, the SMP simulation is not fully functional: It does operate on the simulated CPU threads for a few context switches then fails during a setjmp() operation. It is suspected that this is not an issue with the NuttX SMP logic but more likely some chaos in the pthread controls. Similar strange behavior was seen in other times where setjmp/longmp was used from a signal handler. For example when implementing simulated interrupts using signals.
|
||||
|
||||
Apparently, if longjmp is invoked from the context of a signal handler, the result is undefined: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm
|
||||
|
||||
|
|
@ -213,4 +214,4 @@ But for example, this command:
|
|||
|
||||
nsh> sleep 1 &
|
||||
|
||||
will execute the sleep command on CPU1 which has worked every time that I have tried it (which is not too many times).
|
||||
will execute the sleep command on CPU1 which has worked every time it was tested.
|
||||
|
|
|
|||
|
|
@ -239,7 +239,7 @@ OS with all of that?
|
|||
you actually use.
|
||||
|
||||
Using a variety of technologies, NuttX can scale from the very tiny to the moderate-size system.
|
||||
I have executed NuttX with some simple applications in as little as 32K *total* memory (code and
|
||||
NuttX was seen operating with some simple applications in as little as 32K *total* memory (code and
|
||||
data). On the other hand, typical, richly featured NuttX builds require more like 64K (and
|
||||
if all of the features are used, this can push 100K).
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ referenced above may be build in the Cygwin environment as well.
|
|||
Windows with Cygwin + GNU ``make`` + SDCC (custom built under Cygwin)
|
||||
=====================================================================
|
||||
|
||||
I have never tried this combination, but it would probably work just
|
||||
This combination was not reported to have ever been tested, but it would probably work just
|
||||
fine.
|
||||
|
||||
Windows with Cygwin + GNU ``make`` + Windows Native Toolchain
|
||||
|
|
@ -95,11 +95,11 @@ At present, this build environment also requires:
|
|||
|
||||
**Windows Console**. The build must be performed in a Windows console
|
||||
window. This may be using the standard ``CMD.exe`` terminal that comes
|
||||
with Windows. I prefer the ConEmu terminal which can be downloaded from:
|
||||
with Windows. The ConEmu terminal may be preferable. It can be downloaded from:
|
||||
http://code.google.com/p/conemu-maximus5/
|
||||
|
||||
**GNUWin32**. The build still relies on some Unix-like commands. I
|
||||
usethe GNUWin32 tools that can be downloaded from
|
||||
**GNUWin32**. The build still relies on some Unix-like commands.
|
||||
The GNUWin32 tools may be of use here. They can be downloaded from
|
||||
http://gnuwin32.sourceforge.net/. See the top-level ``nuttx/README.txt``
|
||||
file for some download, build, and installation notes.
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ there may be conflicts.
|
|||
Wine + GNU ``make`` + Windows Native Toolchain
|
||||
==============================================
|
||||
|
||||
I've never tried this one, but I off the following reported by an ez80
|
||||
The following was reported by an ez80
|
||||
user using the ZiLOG ZDS-II Windows-native toolchain:
|
||||
|
||||
"I've installed ZDS-II 5.1.1 (IDE for ez80-based boards) on wine
|
||||
|
|
@ -141,8 +141,8 @@ very likely that NuttX would work in that environment as well (with some
|
|||
porting effort). If GNU make is not supported, then some significant
|
||||
modification of the Make system would be required.
|
||||
|
||||
**MSYS**. I have not used MSYS but what I gather from talking with NuttX
|
||||
users is that MSYS can be used as an alternative to Cygwin in any of the
|
||||
**MSYS**. MSYS was not specifically tested, but some users consider it
|
||||
as an alternative to Cygwin in any of the
|
||||
above Cygwin environments. This is not surprising since MSYS is based on
|
||||
an older version of Cygwin (cygwin-1.3). MSYS has been modified,
|
||||
however, to interoperate in the Windows environment better than Cygwin
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Note:
|
|||
terminal_2: Listening for serial connection on port 5002
|
||||
terminal_3: Listening for serial connection on port 5003
|
||||
|
||||
FVP has four UART port and I choice UART1 as tty, so just telnet to port 5001
|
||||
FVP has four UART port and UART1 was choosen as tty, so just telnet to port 5001
|
||||
will enter nsh:
|
||||
telnet localhost 5001
|
||||
|
||||
|
|
|
|||
|
|
@ -316,17 +316,17 @@ Status
|
|||
|
||||
2022-07-01:
|
||||
|
||||
1. It's very stranger to see that signal testing of ostest is PASSED at Physical Ubuntu PC
|
||||
rather than an Ubuntu at VMWare. For Physical Ubuntu PC, I have run the ostest
|
||||
for 10 times at least but never see the crash again, but it's almost crashed every time
|
||||
1. It's very strange to see that signal testing of ostest is PASSED at Physical Ubuntu PC
|
||||
rather than an Ubuntu at VMWare. For Physical Ubuntu PC, the ostest was run
|
||||
for 10 times at least but the crash was never seen again, but it's almost crashed every time
|
||||
running the ostest at Virtual Ubuntu in VMWare
|
||||
I check the fail point. It's seem at signal routine to access another CPU's task context reg
|
||||
will get a NULL pointer, but I watch the task context with GDB, everything is OK.
|
||||
So maybe this is a SMP cache synchronize issue? But I have done cache synchronize
|
||||
operation at thread switch and how to explain why the crash not happening at
|
||||
Physical Ubuntu PC?
|
||||
So maybe this is a qemu issue at VMWare. I am planning to run
|
||||
the arm64 to real hardware platform like IMX8 and will check the issue again
|
||||
Checking for the the fail point. It's seem at signal routine to access another CPU's task context reg
|
||||
will get a NULL pointer, but watch the task context with GDB, shows everything as OK.
|
||||
So maybe this is a SMP cache synchronize issue? But synchronize operations have
|
||||
been done at thread switch. It is hard to explain why the crash is not happening with a
|
||||
Physical Ubuntu PC.
|
||||
So maybe this is a qemu issue at VMWare.
|
||||
``arm64`` should be tested on a real hardware platform like IMX8 for the above issue.
|
||||
|
||||
2022-06-12:
|
||||
|
||||
|
|
@ -426,7 +426,7 @@ The nuttx ELF image can be debugged with QEMU.
|
|||
|
||||
FPU Support and Performance
|
||||
===========================
|
||||
I was using FPU trap to handle FPU context switch. For threads accessing
|
||||
The FPU trap was used to handle FPU context switch. For threads accessing
|
||||
the FPU (FPU instructions or registers), a trap will happen at this thread,
|
||||
the FPU context will be saved/restore for the thread at the trap handler.
|
||||
It will improve performance for thread switch since it's not to save/restore
|
||||
|
|
@ -450,7 +450,7 @@ index c58fb45512..acac6febaa
|
|||
DEPPATH += --dep-path syslog
|
||||
VPATH += :syslog
|
||||
+syslog/lib_syslog.c_CFLAGS += -mgeneral-regs-only
|
||||
I cannot commit the patch for NuttX mainline because it's very special case
|
||||
This patch cannot be merged into NuttX mainline because it is a very special case
|
||||
since ostest is using syslog for lots of information printing. but this is
|
||||
a clue for FPU performance analysis. va_list object is using for many C code to
|
||||
handle argument passing, but if it's not passing floating point argument indeed.
|
||||
|
|
|
|||
|
|
@ -79,9 +79,9 @@ Serial Connection
|
|||
USART1 is the default USART1 used in the configuration files to
|
||||
provide a serial console (of course, that can be easily changed
|
||||
by editing the configuration file). The AVR32DEV1 board has no
|
||||
RS-232 drivers or connectors on board. I use an off-board MAX232
|
||||
module that I got on eBay (search for MAX232 if you want to find
|
||||
one). I connect the MAX232 board as follows:
|
||||
RS-232 drivers or connectors on board. An off-board MAX232 module
|
||||
was used (search for MAX232 if you want to find
|
||||
one). The MAX232 board was conneted as follows:
|
||||
|
||||
In boards/avr/at32uc3/avr32dev/include/board.h:
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ PA17 and PA23 are available from the AVR32DEV1:
|
|||
PA11-PA12, PA18-PA19, PA28-PA31............................-0.3 to 3.6V
|
||||
Other Pins ............................................... -0.3 to 5.5V
|
||||
|
||||
I get the 5V from another USB port (using the 5V power cable that normally
|
||||
The 5V are taken from another USB port (using the 5V power cable that normally
|
||||
provides the extra current needed by my USB IDE drive).
|
||||
|
||||
Development Environment
|
||||
|
|
@ -307,7 +307,7 @@ AVR32 Bootloader
|
|||
Reset
|
||||
^^^^^
|
||||
|
||||
I don't trust the reset button -- if you reset and something weird happens,
|
||||
The reset button may not be really reliable -- if you reset and something weird happens,
|
||||
try a full power cycle.
|
||||
|
||||
Make Tip
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue