Using minicom to communicate with ChipSHOUTER

#1

Hi,

We are using a Linux PC to communicate with the ChipSHOUTER and we have been able to successfully send commands and receive responses using the shouter-console.py Python script.

However, I would also like to use minicom to communicate with the ChipSHOUTER but I haven’t been able to determine the correct settings that allow any of the commands to be accepted. At this point, no matter what I command I enter after I hit the Carriage Return it displays the entire help menu with all the commands. It doesn’t seem to be recognizing anything I’m typing and just keeps showing the help menu. I’m confident I have the right serial port settings (115,200 baud 8N1) and I also have the following minicom settings:

Hardware Flow Control: No
Software Flow Control: No
Add linefeed: Yes
Local echo: Yes
Add carriage return: Yes
Terminal Emulation: VT102

Is there any reason why I can’t use minicom to communicate with the ChipSHOUTER instead of using the shouter-console.py script?

Please let me know if you have any questions and I look forward to your response.

  • Brad
#2

Hi Brad,

Your serial settings looks right, but I believe that commands are terminated only by a newline, not a newline + carriage return. Can you try removing the carriage return and seeing if the problem persists?

Alex

#3

Hi Alex,

Thank you for your prompt response.

Are you defining a newline as Line Feed (LF) [0x0A] or something else?

In the past, I have also seen a newline be defined as Carriage Return (CR) + LF but since you specified that the CR isn’t to be used I assume that only the LF should be used for the newliine. Is that correct?

  • Brad
#4

Hi Alex,

If I remove the from the minicom settings the help menu just does a line wrap in the minicom window. If I add the back in, then the help menu displays normally but it doesn’t recognized any of the commands.

If I temporarily run the shouter-console.py script, run a command to the ChipSHOUTER and then go back to minicom, then the last command I used under the script is the command that one that seems to be executed on the ChipSHOUTER every regardless of the command I use.

So far, I haven’t found any settings on minicom that allow the ChipSHOUTER to respond to any of the commands I type in. I have even tried to manually type in a LF [0x0A] with a Ctrl-J and that didn’t seem to make a difference either.

  • Brad
#5

Hi Brad,

Yeah, a newline is 0x0A, sorry about the confusion. Your settings look correct, so if you’ve disabled sending carriage returns I’m not sure what the issue is. Have you tried connecting to the ChipShouter using another serial terminal or via PySerial?

Alex

#6

Hi Alex,

I have tried using multiple different Linux terminal emulation applications including minicom, PuTTY and cutecom. I have also used the python-based serial console port script that is part of the ChipShouter git repository (shouter-console.py).

So far the only applications that work on our Linux-based PC are the shouter-console.py script and the cutecom application. The cutecom application is unique since it allows you to specify the termination character for the input to a Line Feed (0x0A). I have not found a way to do that on minicom or PuTTY.

I think this is basis of my problem since Linux uses only a line feed (0x0A) as the termination character. Using a Linux-based PC, have you successfully used any serial communication application to communicate with the ChipShouter? If so, which application and what were the configuration settings?

I currently don’t have access to a Windows-based PC so I can’t confirm that PuTTY communicates as expected with the ChipShouter.

I look forward to your response.

  • Brad
#7

Hi Brad,

Sorry I didn’t have enough time to get this tested on Friday. I’ll see if I can recreate your issue on Monday.

Alex

#8

Hi Brad,

I’ve tried connecting to the ChipShouter and I’ve found the following:

  • Termite on Windows seems to work, but PuTTy doesn’t
  • In Linux, minicom and screen don’t seem to work
  • Configuring the serial port via stty (
    stty -F /dev/ttyUSB0 115200 min 1 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -ecohe -echok -echoctl -echoke
    ) and then using echo and cat works. Minicom will configure most of this stuff on startup, so you may want to enter minicom and then exit immediately.

I’ll do some more experimenting and see if I can track down why some serial terminals work but others don’t.

Alex

#9

Hi Alex,

Thank you for the information.

I have a correction and a question:

On your stty command, I believe there is a typo in the -echoe parameter, the corrected version is:

stty -F /dev/ttyUSB0 115200 min 1 ignbrk -brkint -icrnl -imaxbel
-opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

Also, can you tell me how you used the echo and cat commands to verify the communication to the ChipShouter is working? I haven’t been able to get cat /dev/ttyUSB0 to return anything regardless which command I issue with the echo command.

I look forward to your response.

  • Brad
#10

Hi Brad,

Thanks for the correction on the command.

To read/write, I’ve been doing

# cat /dev/ttyUSB0 &
# echo <cmd> > /dev/ttyUSB0

Let me know if that works for you

Alex

#11

Hi Alex,

Thank you for your quick response.

That worked. I thought I added the ‘&’ at the end of my cat command to run it on the background but I must have done something wrong the first time.

Thanks!

  • Brad
#12

Hi Alex,

Were you ever able to determine what settings are needed to get the ChipSHOUTER to communicate and display correctly when using Minicom and/or PuTTY?

I’m still able to use the shouter-console.py python script but I would also like to communicate with this device using a standard serial communications application.

I look forward to your response.

  • Brad
#13

Hi Brad,

The issue you were having was caused by a firmware bug that caused the write to timeout, so for it to be fixed you’ll need to wait for a firmware update from us. In the meantime, you should be able to fix this by buffering the serial data (meaning it will send all at once when you enter a line break). I don’t have a ChipShouter serial interface on hand to test, but you might be able to turn buffering on by enabling cooked mode (# stty -F /dev/ttyUSB0 cooked), though I’m not sure if minicom overwrites these settings either.

Alex

#14

Hi Alex,

Thank you for your prompt reply.

Do you have an anticipated time frame when this firmware update will be available?

In the meantime, I’ll try the stty settings you suggested. If minicom adjusts these settings upon initialization, I’ll look into trying to have minicom and/or PuTTY use the enable the buffering.

  • Brad
#15

Hi Brad,

The update should be available fairly soon, assuming everything goes okay with the build. Otherwise, it may be a bit before we can roll the update out.

Alex