Mecrisp on the TI Stellaris Launchpad

I got minicom up (I was calling it miniterm, lol) but it doesn't seem to have a setting for translating LF to CR/LF. The Mecrisp app on the launchpad only sends LF.

I also tried setting the "implicit CR on LF" option in Putty which doesn't do the trick either.

Just to recap, I have the rPi running headless with the command line on the PC through SSH using Putty. The launchpad running Mecrisp is ttyACM0 on the rPi. Through the Putty session I am running minicom to the launchpad. Mecrisp seems to return "ok." which marches across the Putty window until it wraps at the right margin.

Any suggestions?

To answer your earlier question the problem was a short between the headphones. I was calling it miniterm rather than minicom. lol

I reached the point you describe where Mecrisp is not sending a CR with the LF and minicom can't seem to deal with that or Putty either oddly enough. I guess there is something about an SSH session that interferes with this.

I will try microcom (and not microterm, lol)

Yep, that did the trick. Now I just need to learn Mecrisp.

Someone suggested using microcom which handles the LF with no CR issue and I am talking to Mecrisp finally. Now I just have to learn it.

A fair amount of water has fallen over the damn and I have made some progress on my project. The Forth compiler is installed on the target. Using microcom on the rPi and Extra-Putty on my PC I can talk to the Forth program from the PC. Microcom got me around the problem I had with minicom where I needed the LF from the target translated to CRLF.

I have completed my hardware setup and have some software to test, but I can't figure out how to transmit a file to the target either from the rPi or from the PC. Microcom doesn't seem to have an option for sending a file to the target and Putty only seems to support X and Y modem, not a simple dump of a text file.

I found picocom and installed it on the rPi, but when I run it I get the configuration info and "Terminal Ready", but none of the commands seem to work. The escape key is supposed to be Cntl-A but nothing I type gets a response. I have to kill the putty session.

I took a few more steps today. I found that Mecrisp will accept definitions spread over multiple lines and that Putty has an option that lets you drag and drop a file to send it to the target. It doesn't work perfectly, but it works. Now I can run some source and test it.

To get something working better I tried using e4thcom which knows about the command line prompt in mecrisp and can load a file to it. e4thcom installed ok but when I run it I get no response from the target. I am invoking with this command...

e4thcom -t mecrisp -d ttyACM0 -b B9600

It reports this...

/dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR

but when e4thcom is exited stty returns this...

speed 0 baud; rows 0; columns 0; line = 0;

among other things. Why would the speed be set to zero?

Even when I run microcom the target does not respond. I have to reboot which resets the target too. :(

AIUI if you ask stty for speed, unless you give it a device name it'll return the speed of the terminal you're typing in at the moment. Terminal speed is, I think, supposed to be a hint to programs how much data they're likely to be able to output before the serial port gets congested. If connect to your Unix timesharing system via a VT100 then termcap will say it's at 9600 baud - not only do you need to configure the serial port but it could cause programs to adapt to the speed. This is all water under the

Is it anything to do with CTS/RTS/DSR/DTR? A slow serial line getting wedged isn't uncommon if you're lacking flow control and doing bulk downloads.

Theo

If you are checking it after exit, that means nothing as the program could be saving the current settings on entry and restoring them on exit.

Try using stty from another terminal while the program is running to see what the terminal settings have been set to by the program.

Check the flow control is what you would expect; incompatible flow control settings could _easily_ cause this.

Simon.

It could be software flow control, X-on, X-off getting wedged.

If you use serial over USB, the port settings like speed are virtually meaningless.

Groetjes Albert

It appeared to be the speed. It seems there is some different handling of the tty settings in the two programs, microcom and e4thcom so that e4thcom leaves the port is a state that disrupts microcom. I set the data rate from stty and got microcom to work again. But now something else is messed up and even rebooting and cycling power won't fix it. I can get microcom to work, but the target won't respond unless I hit enter twice rapidly. 8-*

This is getting to be rather frustrating.

We;come to the wonderful world of serial comms. I am SO glad is almost like a horse and cart,. There, but no one uses it

What should it be set to???

Only if it's emulated serial, for instance a 3G dongle pretending to be a modem. If it ever goes into real serial (eg a USB-RS232 adaptor) then the settings matter.

Theo

In this case there is a real serial port between the two chips on the launchpad. No handshakes though.

It sounds to me like you have managed to configure the target to autobaud mode.

Simon.

There are 3 options: hardware (usually CTS/RTS, but not always), software (usually XON/XOFF, but not always) and none (which relies on you having a large enough buffer or some higher level error detection protocol.

As the XON/XOFF characters appear within the data stream, you can't use XON/XOFF if they could ever be present in the data itself.

You can't have CTS/RTS active on the terminal program if the target doesn't support it. You can check with stty while your terminal program is running; look for the presence of "-crtscts" in the output to indicate that RTS/CTS flow control is disabled.

Also, just as an additional check, make sure DTR/DSR flow control is disabled as well (-cdtrdsr in stty) in case something wierd is going on with your terminal program.

Simon.

Yeah, well I don't know for sure, but I don't see any indication there is any flow control in use. The target board had two cpus. One is the USB debugger with a UART emulation. The target CPU uses a three wire interface, txd, rxd and gnd so no hardware handshaking. The application software is Mecrisp and I have not seen any indication it uses software flow control.

I xon/xoff is disabled, rts/cts is disabled and I don't see any display of dtr/dsr.

pi@raspberrypi ~/Projects/Breath/Stellaris $ stty -F /dev/ttyACM0 -a speed 115200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;

-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts

-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl

-ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0

-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop

-echoprt -echoctl -echoke

Now that I have fixed the character length and rebooted the target things seem to be working again. I wish I had a way to reboot the target from the PC, but for now I have to unplug the USB cable. Seems like there should be a way to cut power to a USB device via software. Don't the hubs have power control? I found a lot of references to software resets which have to do with disabling a hub or port, but I can't find anything that would be a hard reset to a USB device.

It sure seems like the EU is a lot more active in embedded Forth than here in the US. There are three embedded forths that I am aware of.

Still, it's nice to have these tools to work with and be able to run on embedded hardware.