Help me in learning understanding Nuttx.

[Sainath Vanacharla]

I am an undergraduate student and  new to RTOS, I came across Nuttx while reading about PX4 flight controller and uROS. I am very interested to learn Nuttx, as a part of curriculum we are learning freertos now but, I want to do my semester project on Nuttx.

Can anyone please guide me how to learn nuttx. I am good at linux system programming as nuttx is POSIX compliant I am confident I can learn Nuttx easily if someone guide me.

I already saw Nuttx channel on youtube it is demonstrating only example programs but I want to learn more.

[Naasik Hendricks]

Hi

I believe there is a forum/Vlog on lessons learned, it was started last year. Best people to ask Alan, Johannes and Dave, where it is published.

BR

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/1ccd2ffd-2c44-4045-8ae1-6e8aca3cc569%40googlegroups.com.

[Gregory Nutt]

Check the Wiki that is accessible through the website:
https://nuttx.apache.org/

Direct Link: https://cwiki.apache.org/confluence/display/NUTTX/Nuttx

Note that that the NuttX Google group is deprecated.  Discussion
currently occurs at d...@nuttx.apache.org.  You can subscribe to that
list by sending an email to dev-su...@nuttx.apache.org

[Phani Kumar]

Hi Greg and all,

Currently I am porting USB Host controller to Renesas RX65N controller and stuck at endpoint descriptor and thought of checking with you.

Basically this endpoint descriptor - looking into lpc1740 as reference code - struct lpc17_40_ed_s (.\arch\arm\src\lpc17xx_40xx\lpc17_40_usbhost.c) refers to ohci_ed_s struct (./include/nuttx/usb/ohci.h).

As RX65N controller does not refer to any of these specs (OHCI/ UHCI/ EHCI). I think, I can also use this ohci_ed_s struct, as host code at OS level may be using these specs for various USB scheduling and other things.

Please let me know if you think, usage of ohci_ed_s struct works for RX65N or should I need to look into EHCI or any thing else.

With best regards,

Phani.

[Nathan Hartman]

Here's a recent presentation by the creator of NuttX:

https://youtu.be/KF_9yOsNH2s 

[Gregory Nutt]

You should ignore OHCI and EHCI and properly design the HCD from scratch according to the specification.

[Phani Kumar]

Hi Greg and all,

As part of porting USB Host driver for RX65N, I am referring to LPC17_40 USB Host port. Here are some of the points, where I need your suggestions. Please let me know if you have any pointers/ other references on this.

HCCA (Host communication area details), TDTAIL (Transfer descriptor details) and EDCTRL (Endpoint descriptor details) are referred as respective structures. LPC17_40 has these structures located at some RAM Area (I think, LPC17xx has dedicated memory for USB Host or something like that) and uses this memory area for these structures (where start address is fixed at starting point of memory, and with each size, the next structure is referred).

In RX65N, would it be OK, to use normal memory and allocate these structures statically - in the beginning of the file itself? Or do you suggest to allocate memory in the init function *__usbhost_initialize () function and use them?

With best regards,

Phani.

[Phani Kumar]

Hi Greg and all,

I am developing the USB Host driver for RX65N, and using lpc17xxx port as my basic reference. Currently I can detect the device and initiate the standard "usbhost_enumerate()" function. This calls tballoc twice and prepares the buffer for (i) first setup packet request and (ii) for data to be received. This results in series calls to

xxx_usbhost_ctrlin() //Think this is getting ready for reading the returend data from device

-> xxx_usbhost_ctroltd () //This creates the Transfer Descriptror for the data transer

-> xxx_usbhost_alloc_xfrinfo () //Prepares the data to be transmitted (setup packet to get teh device descriptor)

-> and finally xxx_enquetd () //this prepares the pointers ready to be transmitted

and then waits for completion on semaphore

Some how I am not able to figure out, who/how transfer the data to actual hardware registers here? If the host keeps keeps pumping the data (with enque), where does the deque i.e. taking this out and sending out to device happens?

Think I am missing very basic thing. Let me know if you have any pointers/ suggestion for me.

With best regards,

Phani.

[Phani Kumar]

Or... Do I have to write the data to corresponding hardware registers in the enque itself and wait for the interrupt routine to receive the data and release the semaphore? Basically enque of Lpc17xxx (which I am using as reference) seems generic and not updating any hardware registers...

With best regards,

Phani.

[Phani Kumar]

Hello Greg and others,

I am developing a USB Host controller on NuttX with hardware which is not compliant with OHCI or EHCI. As the hardware provides setup of hardware registers for the USB Host, I am trying to "fit" it to OHCI spec (currently using lpc17_40_usbhost as reference).

I am confused about the usage of following buffers and how to use them in read/ write from hardware during interrupt (in bottom half).

