Mecrisp on the TI Stellaris Launchpad

On 4/18/2015 4:32 AM, David Brown wrote:
> On 18/04/15 02:03, rickman wrote:
>
>> I don't wish to insult anyone.  But I will say that I have tried to
>> learn linux several times and found poor support from the linux
>> community.  Mostly I think there is an attitude that "we" (the linux
>> community) got it *right*, when there are many, many more PC users, even
>> professional programmers, than there are working under Linux.
>>
>> Ok, everyone is entitled to their opinion.  But the problem arises when
>> it is not understood that this is an opinion, not a universal truth.
>> There are good and bad things about both linux and windows.  I would
>> like to learn about linux now, so I won't ask "why" anymore.  I'll just
>> accept the things that are goofy about it just as I have done with
>> windows for many years.
>>
>
> How people answer questions is going to vary a great deal, no matter
> what the subject and what the group - don't tar all "linux communities"
> as being bad support.  But if you /do/ feel you are getting bad support
> somewhere, ignore them or find another forum - don't stop asking
> questions, and never stop asking "why?".  It's crucial to learning.

Thank you for the support.  I *did* let it stop me from learning Linux 
on several occasions.  But now that I have a project for the rPi, I have 
more incentive to dig in.  I'm spending a lot of time with this now.


> I fully agree that there are good and bad things about Linux and
> Windows.  I couldn't do my work with only one of them.
>
> It is the "power users" from Windows that find Linux hardest, precisely
> because there are many small differences that lie under the surface,
> unseen by users who are satisfied by email, browser, media player and a
> few games.
>
> But there are many things about the Unix design that have turned out to
> be very good decisions.  When you look at the differences between Linux
> and Windows, many aspects trace their roots back to the beginnings of
> the systems - for Linux, this was Unix of the 70's, and for Windows it
> was MSDOS.

Lol, I was actually using Unix in the 70's, the era of command line 
processing.  I learned cat I recall... but not much more.  I think I 
used it some more in the 90's, but didn't find that experience rewarding 
at all.  For some reason the delete and backspace keys were reversed on 
our workstations and I was told I could define it any way I wished... 
lol.   Not much good if you don't know how to redefine it.


> And then consider where Unix came from - it came from
> serious computing professionals, big companies, big universities, big
> multi-user computers.  It has always been serious stuff, made by serious
> people.  MSDOS, on the other hand, was a con-job pulled off by a couple
> of guys (admittedly quite good programmers), hacked together for a
> marketing exercise that was never meant to be used for real work.
>
> Some Linux users therefore feel completely justified in being arrogant
> about the superiority of the Linux "guts" compared to that of Windows.
> But if it bugs you (and it certainly can be annoying), just ignore it
> and move along.

I don't care about origins or intent.  I just want to get some work done 
with the minimum of hassle.  I'm still amazed at how slow computers have 
gotten as the CPUs have gotten faster.  The rPi is no exception.  It is 
many times faster and has much more memory than the machine I first got 
on the Internet with.  But I guess browsers and HTML have changed to 
demand more.  That's the main reason why I want to use Forth.  It is 
very light weight and puts little strain on the system hosting it. 
Heck, Mecrisp runs entirely on the target!

-- 

Rick

On 4/18/2015 11:15 AM, Martin Gregorie wrote:
> On Sat, 18 Apr 2015 09:32:24 -0400, rickman wrote:
>
>> But that doesn't explain the issue I have where quoted text in the
>> window for composing messages often is not wrapped and runs off the edge
>> of the window.  Any idea what causes that?
>>
> I some NNTP clients don't seem wrap outgoing lines, But I don't know
> which ones they are.
>
> Pan has the ability to display incoming messages as they were received or
> after wrapping them, which is quite useful.
>
> Wrapping is useful if long lines are received, but it can mess up lines
> which start with hyphens or asterisks because it thinks that means 'join
> to preceding line' rather than 'another item in the list'. Hitting 'w'
> toggles between wrap and no-wrap so either way the fix is instant.

I don't wish to belabor this too much.  It is off topic and I just 
thought someone with Thunderbird experience might have a quick answer. 
This issue is not on reading messages, that always wraps lines so they 
are viewable.  It is the quoted text in the reply that will not be 
wrapped if it is not broken in the received message.  Very odd....

-- 

Rick

