Mecrisp on the TI Stellaris Launchpad

=?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de> writes:
>Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>> I think it has something to do with more usage of Unix/Linux by
>> non-programmers (to such an extent that they don't even write their
>> own shell scripts).
>
>I don't think that argument works.
>
>There have been platforms where a very large fraction of users never 
>wrote a program of their own.  The biggest of those has to be Microsoft 
>Windows, closely followed by MacOS.
>
>But Unix never was anywhere near the top of that category.  I'm not 
>aware of any system that encouraged users to write their own programs 
>more strongly than Unix did: the whole "toolkit" paradigm almost forced 
>_users_ to become programmers, at least at the shell script level.  And 
>how many other systems did come with a bona-fide HLL compiler right 
>there in the box?

Pretty much any home computer from the 1970s and 1980s included BASIC.
Yes, an interpreter, but that does not stop anyone from programming.

Anyway, Unix may have the highest proportion of programmers, but it
seems that non-programmers are the primary target of the Linux
distributions these days.  E.g., neither emacs nor vi nor Eclipse is
installed in Debian by default.  Or look at what programming languages
are installed by default.  Only those necessary for running the
scripts, no others.

Actually (and getting back on-topic a little bit) the Raspberry Pi was
created exactly to get away from the current non-programming culture
and get more people to program, like home computers did in the 1980s.

>> In the old times, we had "." first in the PATH.  If I am working on a
>> new version of Gforth, and am in the build directory of Gforth, then
>> saying "gforth" gives me the development version, not the installed
>> version.
>
>And that was baskk-ackward.  If only because it's a whole lot easier to
>and type the "./" prefix for the exceptional case of wanting something
>else than the normal instance of a command, than it would be to figure
>out where the "official" one might be, and type the full path to there 
>every time you want to be sure you get that.
>
>The distinction between "gforth" and "./gforth" is way easier to handle 
>than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" 
>and "gforth".

Not in my experience: If I am in a gforth build directory, I pretty
much always want to call ./gforth rather than /usr/bin/gforth when I
type gforth.  If I want to call /usr/bin/gforth, I either do it from a
different directory, or I say, e.g., gforth-0.7.0.

As for /opt, I don't know where that nonsense comes from, but it
certainly does not come from the original Unix.  Proper programs are
installed in one of the directories that users have in the PATH by
default (such as /usr/bin or /usr/local/bin) rather than somewhere in
/opt (which indicates that the programmer is too lazy to make a
working "make install").

>On Microsoft platforms, you have no control over it: the 
>system forces an implied '.' to the front of your PATH, whether you want 
>it or not.

On Windows and MacOS, the usual way to call a program is to click on
an icon, and AFAIK that works with absolute file names, no PATH
incolved.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

On 18/04/15 11:15, Anton Ertl wrote:
> =?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de> writes:
>> Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>>> I think it has something to do with more usage of Unix/Linux by
>>> non-programmers (to such an extent that they don't even write their
>>> own shell scripts).
>>
>> I don't think that argument works.
>>
>> There have been platforms where a very large fraction of users never
>> wrote a program of their own.  The biggest of those has to be Microsoft
>> Windows, closely followed by MacOS.
>>
>> But Unix never was anywhere near the top of that category.  I'm not
>> aware of any system that encouraged users to write their own programs
>> more strongly than Unix did: the whole "toolkit" paradigm almost forced
>> _users_ to become programmers, at least at the shell script level.  And
>> how many other systems did come with a bona-fide HLL compiler right
>> there in the box?
>
> Pretty much any home computer from the 1970s and 1980s included BASIC.
> Yes, an interpreter, but that does not stop anyone from programming.
>
> Anyway, Unix may have the highest proportion of programmers, but it
> seems that non-programmers are the primary target of the Linux
> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
> installed in Debian by default.  Or look at what programming languages
> are installed by default.  Only those necessary for running the
> scripts, no others.

Most distros install a subset of commonly used tools, and then make it 
easy for others to be installed.  There are vast numbers of tools, 
editors, languages, libraries, etc., commonly used by programmers - it 
would be ridiculous to install 2GB+ of popular programming tools when 
even most full-time programmers won't need them.  (i.e., /you/ might 
want emacs - but someone else will want eclipse, or vim, or jedit, or 
netbeans, or QT tools, etc.).