During initialization, EDuffer, TDBuffer, TBBuffer and xferInfo buffers are created. I am using chunk of memory for each of these and allocated 10 buffers for each (hardware has 10 endpoints) for ED, TD, TB and xferInfo. I assume ED for Endpoint, TD for Transfer Descriptor, TB for TransferBuffer and xferInfo is to manage the transfer details between interrupts.

With this setup and initial configuration, I am able to detect attaching of device and then issue first setup packet. Device sends the data and interrupt is triggered. I ack this interrupt and start the bottom half (worker queue) to read the data (I have the data in the hardware registers) and in bottom half, I am not sure, where should I read this data into - ED/ TD/ TB? Also I am not sure, how to get the reference to these buffers in bottom half?

Some pointers/ direction would help me a lot.

Thanks in advance and with best regards,

Phani.

[Gregory Nutt]

EDs and TDs are DMA descriptors used only in the OHCI architecture.  I am not sure how to talk about DMA descriptors outside of the context of OHCI.  The OHCI specification is here:  http://www.scaramanga.co.uk/stuff/qemu-usb/hcir1_0a.pdf

That should answer any questions that you have about the OHCI DMA descriptors

[Phani Kumar]

Hi Greg and all,

Generally enumeration sequence of USB (from host perspective) is - start with address 0, (i) Get the device descriptor (DD) (ii) note the control endpoint (EP0) size of device (iii) configure the EP0 of host to EP0 of device (iv) Get the complete 18 bytes of DD (v) Reset the device (vi) Send setup packet on address 0 with new address (vii) Then read all the descriptors with newly assigned address.

