Mecrisp on the TI Stellaris Launchpad

On 2015-05-10, rickman <gnuarm@gmail.com> wrote:
> On 5/10/2015 5:37 AM, Simon Clubley wrote:
>>
>> Check the flow control is what you would expect; incompatible flow
>> control settings could _easily_ cause this.
>
> What should it be set to???
>

[I'm not quite sure what you are asking as only you know which flow
control is in use here, so apologies if the following is redundant.]

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.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 5/10/2015 7:42 PM, Simon Clubley wrote:
> On 2015-05-10, rickman <gnuarm@gmail.com> wrote:
>> On 5/10/2015 5:37 AM, Simon Clubley wrote:
>>>
>>> Check the flow control is what you would expect; incompatible flow
>>> control settings could _easily_ cause this.
>>
>> What should it be set to???
>>
>
> [I'm not quite sure what you are asking as only you know which flow
> control is in use here, so apologies if the following is redundant.]

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.


> 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.

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 = <undef>; 
eol2 = <undef>; swtch = <undef>; 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.

-- 

Rick

On 4/18/2015 11:52 AM, Albert van der Horst wrote:
> In article <mgtsk2$v6j$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> <SNIP>
>>
>> So is noforth documented much?  That is one problem I'm having with
>> Mecrisp.  It doesn't have a lot of documentation, which is something I
>> would like to work on.  Matthias has ported it to several MSP430s and
>> then discovered the ARM CM line.  I think there are some dozen ARM
>> targets ready to fire up on eval boards.  He really liked the STM line I
>> think.  I have an old Motorolla board that should be worth firing up and
>> I think the processor has a version ready for it.  Cool.
>>
>> But if noforth would get me to my goal more quickly on this task, I
>> would like to consider it.  But it looks like it is only for the MSP430
>> and not the ARM board I currently have.
>
> I think the documentation of noforth is quite formidable. Not only the
> examples, the system itself and the way to make turnkey systems, but also
> the metacompiler, which is somewhat rarer.
> We (Dutch Forth chapter) are in the process of helping the authors
> to make the system somewhat easier to find, (probably BitBucket)
> and the authors have GPL-ed it, such that the copyright status is clear.
>
> It is mature, as the example I gave was three year ago, and quite some
> improvements have been made, in particular the number of boards that
> are supported. But sorry, it is MPS430 only.

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. 
4E4th, noforth and mecrisp.  All three are from the area around Germany 
(as far as I can tell).  I have been working with Mecrisp and am at 
quite a disadvantage not knowing the language of the comments.  :(

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

-- 

Rick