Loading ...
Sorry, an error occurred while loading the content.

Re: I have port NuttX to RGMP

Expand Messages
  • clemens fischer
    ... That is a very interesting project! Why are the newer linux kernels not considered? I m running Linux 2.6.38.8, because I need some of the features not
    Message 1 of 28 , Jun 4, 2011
    View Source
    • 0 Attachment
      On Thu-2011/05/12-05:05 qiang yu wrote:

      > I've port NuttX to RGMP (http://rgmp.sf.net) which is a project to run Linux
      > and RTOS simultaneously on multi-processor x86 computers.

      > You can run Linux first and then boot NuttX on another CPU to form a hybrid
      > OS so that they can run simultaneously and communicate with each other. This
      > will let you be able to use both GPOS and RTOS features. The requirements
      > are a multi-processor computer of x86 and a Linux OS using kernel 2.6.32 or
      > 2.6.35 (Ubuntu 10.04 or 10.10).

      That is a very interesting project!

      Why are the newer linux kernels not considered? I'm running Linux
      2.6.38.8, because I need some of the features not available earlier.

      > Any one interest in can have a look!

      I have taken the liberty to subscribe[1] to [2] proposing the newsgroup
      name "gmane.linux.real-time.rgmp", with obfuscated email-addresses.

      People can read both "gmane.linux.real-time.rgmp" and
      "gmane.comp.embedded.nuttx" with newsreaders, a web interface and
      RSS-feeds once this subscription is approved.

      [1] rgmp-discuss@...
      [2] http://gmane.org/

      BTW: RGMP needs documentation! Eg. sample sessions so people know what
      it will do for them and a howto get the linux+RGMP combination up and
      running.


      regards, clemens
    • clemens fischer
      ... In other languages (like Lua) fwrite() is general purpose and needs a flush() if a linefeed (on stdout) is wanted. Doing this automatically could well
      Message 2 of 28 , Jun 4, 2011
      View Source
      • 0 Attachment
        On Sat-2011/05/14-17:34 Gregory N wrote:

        > Good suggestion. I have implemented this in NuttX was well. The
        > change is available in SVN now. To use it, you have to enable
        > CONFIG_STDIO_LINEBUFFER. You still also need to set
        > CONFIG_STDIO_BUFFER_SIZE too. The buffer will flushed whenever the
        > buffer is full or whenever a newline character is encountered.
        >
        > This effects only printf(), fprintf(), vfprintf(). It should probably
        > apply to puts() as well, but it does not yet. It does not apply to
        > fwrite: fwrite() could be writing binary data and flushing on '\n'
        > would be strange behavior in that case. Puts is based on fwrite() and
        > I would prefer to avoid the extra logic just to see if the string has
        > a newline in it. Maybe I should add the extra logic?

        In other languages (like Lua) "fwrite()" is general purpose and needs
        a flush() if a linefeed (on stdout) is wanted. Doing this automatically
        could well be kept to the printf* class of functions. Adding it to the
        write* class should be tied to the configuration option
        CONFIG_STDIO_LINEBUFFER and wrapped by a check if output is really going
        to stdout.


        clemens
      • Bassem Fahmy
        Hi,I was wondering if there is a way to access files on my computer from the Nuttx simulator. may be mount a folder or something..i m not sure. Thannks,Bassem
        Message 3 of 28 , Jun 4, 2011
        View Source
        • 0 Attachment

          Hi,
          I was wondering if there is a way to access files on my computer from the Nuttx simulator. may be mount a folder or something..i'm not sure.


          Thannks,
          Bassem

        • Gregory N
          ... Serial output is surprisingly complex. First of all, there are two levels of buffering, one in the C buffered I/O layer and one inside of the serial
          Message 4 of 28 , Jun 4, 2011
          View Source
          • 0 Attachment
            > In other languages (like Lua) "fwrite()" is general purpose and needs
            > a flush() if a linefeed (on stdout) is wanted. ...

            Serial output is surprisingly complex. First of all, there are two levels of buffering, one in the C buffered I/O layer and one inside of the serial driver itself. So when we "flush" the C buffered I/O this really just means copying the data from the C buffer to the driver buffer where it can be sent by the driver.

            Because of all of this buffering, I imagine that most people just set CONFIG_STDIO_BUFFER_SIZE=0 in the configuration file. Then there is is no C buffering layer. The serial data goes straight to the driver buffer.

            Using C buffered I/O might still be of value when using serial output in a deeply embedded system (CONFIG_STDIO_BUFFER_SIZE > 0). It keeps the serial driver quiet and data comes in/out chunks which is perhaps more efficient.

            Now C buffered I/O can be used for a number of different things. For the case of serial console, it makes a better user interface if newline terminated data just appears on the command line without a flush() (with newlines \n expanded to \r\n). This is what CONFIG_STDIO_LINEBUFFER does. But that same behavior might not be desirable if the the serial port were used in a machine-to-machine interfaces. Or for SLIP or PPP.

            (And it works just as you suggest... no flushing of fwrite(), only on the more clearly line-oriented output).

            In Linux, you solve all of these different issues with termios. But there are no termios in NuttX. Instead, there are many configuration options to accomplish what you want.

            I have mixed feelings about all of the configuration options. All of the configuration options make setting up and tuning NuttX complex. But it keeps the footprint to the smallest possible size and that is what I am trying to accomplish.

            I would love to have a good configuration tool to make this simpler and I somethings think I should take the configuration tool from Linux or uClibc. But it is GPL and I am not sure of what it would mean to have a GPL tool in a BSD package. I suppose when you ship bits, you don't ship the configuration tool bits so it should be okay. But it leaves me unconfortable.

            Greg
          • Gregory N
            ... You have basically the same problem here as with any virtualized machine. You could copy files to/from the simulation via serial or a network (if the
            Message 5 of 28 , Jun 4, 2011
            View Source
            • 0 Attachment
              > Hi,I was wondering if there is a way to access files on my computer from the Nuttx simulator. may be mount a folder or something..i'm not sure.

              You have basically the same problem here as with any virtualized machine. You could copy files to/from the simulation via serial or a network (if the simulator network works -- it didn't the last time I used it).

              Actually, I've never thought about this problem. I can speculate a little; perhaps someone in the list has some better ideas:

              You can share a FAT file system image file. On a Linux host you can access the FAT file system image file using losetup like:

              dd if=/dev/zero of=fs.img bs=512 count=1024
              losetup /dev/loop0 fs.img
              mkdosfs /dev/loop0
              mkdir /mnt/myfs
              mount -t msdos /dev/loop0 /mnt/myfs

              Now you can write files to /mnt/myfs. But how can use use this within the NuttX simulator? You could copy the fs.img file into RAM when the simulator starts. They you could use a NuttX ramdisk to access the files.

              Another thing you can do is use xxd -i to convert a file system file into a C header file. I this all of the time for ROMFS images. See, for example, tools/mkromfsimg.sh. In fact, the logic in that script would work perfectly well for creating a read only ROMFS version of a directory. See apps/nshlib for some examples. The file nsh_romfsimg.h in that directory was created using the mkromfsimg.sh script. That image is mounted at /etc/init.d and contains a shell script rcS.

              If you want a write-able file system that to get files from the NuttX simulator, then I think you need to invent somehting. One way would be to write a special block driver that can access the host file system. Then you could access files directly in the fs.img file.

              Does anyone else have any better ideas?

              Greg
            • qiang yu
              Hello Clemens, That is a very interesting project! ... I m glad you like it. ... I ll make RGMP support 2.6.38 in the next week which I have already planned
              Message 6 of 28 , Jun 4, 2011
              View Source
              • 0 Attachment
                Hello Clemens,

                That is a very interesting project!

                I'm glad you like it.


                Why are the newer linux kernels not considered? I'm running Linux
                2.6.38.8, because I need some of the features not available earlier.


                I'll make RGMP support 2.6.38 in the next week which I have already planned
                since Ubuntu 11.04 released.

                I have taken the liberty to subscribe[1] to [2] proposing the newsgroup
                name "gmane.linux.real-time.rgmp", with obfuscated email-addresses.

                People can read both "gmane.linux.real-time.rgmp" and
                "gmane.comp.embedded.nuttx" with newsreaders, a web interface and
                RSS-feeds once this subscription is approved.

                [1] rgmp-discuss@...
                [2] http://gmane.org/

                Thank you. I hope the mailing list will be more active.
                 

                BTW: RGMP needs documentation! Eg. sample sessions so people know what
                it will do for them and a howto get the linux+RGMP combination up and
                running.

                Thank you for your advice. I'll improve the documentation.

                Regards,
                Yu Qiang
              • Hal Glenn
                I know it s come up before, but how big would an NFS client be? Combine a PPP link and the ability to mount NFS some very interesting doors I think would open
                Message 7 of 28 , Jun 5, 2011
                View Source
                • 0 Attachment
                  I know it's come up before, but how big would an NFS client be? Combine a PPP link and the ability to mount NFS some very interesting doors I think would open for small uC applications, and possibly an easier networking path for the simulator.

                  Hal

                  On Sat, Jun 4, 2011 at 7:44 PM, Gregory N <spudarnia@...> wrote:
                   

                  > Hi,I was wondering if there is a way to access files on my computer from the Nuttx simulator. may be mount a folder or something..i'm not sure.

                  You have basically the same problem here as with any virtualized machine. You could copy files to/from the simulation via serial or a network (if the simulator network works -- it didn't the last time I used it).

                  Actually, I've never thought about this problem. I can speculate a little; perhaps someone in the list has some better ideas:

                  You can share a FAT file system image file. On a Linux host you can access the FAT file system image file using losetup like:

                  dd if=/dev/zero of=fs.img bs=512 count=1024
                  losetup /dev/loop0 fs.img
                  mkdosfs /dev/loop0
                  mkdir /mnt/myfs
                  mount -t msdos /dev/loop0 /mnt/myfs

                  Now you can write files to /mnt/myfs. But how can use use this within the NuttX simulator? You could copy the fs.img file into RAM when the simulator starts. They you could use a NuttX ramdisk to access the files.

                  Another thing you can do is use xxd -i to convert a file system file into a C header file. I this all of the time for ROMFS images. See, for example, tools/mkromfsimg.sh. In fact, the logic in that script would work perfectly well for creating a read only ROMFS version of a directory. See apps/nshlib for some examples. The file nsh_romfsimg.h in that directory was created using the mkromfsimg.sh script. That image is mounted at /etc/init.d and contains a shell script rcS.

                  If you want a write-able file system that to get files from the NuttX simulator, then I think you need to invent somehting. One way would be to write a special block driver that can access the host file system. Then you could access files directly in the fs.img file.

                  Does anyone else have any better ideas?

                  Greg

                  Recent Activity:
                  .
                   

                • Gregory N
                  Hi, Hal, ... I have consider implementing an NFS client in the past. It would not be very difficult and could be the basis for a lot of great solutions. Would
                  Message 8 of 28 , Jun 5, 2011
                  View Source
                  • 0 Attachment
                    Hi, Hal,

                    > I know it's come up before, but how big would an NFS client be? Combine a
                    > PPP link and the ability to mount NFS some very interesting doors I think
                    > would open for small uC applications, and possibly an easier networking path
                    > for the simulator.

                    I have consider implementing an NFS client in the past. It would not be very difficult and could be the basis for a lot of great solutions. Would anyone else be interested in having NFS built into NuttX?

                    It would be difficult to use with the user-mode Linux simulation, however, because networking is not functional on Linux. On Linux, the simulation uses TAP devices to support networking (I think it is closer on Cygwin where is uses the WinPCAP library). Both of these were leveraged from uIP but have never worked.

                    I am also finishing up an FTP client that will be in NuttX-6.4 (hopefully before the end of this week). But if you have a network, there is already TFTP and WGET.

                    NuttX is missing good serial port transfer logic too. I started an X/Y/Z Modem implementation a couple of years ago, but never finished that. The full X/Y/Z Modem logic is quite complex; I think NuttX needs something simpler.

                    Greg
                  • Gregory N
                    ... Hmmm... a problem with having global settings like CONFIG_STDIO_LINEBUFFER is that it applies to all serial ports. What if I want line buffering on one
                    Message 9 of 28 , Jun 5, 2011
                    View Source
                    • 0 Attachment
                      > In other languages (like Lua) "fwrite()" is general purpose and needs
                      > a flush() if a linefeed (on stdout) is wanted. Doing this automatically
                      > could well be kept to the printf* class of functions. Adding it to the
                      > write* class should be tied to the configuration option
                      > CONFIG_STDIO_LINEBUFFER and wrapped by a check if output is really going
                      > to stdout.

                      Hmmm... a problem with having global settings like CONFIG_STDIO_LINEBUFFER is that it applies to all serial ports. What if I want line buffering on one port, but I want another to have a different buffering strategy>

                      Another option that might be good for NuttX would be to implement the setvbuf() function. See http://en.wikibooks.org/wiki/C_Programming/File_IO#The_setvbuf_function.

                      I'll look into that someday (not today).
                      Greg
                    Your message has been successfully submitted and would be delivered to recipients shortly.