Currently while developing the USB host driver, I am able to get till point (iv). This is completely done by usbhost_enumerate() function [in usbhost_enumerate.c] - This calls first DRVR_EP0CONFIGURE() to set the default EP0 size as 8 bytes (of host's EP0). Then gets the 8 bytes of DD with DRVR_CTRLIN - for step (i) and (ii) above. Next  usbhost_enumerate() calls DRVR_EP0CONFIGURE() with new size. Then gets the all the 18 bytes of DD with DRVR_CTRLIN(). Finds out internally about new address to be assigned and calls DRVER_CTRLOUT () to set the new address - still with address 0.  Next DRVR_EP0CONFIGURE() is called with new address - to set the new address in the host driver. Finally calls DRVR_CTRLIN() to get the config descriptors with new address. 

I am not very sure, if this sequence is correct. If any of you have worked on USB Host driver, please let me know

1. My understanding is "usbhost_enumerate.c" is hardware agnostic module and should not be modified to port USB host for different controllers. Is this correct? 

2. In the above sequece - I see missing Reset (point v as in above). It should be supposed to be called from usbhost_enumerate() [in usbhost_enumerate.c]. Is this my understanding correct? Or am I missing something? Or this should be done by usb host driver itself?- so usb host driver resets the device once it deciphers the standard set_address command?

3. Also for setting the new address (for point vi), usbhost_enumerate() [in usbhost_enumerate.c] is calling DRVR_CTRLOUT. I think, this should be DRVR_CTRLIN, as host issues the address as setup packet and expects 0 bytes data as acknowledgement on control In pipe. 

4. In that way, can each controller port for USB host can have its own version of usbhost_enumerate.c? 

Any of your thoughts/ comments/ suggestions would help me.

With best regards,

Phani.

[Phani Kumar]

Hi Greg and all,

I am currently at the last stage of USB Host driver (currently using HID KBD for test) development. If any of you have developed this kind of Host driver/ ported - please let me know, your suggestions/ comments/ observations. It would help me a lot.

Currently I am done with the basic driver of USB Host. As soon as the device is connected, connect event triggers and enumerates the device. This completes getting all the details from device (mainly this is done in usbhost_enumerate.c). I can see all the data going from device and finally host also sets the configuration of the device. Which seems to be last stage of the enumeration. Also if I list the folder under /dev, I see kbda and assume enumeration is successful.

nsh> ls /dev
/dev:
console
kbda
null
ttyS2
ttyS8

After this, I don't see any thing from upper layer - so no activity happens on the bus. At this point (after enumeration is done), what is the next step? Who should start request to read the device (as the device is HID KBD, which is already identified during enumeration). 

Also I tried the Hidkbd example and I see the same behavior, as above. 

Any of your comments/ suggestions/ observations on what is the next step after enumeration - it would be really helps me a lot. 

Thanks in advance and With best regards,

Phani.

[Gregory Nutt]

... Also if I list the folder under /dev, I see kbda and assume enumeration is successful.

nsh> ls /dev
/dev:
console
kbda
null
ttyS2
ttyS8

After this, I don't see any thing from upper layer - so no activity happens on the bus. At this point (after enumeration is done), what is the next step? Who should start request to read the device (as the device is HID KBD, which is already identified during enumeration).

You need an application to open the keyboard device and read from it.  Try apps/examples/hidkbd.

The last time I used it, the driver worked but there were some debouncing issues that needed to be cleaned up.  I believe that there was a recent patch for keyboard debouncing, but I have never tried it.

Greg

[Gregory Nutt]

After this, I don't see any thing from upper layer - so no activity happens on the bus. At this point (after enumeration is done), what is the next step? Who should start request to read the device (as the device is HID KBD, which is already identified during enumeration).

You need an application to open the keyboard device and read from it.  Try apps/examples/hidkbd.

The last time I used it, the driver worked but there were some debouncing issues that needed to be cleaned up.  I believe that there was a recent patch for keyboard debouncing, but I have never tried it.

Someof the graphics layers can support keyboard input too.  NSH can also be configured to take input from a keyboard (CONFIG_NSH_USBKBD).

[Tom Hwang]

I'm almost the same situation as you currently.
did you find ways to get through it?

I'm also so struggling now.

I've treated M4 with IAR. but it's too difficult compared to IAR or Arduino even though just turning on LED with GPIO in the environment of NuttX.
Actually, it's my first target.

I wish seriously to get many examples as much as I can to get some hints for coding.
It's not easy to find tho... maybe it's so few...

I mean... I need some guidance.

2020년 1월 20일 월요일 오전 1시 16분 49초 UTC+9, Sainath Vanacharla 님의 말:

[Adam Feuer]

Tom,

Re: turning on LEDs via GPIO, have you looked at the NuttX apps/examples? There's this one for LEDs:

https://github.com/apache/incubator-nuttx-apps/tree/master/examples/leds

For GPIO there's this example that creates a command that will set or unset GPIO pins:

https://github.com/apache/incubator-nuttx-apps/tree/master/examples/gpio

-adam

--

You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/9edaa303-4083-416b-90e3-bd9e03d3446b%40googlegroups.com.

--

Adam Feuer <ad...@starcat.io>

[Phani Kumar]

Hi All,

Recently I ported the NuttX USB Host to one of the hardware which is plain USB host (which does not adhere to any of the spec - OHCI/ etc).  I have captured some of my learning and understanding in attached document. I think, this would be useful to some one who wants to port NuttX USB Host to non standard USB host hardware, or some one have better suggestions on this. 

With best regards,

Phani.

--

You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/8f82d65c-494d-9d24-5cb9-91ddc2604b02%40gmail.com.

[Nathan Hartman]

On Thu, Apr 16, 2020 at 9:07 AM Phani Kumar <phanik...@gmail.com> wrote:

Hi All,

Recently I ported the NuttX USB Host to one of the hardware which is plain USB host (which does not adhere to any of the spec - OHCI/ etc).  I have captured some of my learning and understanding in attached document. I think, this would be useful to some one who wants to port NuttX USB Host to non standard USB host hardware, or some one have better suggestions on this. 

Thank you for sharing!

Cheers,

Nathan

[Phani Kumar]

Hi Greg and all,

Currently I am working on USB Host which is plain USB host hardware (which does not adhere to any of the spec - OHCI/ etc - provides plain registers interfaces to manage data flow).  I have ported NuttX USB Host for Mass storage (MSC) and it is working well for basic testing like, mount/ copy files/ remove files etc. 

As part of throughput measurement, I am trying to copy huge files with size around 200+ KB. Some times, copy succeeds and some times code waits indefinitely. On looking at the USB analyzer logs, I see below pattern. 

1. Upper layer (usbhost_storage.c) keeps sending CBW (Command Block Wrapper), Data (always 512 bytes) and CSW (Command Status Wrapper) in usbhost_read() and usbhost_write() functions.

2. When I see the issue, it is due to 

a. Previous block is transmitted.

b. Upper layer (usbhost_storage.c) is trying to transfer the next block and sends the CBW (31 bytes)

c. Device (using normal pendrive) seems to be busy (possibly it is managing the internal details with previously received data) and there is no response.

d. My USB Host device waits for turn around time and raises interrupt Not Ready (NRDY). 

3. With this scenario, I am trying to find out, is there any way, driver can intimate the upper layer that device is busy/ not responding, so that upper layer can retry sending the data? I looked at ..nuttx-8.2\include\errno.h and could not figure out which one is the correct error to be returned for usbhost_storage.c so that re-try can happen (EBUSY seems to be ideal, but I did not see the retry after returning this EBUSY error).

Please let me know if you have any suggestion/ comments on handling this kind of device behavior.

With best regards,

Phani.