>
> Actually (and getting back on-topic a little bit) the Raspberry Pi was
> created exactly to get away from the current non-programming culture
> and get more people to program, like home computers did in the 1980s.
>
>>> In the old times, we had "." first in the PATH.  If I am working on a
>>> new version of Gforth, and am in the build directory of Gforth, then
>>> saying "gforth" gives me the development version, not the installed
>>> version.
>>
>> And that was baskk-ackward.  If only because it's a whole lot easier to
>> and type the "./" prefix for the exceptional case of wanting something
>> else than the normal instance of a command, than it would be to figure
>> out where the "official" one might be, and type the full path to there
>> every time you want to be sure you get that.
>>
>> The distinction between "gforth" and "./gforth" is way easier to handle
>> than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth"
>> and "gforth".
>
> Not in my experience: If I am in a gforth build directory, I pretty
> much always want to call ./gforth rather than /usr/bin/gforth when I
> type gforth.  If I want to call /usr/bin/gforth, I either do it from a
> different directory, or I say, e.g., gforth-0.7.0.
>
> As for /opt, I don't know where that nonsense comes from, but it
> certainly does not come from the original Unix.  Proper programs are
> installed in one of the directories that users have in the PATH by
> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
> /opt (which indicates that the programmer is too lazy to make a
> working "make install").

You appear to be supremely confident that your own personal usage of 
Linux, and your own (somewhat lacking and biased) view of OS history, is 
/the/ truth and /the/ right way to do things.  Linux, and Unix in 
general, is all about flexibility and the freedom to use the tools you 
want in the way you want.

So choose the PATH settings that work for /you/, and choose the file 
system organisation that works for /you/.  But don't try and tell 
everyone else that they are lazy or otherwise "wrong" for using a 
different organisation.

>
>> On Microsoft platforms, you have no control over it: the
>> system forces an implied '.' to the front of your PATH, whether you want
>> it or not.
>
> On Windows and MacOS, the usual way to call a program is to click on
> an icon, and AFAIK that works with absolute file names, no PATH
> incolved.
>

That's correct.  But DLL libraries and other files may need to be in the 
PATH (or a library path variable).

Am 18.04.2015 um 02:03 schrieb rickman:

> 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*,

In all fairness, from this end your attitude, particularly that 
"really!?", did come across pretty much the same, just applied the 
opposite way.  This attitude thing does cut both ways.

 > when there are many, many more PC users, even
 > professional programmers, than there are working under Linux.

That's the "trillions of flies eat shit, so that must be a good thing!" 
fallacy.  Democracy just doesn't work to decide about technical merit.

On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
> Am 18.04.2015 um 02:03 schrieb rickman:
> ....
>  > when there are many, many more PC users, even
>  > professional programmers, than there are working under Linux.
>
> That's the "trillions of flies eat shit, so that must be a good thing!"
> fallacy.  Democracy just doesn't work to decide about technical merit.
>

Certainly true, however its implication "this is what flies do, so
I shall not do it" is also a widespread fallacy (e.g. means you will
not consider flying as an option).
  Then the fallacy you point to is what most if not all of the
pro linux/gnu arguments are based on.

Your argument (from a previous post) about the user being left to
decide whether to have his current directory as one of his exec
paths is quite correct.

BTW, does anyone know how much unix is there within Android?
Its event timings and latencies are *so* pathetic I could not
imagine the entire linux thing would have survived that long if it were
that bad. Good thing tablet devices have become cheap enough to
not regret much if you smash one against the wall.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

David Brown <david.brown@hesbynett.no> writes:
>On 18/04/15 11:15, Anton Ertl wrote:
>> Anyway, Unix may have the highest proportion of programmers, but it
>> seems that non-programmers are the primary target of the Linux
>> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
>> installed in Debian by default.  Or look at what programming languages
>> are installed by default.  Only those necessary for running the
>> scripts, no others.
>
>Most distros install a subset of commonly used tools, and then make it 
>easy for others to be installed.  There are vast numbers of tools, 
>editors, languages, libraries, etc., commonly used by programmers - it 
>would be ridiculous to install 2GB+ of popular programming tools when 
>even most full-time programmers won't need them.  (i.e., /you/ might 
>want emacs - but someone else will want eclipse, or vim, or jedit, or 
>netbeans, or QT tools, etc.).

So what?  The distro also installs stuff like nano and an inetd that
most people don't use.  Somehow, when I last looked (a few years ago),
Debian installed nothing that I use, except a shell and apt-get;
that's ok when I ask for a minimal install, but requiring 600MB for
that alone is a bit stiff.  Anyway, in the old days distros used to
have options that said "typical server", "typical desktop", "typical
development environment"; I have not seen the latter option for a
number of years.

And installing hundreds of packages to get a decent environment gets
old quick, even if each package is easy to install.

>> As for /opt, I don't know where that nonsense comes from, but it
>> certainly does not come from the original Unix.  Proper programs are
>> installed in one of the directories that users have in the PATH by
>> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
>> /opt (which indicates that the programmer is too lazy to make a
>> working "make install").
>
>You appear to be supremely confident that your own personal usage of 
>Linux, and your own (somewhat lacking and biased) view of OS history, is 
>/the/ truth and /the/ right way to do things.

