Hot!Command service on USART port : no prompt

Author
gblkom
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2016/09/06 08:35:35
  • Location: 0
  • Status: offline
2016/09/15 07:33:36 (permalink)
0

Command service on USART port : no prompt

I've tried to create a very simple project with a command prompt on "USART ID 5" of a PIC32MX795F512L, using Harmony 1.08.01 and MHC 1.0.8.7.
In MHC I've enabled :
  Drivers/USART
  System services
    Command
    Console
The result is that I get no prompt; however if I add some SYS_CONSOLE_MESSAGE() in APP_Tasks () they are printed correctly.
After some debug in sys_command.c (provided by Harmony), I discovered that the state of the command service (pCmdIO->cmdState) was permanently SYS_CMD_STATE_DISABLE. Command init SYS_CMD_Initialize() is called before console init SYS_CONSOLE_Initialize() in SYS_Initialize (), but as the console is not yet ready at command init, the command service state is set to  SYS_CMD_STATE_DISABLE and I don't know what I'm expected to do to make it jump to another state. No Harmony project example is available for a simple command prompt on USART (as always we have complex examples but no basic one),
At the end I've applied a workaround to sys_command.c in SYS_CMD_Tasks() to get the prompt (see + lines) :
               case SYS_CMD_STATE_DISABLE:
                    //App layer is not ready to process commands yet
+                    if ((*pCmdIO->pCmdApi->isRdy)(pCmdIO))
+                        pCmdIO->cmdState = SYS_CMD_STATE_SETUP_READ;
                    break;
Did I missed something ?
What is the right way to make it work.
#1