On 18/04/15 15:56, rickman wrote:
> On 4/18/2015 4:16 AM, David Brown wrote:
>>
>> Once you have figured out what devices you are plugging in, and where
>> ("lsusb" and "lsusb -v" are very handy), udev rules are your friend for
>> making it all consistent and easy to use.
>
> Ok, lsusb is helping.  If I plug into the "device" port on the launchpad
> *nothing* shows up.  If I plug into the "debug" port it shows up as
> dev1.7.  This is on the same port that was showing a mouse as dev1.6.
> But this is a start.  I guess I was using the wrong port on the launchpad.
>
>
>> This is from my "52-david.rules" file in /etc/udev/rules.d on my
>> development PC (the rules files are read in order, so the "52" is about
>> the middle) :
>>
>>
>>
>> KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.1/2-1.1:1.0/*", SYMLINK +=
>> "ttySerial_hub1"
>> KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.0/*", SYMLINK +=
>> "ttySerial_hub2"
>> KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.0/*", SYMLINK +=
>> "ttySerial_hub3"
>> KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.4/2-1.4:1.0/*", SYMLINK +=
>> "ttySerial_hub4"
>>
>> KERNEL == "ttyUSB*", ATTRS{idVendor} == "0403", ATTRS{idProduct} ==
>> "6001", \
>>    ATTRS{serial} == "FTFLYG0L", SYMLINK += "ttySerial_ttl1"
>>
>> ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", \
>>    ATTR{serial}=="FTUSV1RA", SYMLINK += "ttySerial_232"
>>
>>
>> The key points here are to give a list of identification checks (like
>> the ttyUSB kernel driver, used for FTDI devices, or the physical path
>> through hubs, or the serial numbers, vendor IDs, etc., of the device),
>> and then a list of commands.  Typical commands change the permissions
>> (to make particular devices available to particular users), and SYMLINK
>> to make new symbolic links.
>
> I appreciate the help, but I don't understand much of this.  Like I've
> said, I'm a complete noob at Linux.  Do I need to do any of this?  There
> is only one user, "raspberry".

No, you certainly don't /need/ any of it.  But it can sometimes make 
life a little easier.  If you only use one user, and have made sure that 
it is in the right groups (typically "dialout" and/or "plugdev" - 
details vary from distro to distro), then you will have full access to 
the USB serial devices.  If you have problems, you can also access the 
port as "root".  (Some people will call such advice blasphemy, but 
sometimes it is simply easier to do things as root.)

Other than that, keep a note of this post.  If you want to use more 
devices in the future and get consistent names, then it will give you 
clues - especially when combined with a google search for udev rules. 
(Of course, you could also post again here.)  Even if you don't need 
these things now, it might be useful to know about them in the future.

>
>
>> So with this setup, I have a four-port hub that I use to connect FTDI
>> serial ports - TTL, RS232, RS485, etc.  When I connect then, the first
>> connected gets /dev/ttyUSB0, then the next gets /dev/ttyUSB1, etc.
>> Unlike Windows, the numbers are not tracked by serial number of the
>> device - this means the same devices entered in different orders get
>> different numbers.  On the other hand, you don't end up with numbers
>> like COMM123 ...
>>
>> With the udev rule above, the devices get additional names when plugged
>> into particular ports on the hub.  This means that I always know exactly
>> which device is which, using those symbolic names.  It doesn't matter if
>> /dev/ttySerial_hub2 points to /dev/ttyUSB0 - I know which port it is
>> attached to.
>
> But only if the devices are connected in the same order each time.  I
> noticed that when the mouse is plugged in it was port 1.6.  When I
> unplug it and use that port for the launchpad it becomes port 1.7.  Is
> that expected?

Yes - some of the number in USB devices simply increments each time a 
device is attached.  The DEVPATH I used in the rules above does not act 
like that - it is a tree based on the physical path through hubs, and is 
thus completely independent of the ordering.

>
>
>> Another quick point - if you are working with serial ports, and you like
>> Python, don't forget that pyserial is your friend :-)
>
> It may be my friend, but I can't figure out how to run it...  Is that
> what friends are about, hard to understand?  I also can't figure out how
> to run miniterm.  Google searches... or more accurately a duckduckgo
> search on miniterm I get all manner of links to pyserial and few, if
> any, to miniterm.  The noob factor is at work.  I can download what
> seems to be pyserial, but I can't figure out how to run it as an
> application.
>

pyserial is not an application - it is a library for Python.  If you 
have experience with Python programming (or /want/ experience with 
Python programming - it's a nice high-level language, fully 
cross-platform), then you should find pyserial quite easy to use.  You 
can try it on Windows first for familiarity - it works there too.

But if you haven't used Python, then pyserial is not your friend for now!


As I noted elsewhere, try "screen" rather than miniterm - "screen 
/dev/ttyUSB0 115200" gets you connected at 115200 baud.  Obviously 
change the /dev/ttyUSB0 as needed.

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.

>--
>
>Rick

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 18/04/15 17:04, rickman wrote:
> On 4/18/2015 4:38 AM, Jan Coombs <Jan-54 wrote:
>> On Fri, 17 Apr 2015 20:20:30 -0400
>> rickman <gnuarm@gmail.com> wrote:
>>
>>> Now I am a bit stuck trying to get a serial port terminal emulation
>>> running.  It would appear that miniterm is the right program to use, but
>>> while dealing with the slowness of the rPi when web browsing I have yet
>>> to find it exactly.  I thought I had found it at a site called Py
>>> Serial.  But I think what I downloaded with some sort of python wrapper
>>> for miniterm.  I'm not sure really.
>>
>> gtkterm is simple and capable, but can't find rPi to check
>> this :(  To install, type at  terminal:
>>
>> sudo apt-get install gtkterm
>
> Sounded good, but didn't work.  I am familiar with the "sudo apt-get
> install" thing.  I think that was the first thing I learned a few weeks
> ago (or was it months?) when I first powered up the rPi.  This time it
> says "Unable to locate package gtkterm".

Personally, I like to save a bit of "sudo" by doing "sudo su -" first, 
to get a root login, and then just typing commands without the sudo stuff.

Make sure you have updated your repository lists ("apt-get update"). 
Then try a search ("apt-cache search gtkterm") - maybe it has a slightly 
different name on your distro.

>
> It would be so much easier if I could access newsgroups on the rPi.  Oh
> well...
>
>
>>> Even once I get a terminal emulator running, I'm not sure how to find
>>> the ID of the device I'll be talking to with it.  It is a TI launchpad
>>> with a USB emulated UART.  These things are like falling off a rock in
>>> the PC world... mainly because I've come up the learning curve and know
>>> it.  Will miniterm have the smarts to find the one serial port on the
>>> machine or do I have to figure out the ID of this USB serial port and
>>> tell it?
>>
>> In a terminal type:
>>
>>    dmesg | tail
>>
>> and you will see the end of the system log.  If you just
>> plugged the USB, then you should see something like:
>>
>> "FTDI USB Serial Device converter now attached to ttyUSB1"
>>
>> For the above, the com port name/location is /dev/ttyUSB1
>
> Yeah, I've already figured out I was using the wrong port on the
> launchpad for the UART.  Seems it is the same port as the debugger.  So
> now I can see it.
>
> I have to switch it out with the mouse and every time the USB number
> increments.  The mouse is now on port 1.8 lol.

Yes, but that number doesn't matter much - don't worry about it.

>
>
>> To access the comm ports as a regular user you might need
>> to join the dialout group.  To check current status type:
>>
>>    groups
>>
>> To add user "rick" to dialout group, type at  prompt either
>> of these: (your user name might be "pi")
>>
>>    sudo usermod -a -G dialout rick
>>    sudo adduser rick dialout
>
> Now I just need to figure out my user name.  I haven't logged into this
> thing in months.  I believe the default is raspberry.

Use "whoami" to confirm that.

Also use "ls -l /dev/ttyUSB*" to confirm that the group you want is 
"dialout" - distros vary on the details.

Note that you need to log out, then log in again, in order for the new 
group membership to take effect.

>
>
>> Checked this on my desktop, so maybe not quite so.  The
>> rPi will run a number of linux systems, so if you have
>> further problems say which version of linux it is running.
>>
>>    uname -a
>>
>> I recently connected the little MSP430 launchpad board at
>> work, and struggled.  I could re-check this on Monday.
>
> I'm running Raspbian.  I think I have all the pieces now except a
> terminal emulator.  When reading about miniterm it says it lets the
> command window handle ANSI code formatting and that window is called
> "terminal".  I'm wondering if I need a terminal emulator at all.  I
> guess the "terminal emulator" reroutes the keystrokes to the serial port
> output and the serial port input to the display.  There would be no way
> to do that with pipes or such.  That would allow me to control the
> command window from the serial port perhaps which is not what I need.
>

On 18/04/15 17:26, rickman wrote:

>
> I don't care about origins or intent.  I just want to get some work done
> with the minimum of hassle.  I'm still amazed at how slow computers have
> gotten as the CPUs have gotten faster.  The rPi is no exception.  It is
> many times faster and has much more memory than the machine I first got
> on the Internet with.  But I guess browsers and HTML have changed to
> demand more.  That's the main reason why I want to use Forth.  It is
> very light weight and puts little strain on the system hosting it. Heck,
> Mecrisp runs entirely on the target!
>

"Software gets slower faster than hardware gets faster."

(I can't remember whose "law" that is.)

On 17/04/2015 22:02, rickman wrote:
> I was commenting on the facts that there is a quarter volt lost across
> the rPi

It doesn't matter how much "is lost" because the final voltage is within 
spec. I don't know about the hub and PHY on the Pi, but all the PHYs we 
produce have the ability to disable VBUS on each port and can signal 
over current conditions. When a device pulls too much current you signal 
the USB MAC and it tells the PHY to kill VBUS. The missing volts will be 
loss in the PHY VBUS switch most likely.

I don't work with our PHYs directly but only with the USB MACs we 
produce so I can't recall off the top of my head if the over current is 
as programmable as the current the device claims during enumeration. 
Devices specify their max current requirements in multiples of 2mA 
units. Before enumeration, the spec allows 100mA and I'm fairly sure our 
PHYs will signal over current if something tries to draw much more than 
100mA. Once enumerated, again I'm fairly sure the over current level is 
programmable.

> and that the launchpad seems to reset when I type on the USB
> keyboard.

If the launchpad lies during enumeration then this can happen. It's not 
helped by the early Pi hardware being a bit more than flakey.

>  Maybe it's not voltage related, but the quarter volt drop is
> unexpected

Not when you know there are switches between the power rail and VBUS as 
previously stated.

>and there are plenty of cases where even an older mouse, like
> the one I have, can't be powered through the rPi.

I have lots of devices that work perfectly with a Pi as long as they are 
connected before the Pi (model B, 512M) is booted. Plugging them in once 
booted normally results in a crash. Which is a shame as USB is designed 
to be hot-pluggable.

I should really say that I am shocked, nay stunned to find that a �30 
single board PC which can be battery powered that runs Linux and 
provides a metric shit-load of IO in addition to Ethernet and USB has a 
number of gotchas and issues. ;-)

On 15-04-18 16:32 , rickman wrote:

> But that doesn't explain the issue I have where quoted text in the
> window for composing messages often is not wrapped and runs off the edge
> of the window.

That occasionally happens with Thunderbird for me, too.

> Any idea what causes that?

No, I don't.

> It makes it very hard to see what I am replying to.

Yes. But there is a useful menu command Edit->Rewrap which wraps the 
quoted text.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

David Brown <david.brown@hesbynett.no> writes:
>> I'm still amazed at how slow computers have gotten as the CPUs have
>> gotten faster.  The rPi is no exception.  It is many times faster and
>> has much more memory than the machine I first got on the Internet
>> with.  But I guess browsers and HTML have changed to demand more.

Certainly today's web pages have ridiculous amounts of javascript on
them.  Rick could try a simpler browser like dillo (dillo.org), that has
no JS and is very fast, but there's lots of sites that won't work.

>> That's the main reason why I want to use Forth.  It is very light
>> weight and puts little strain on the system hosting it.

Python is nowhere near as light as Forth but it works pretty well on the
Pi, from what I hear.  I used it on a much less powerful board than the
Pi and it was great.

> "Software gets slower faster than hardware gets faster."
> (I can't remember whose "law" that is.)

I thought this was interesting: 

http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

it points out that people have always dealt with unacceptably slow
computations by limiting what they compute.  "Example: In your favorite
sword-fighting video game, are light reflections affected realistically
by sword vibration?"

There's more abstraction and interpretation burning cpu cycles in
today's software, but the software is also doing more for people than it
used to.

In message <mgtmbd$582$1@dont-email.me>
          rickman <gnuarm@gmail.com> wrote:

> On 4/18/2015 4:00 AM, David Brown wrote:
>> On 17/04/15 21:12, rickman wrote:
>>> On 4/17/2015 2:47 PM, rickman wrote:
>>>> On 4/17/2015 12:56 AM, Paul Rubin wrote:
>>>>> rickman <gnuarm@gmail.com> writes:
<snip>

>>
>> But Thunderbird re-wraps for display - if the lines in a post are not
>> quoted, and appear to be a line-wrapped paragraph, it re-wraps then to
>> the width of the window.  I am somewhat in two minds as to whether this
>> is a good thing or a bad thing, but I haven't tried to turn it off.
>>
>> So your posts from Thunderbird are absolutely fine.

> Thanks for the info.  It's good to know this is correct.  There is one
> nut case in the Forth group who replies to my posts with a bit of boiler
> plate added saying my lines were not wrapped correctly and he rewrapped
> them for me, lol.

> But that doesn't explain the issue I have where quoted text in the
> window for composing messages often is not wrapped and runs off the edge
> of the window.  Any idea what causes that?  It makes it very hard to see
> what I am replying to.  This message seems to be just fine, I suppose
> because the lines *are* wrapped.  Looking at my post from April 16 at
> 5:24 PM I see my lines are *not* wrapped.  I see in the source the =
> char at the end of each line which I assume means a continuation.
> Strange...  This seems to not be wrapped in the composition window when
> replying.

The = at the end of each line means that the message was sent using 
"quoted-printable" encoding, but has not been decoded correctly. This 
might be a problem at your end, but more likely means that along the 
line the descriptor which identified the encoding has been lost, 
replaced or mangled.

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/