Sure, comes from experience, not just with Linux, but also with other
Unices for about 29 years.  If you want to counter my point, you could
try explaining the benefits of /opt instead of making an ad-hominem
attack.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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:
>>>>> I was using a gadget to measure the voltage and current going into the
>>>>> rPi.  That side is at 5.25 volts give or take with around 400 mA of
>>>>> current.  I moved the meter to the launchpad and the output on the USB
>>>>> port is only 4.95 volts.
>>>>
>>>> I remember reading somewhere (probably adafruit.com) that you should
>>>> use
>>>> a pretty beefy 5V power supply with the rpi especially if it's under
>>>> any
>>>> type of load.  They actually tweak their rpi power supplies to deliver
>>>> 5.25 volts to compensate for some inevitable sag.
>>>>
>>>> I don't remember hearing that the USB ports themselves are out of spec
>>>> but it's possible.  Despite popular misconception USB ports are only
>>>> supposed to be able to deliver 100 mA unless they grant the client
>>>> "permission" to draw more (up to 500ma), through a power negotiation
>>>> protocol that's part of USB.  Most x86 motherboards can deliver 500 mA
>>>> with no problem, so lots of badly designed client devices just assume
>>>> the power is available, and try to draw it without bothering with the
>>>> protocol.  Maybe something like that is going on here.
>>>
>>> I'm not 100% certain of this, but I believe the rPi runs input power
>>> through a Polyfuse which does have some noticeable resistance and so
>>> voltage droop.  I've cross-posted this to the rPi group to see if anyone
>>> will confirm it.
>>
>> I'm appending this OT post because I don't often look at my own posts,
>> but did this one.  I'm using Thunderbird and it seems to do odd things
>> with line breaking.
>>
>> It is common that I reply to ("Followup" in T-bird parlance) a post only
>> to find quoted lines extending off the page.  Ok, so T-bird doesn't
>> always figure out that it needs to wrap lines for display.
>>
>> But looking at my own post, I see the lines wrapping, but at the edge of
>> the screen, not at the 72 column point where line breaks should be
>> inserted when sending a message.  Changing the size of the window
>> confirms this.
>>
>> Then to make it even more confusing, in this reply it would appear that
>> line breaks are inserted in the quoted text!  WTF????!!!!  Anyone
>> understand how T-bird handles the line breaks, word wrap features?  Do
>> you see my posts with line breaks at 72 columns?  I have that turned
>> on... at least I thought I did.  I can't find the setting now.
>>
>
> Thunderbird is wrapping your lines perfectly well - you can see this by
> using ctrl-U to see the "source" of the posts.
>
> 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.

-- 

Rick

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


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


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

-- 

Rick

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

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.


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


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

-- 

Rick

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.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> In article <87oammuvhe.fsf@jester.gateway.pace.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> I'm going to get the better computer, but it costs $35.  The rPi
>>> 2... This thing is not much of a desktop.  I have a 10 year old
>>> machine that runs XP and does rings around the rPi.
>>
>> The Rpi is an embedded linux board that I hope is not being sold as a
>> desktop.  The Rpi2 has four cores each around 1.5x the speed of the
>> Rpi1, and I don't know if the parallelism will really help with web
>> browsing.  I can understand not wanting to lug a full sized laptop
>> around but there are some very nice, fast ultralights around these days.
>> I want one of these:
>> http://www.dell.com/us/business/p/xps-13-linux/pd.aspx
>
> That may be true. But with gforth on the rPi, I demonstrated the following
> on a fair, couple of years back:
>    - add only a screen and a keyboard
>    - run gforth to compile noforth
>    - install noforth on the launchpad
>    - compile a real time program for metallophones
>    - load it on the launchpad and make it a turnkey
>    - run the turnkey, even detached from the rPi
>
> So for old school, who worked on the pdp10's, it is a
> decent development system.
>
>>
>>
>> Ironically one of the easiest places to go look at one in person is the
>> Microsoft store.  But I'd buy the Linux version above.
>
> I've much more sbc's in store than I can get acquainted with in my
> lifetime ...

I know what you mean.  I have a small stack of MCU boards here I've 
never applied power to.  I bought four of the Cypress boards to help 
Matthais with Mecrisp only to find the Cypress development system is 
rather obtuse.  They intentionally hide as much as possible from the 
user... in this case a designer!  I had to ask all manner of questions 
to get something very basic going.  But the boards were only $3 or $4 in 
two slightly different flavors.  That's why I bought four, lol.

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.

-- 

Rick