10 Replies Related Threads

    MicroE
    Starting Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2016/10/06 15:59:04
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2016/10/11 17:31:01 (permalink)
    5 (1)
    I ran into the same issue - In my searching I noticed in one of the command console examples that the function:
     
    SYS_CMD_READY_TO_READ(); 


    Is called in the application task.  If you look at this function you will find it does much more that just report the status :(   Adding this fixed the issue for me.
    #2
    gblkom
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2016/09/06 08:35:35
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2016/10/13 07:08:33 (permalink)
    0
    Thanks a lot for your reply.
    I think you're right about SYS_CMD_READY_TO_READ(). I saw this function during my debug and tried it, but I did not realized I had to call it periodically.
    I called it only once and this was the mistake.
    In addition, as I also needed to change the prompt string (that is ">" by default), I used a patched version of sys_command.c as workaround because I did not find any other way to override this #define _promptStr in the framework's sys_command.h
     
    #3
    gbuloz
    New Member
    • Total Posts : 8
    • Reward points : 0
    • Joined: 2016/10/08 13:33:35
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2016/10/27 13:28:26 (permalink)
    3 (1)
    I've also noticed that command history was not working. After some debug I found that in SYS_CMD_Tasks() the caracters are read one by one, but the escape sequence processing is expecting 3 bytes read at once. I've added the required fix needed to read the 2 missing bytes.
    Then I saw that insertion at curent cursor position (when using left and right keys) was not corectly handled and displayed.
    I've enhanced the history output on the comand line.
    There was also some bugs with pCmdIO->cmdPnt and pCmdIO->cmdEnd
    I've also added CTRL-C to cancel the current input (also any invalid ESC sequence such as proessing ESC 3 times works)
    Then I've changed the prompt string to my need and increased history size to 10
     
    I use a modified copy of /opt/microchip/harmony/1.08.01/framework/system/command/src/sys_command.c that I put in my sorce tree, and exclude the framework one from the project.
     
    Please find the modified file and alternatively the patch for Harmony 1.08.01.
     
    I still have characters lost when pasting a command to the command line. This can be fixed by running the console and command task at full speed without any delay (or at least a YIELD() under FreeRTOS), but this consumes CPU just to read characters from the USART. Using a vTaskDelay() with 1mS idoes not always works with prompt at 115200 bps.
    I've tried to use bigger USART driver and console buffers, even DMA, without any success.
    Any workarond suggestion would be welcome.
    #4
    jcandle
    Super Member
    • Total Posts : 207
    • Reward points : 0
    • Joined: 2011/09/19 22:01:53
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/07 22:36:55 (permalink)
    0
    Having the same headache with all of the demo IO.  The correct RTOS specific behavior would be a read that blocks with a timeout.  With the timeout small enough, typed characters could be handled as needed while the interrupt driven buffer layers would capture fast data.
     
    Just getting in to it, so all I can say is what it should do...
     
    I did try buffers larger than 1 and it seems like it won't return until all of the buffer is filled then...
    #5
    BillP
    Super Member
    • Total Posts : 194
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/08 09:55:49 (permalink)
    3.5 (2)
    There is another option.  Use the USB_CDC library (dual port) and write your own command processor and log messages.  I show how to do this with all the source code and MHC setup in my Harmony book ("Harmony for PIC32MX Applications" from Amazon).  
    #6
    jcandle
    Super Member
    • Total Posts : 207
    • Reward points : 0
    • Joined: 2011/09/19 22:01:53
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/08 16:35:11 (permalink)
    0
    Bill,
     
    What is a reasonable sustained throughput on CDC at 200MHz?  I need to receive and process (push to a destination USART) 2-513 bytes packets every 20-25ms with unbroken 250KB out two ports.  Assuming the PC/MAC pumps out a stream at "921600" over USB with data for both and also servicing a WINC1500 (one or the other but not both pushing data).
     
    I have mostly worked bare metal dePIC33 and did the state machine for protocol right in the interrupt --> pushing packets to FreeRTOS queue for processing. 
     
    I will look into the book.
    #7
    BillP
    Super Member
    • Total Posts : 194
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/09 06:41:45 (permalink)
    3 (1)
    Hi,
    My understanding of a USB CDC device is that baud rate is not meaningful.  Harmony/MHC sets up a USB CDC device as FS (Full speed?).  That determines the "transfer rate" over a virtual COM port.  Since there are PC serial communications programs (e.g. CoolTerm) that run at 230,400 baud, I doubt a USB CDC link would have any trouble with your 250KB requirement.
     
    For larger and faster transfers, I suggest a TCPIP client/server.  Much faster and less load on the CPU.  If you are transferring the same data structure repeatedly, you might consider a UDP broadcast for even faster transfers.
     
    In either case, I believe a PIC32MX or MZ device configured with Harmony should work just fine without even breathing hard.
     
    BillP
    #8
    jcandle
    Super Member
    • Total Posts : 207
    • Reward points : 0
    • Joined: 2011/09/19 22:01:53
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/09 07:08:45 (permalink)
    0
    Bill, 2.04 on an MZ appears to set it up high speed.  I am telling SimpleTerm Gold it is 921600 and "it works".  I say that in quotes because the two port demo handles characters one by one and looses everything else sent in a fast burst. 
     
    The product spec I am working at is dual DMX output fed from either WiFi or USB.  I am leaning at UDP with an ACK packet back and datagram sizes of up to 520 bytes posted to a queue.  On USB, CDC is probably easier for the PC/Mac developer but HS-HOD with 520 bytes per packet would be cleaner for me.  Alas, we have now completely hijacked the thread.
    #9
    BillP
    Super Member
    • Total Posts : 194
    • Reward points : 0
    • Joined: 2014/09/28 07:53:35
    • Location: CA
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/09 08:23:37 (permalink)
    0
    Hi,
    Too bad about the thread, but this is more interesting.  I have not tried the USB host mode, but there are demos for it, so (eventually) it can be made to work under Harmony.  As for UDP, why would you want an ACK packet? What would you do with it?  Retransmit?  If that is needed, use TCP/IP.  If you are streaming data continuously, the next packet fixes whatever is wrong in the bad packet.  Just my opinion.
    #10
    jcandle
    Super Member
    • Total Posts : 207
    • Reward points : 0
    • Joined: 2011/09/19 22:01:53
    • Location: 0
    • Status: offline
    Re: Command service on USART port : no prompt 2017/10/09 09:10:56 (permalink)
    3 (1)
    it is DMX light controls, so I assume I need them all  I can use TCP/IP but the nature of the data lends itself to packets and not stream IO.  yes, I can send a length prefix and packetize a stream, but the hassle in reliably extracting binary data packets from a stream is more than sending "ack 0x########" to ack the nth scene.  So, data/ack/resend if needed.  I could go with a CRC and NACK on bad CRC.
     
    This is also why I am thinking HS HID, as it allows a 0-1024 byte packet.  I have to either have two endpoints for the two DMX queues with 512 bytes of data (and maybe a sequence preamble) or one endpoint which adds a byte saying which queue to drop it in.
     
    My real issue, either way, is that I need to sustain packets at faster than 12.5ms to keep ahead of the outbound, periodic data.  There really isn't a credible Windows timeout in single ms that makes sense.  I will have to discuss dropped packets with the client.  The other reason for ack'ing is to say there is still room on the outbound queue for more packets.
     
    Aside from buffering and timing the transmissions, there will be a comparator circuit decoding SMPTE timecode and an audio in that will periodically be sampled and FFT'd to send back a graphic equalizer image (just the points to create the image.)  I think once a second, in a low priority thread, should be good.
    #11
    Jump to:
    © 2017 APG vNext Commercial Version 4.5