Mecrisp on the TI Stellaris Launchpad

rickman <gnuarm@gmail.com> writes:
> I'm not familiar with irc.  I think I tried it once a long time ago
> and didn't get much traction with it.  I'm expecting there should be
> knowledgeable people in the rPi group.

Usenet probably predates the rpi by too much.  I'd suggest: download an
irc client (xchat.org has a nice one), connect to irc.freenode.net and
join the #raspberrypi channel.  There are also some web based clients
but I've always found them annoying to use.

On Fri, 17 Apr 2015 20:20:30 -0400, rickman wrote:
[ ... ]
> 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?

What do you mean by USB emulated UART?  When I plug one of my Sparkfun 
FTDI boards into a Pi, it shows up to lsusb as "0403:6001 Future 
Technology Devices International, Ltd FT232 USB-Serial (UART) IC" and 
gets assigned to /dev/ttyUSB0.
A different device, Arduino based, announces itself as "2341:0010 Arduino 
SA Mega 2560 (CDC ACM)" and gets assigned as /dev/ttyACM0.  This is on a 
stock Raspbian distribution.
The difference between the two is apparently that the FTDI emulates a 
UART, whereas the Arduino emulates a modem, and that's somehow recognized 
when they're establishing the USB connection.
If the Launchpad is supporting serial/USB on its own, as the Arduino is 
doing, I'd suspect it's following one of these two regimes, but it's up 
to udev rules in the Raspbian configuration to know this, probably from 
the manufacturer and device codes.  Hope this helps -- it's the limit of 
what I know.

On Fri, 17 Apr 2015 20:03:41 -0400, rickman <gnuarm@gmail.com> wrote:

>On 4/17/2015 6:25 PM, Hans-Bernhard Br&#4294967295;ker wrote:
>> Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>>> Blajrs Jrolrsen <boegre@no.com> writes:
>>>> On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
>>>>> Yes, I figured that out.  It seems the current working directory is not
>>>>> considered under Linux for finding executables... really!?
>>
>> Yes, really.
>>
>>> 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?
>>
>>> 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".
>>
>>> That disadvantage was worked around by removing the "." from the front
>>> and putting it on the back of the PATH.
>>
>> That workaround would be half-assed at best, because it relies on the
>> obviously flawed assumption that user will never mis-type commands.  But
>> because they do, it's relatively easy for an attacker to pre-load their
>> traps with lots of mis-typed versions of, 'ls', 'cd', etc.
>>
>> One other rather important aspect is that the way Unix does it actually
>> leaves you a _choice_ how you want this handled: _you_ define your $PATH
>> setting, so you can put '.' in there exactly where you want or need it,
>> or not at all. 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.
>
>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.


OTOH, even MS has decided that the Unix behavior is the correct one,
and PowerShell, largely the replacement for the old command prompt,
does *not* search the current directory for executables first.

On 4/17/2015 10:14 PM, Mel Wilson wrote:
> On Fri, 17 Apr 2015 20:20:30 -0400, rickman wrote:
> [ ... ]
>> 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?
>
> What do you mean by USB emulated UART?

What do you call a UART on a USB port?  These things are MCUs with a USB 
on one side and a UART on the hardware side.  The software on the PC 
makes them look like a UART to the PC, but the PC is really talking over 
USB.


> When I plug one of my Sparkfun
> FTDI boards into a Pi, it shows up to lsusb as "0403:6001 Future
> Technology Devices International, Ltd FT232 USB-Serial (UART) IC" and
> gets assigned to /dev/ttyUSB0.

The question is how do you know that?  As I have said, I know how to do 
this stuff under Windows, but not under Linux.

I've also posted that when I do an ls /dev/tty* I get a list of tty, 
tty0 through tty63, ttyAMA0 and ttyprintk.  This list does not change 
when I plug the device in or unplug it.  I also spent some time plugging 
in a number of USB UARTs and none of them showed up any differently this 
way.  I did find one that crashes the rPi as soon as I plug it in.  I 
expect this is part of the power issues the rPi has.


> A different device, Arduino based, announces itself as "2341:0010 Arduino
> SA Mega 2560 (CDC ACM)" and gets assigned as /dev/ttyACM0.  This is on a
> stock Raspbian distribution.

What do you mean, "announces itself"?  Where do you see that?


> The difference between the two is apparently that the FTDI emulates a
> UART, whereas the Arduino emulates a modem, and that's somehow recognized
> when they're establishing the USB connection.

I'm not totally clear on the difference.  A modem is connected to the PC 
via a UART.  To talk to a modem the software talks through the UART.  I 
suppose there is the AT command protocol that is used to control the 
modem which has nothing to do with the UART.  I guess the modem is like 
another layer on top of the UART although that assumes a smart modem as 
opposed to a dumb modem which just transmits the data it sees one bit at 
a time.


> If the Launchpad is supporting serial/USB on its own, as the Arduino is
> doing, I'd suspect it's following one of these two regimes, but it's up
> to udev rules in the Raspbian configuration to know this, probably from
> the manufacturer and device codes.  Hope this helps -- it's the limit of
> what I know.

Thanks for the effort, but no, this has not helped.  I understand modems 
and UARTs probably more than most people.  I don't know much about Linux 
and I don't see anything here that explains that.  I'm a complete noob 
at Linux, not computers.

-- 

Rick

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.

On 18/04/15 02:20, rickman 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.

If you are running from X, then there are a few terminal editor programs 
(including putty, which might be familiar to you from windows).

 From the command line, I prefer to use "screen" for serial ports.  I 
use "screen" at lot for other purposes (if you don't know it, look it up 
on google - it's very useful for getting lots of cli windows, but this 
is not the place for covering details).

screen /dev/ttyUSB0 115200



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

On 18/04/15 08:05, rickman wrote:
> On 4/17/2015 10:14 PM, Mel Wilson wrote:
>> On Fri, 17 Apr 2015 20:20:30 -0400, rickman wrote:
>> [ ... ]
>>> 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?
>>
>> What do you mean by USB emulated UART?
>
> What do you call a UART on a USB port?  These things are MCUs with a USB
> on one side and a UART on the hardware side.  The software on the PC
> makes them look like a UART to the PC, but the PC is really talking over
> USB.
>
>
>> When I plug one of my Sparkfun
>> FTDI boards into a Pi, it shows up to lsusb as "0403:6001 Future
>> Technology Devices International, Ltd FT232 USB-Serial (UART) IC" and
>> gets assigned to /dev/ttyUSB0.
>
> The question is how do you know that?  As I have said, I know how to do
> this stuff under Windows, but not under Linux.
>
> I've also posted that when I do an ls /dev/tty* I get a list of tty,
> tty0 through tty63, ttyAMA0 and ttyprintk.  This list does not change
> when I plug the device in or unplug it.  I also spent some time plugging
> in a number of USB UARTs and none of them showed up any differently this
> way.  I did find one that crashes the rPi as soon as I plug it in.  I
> expect this is part of the power issues the rPi has.
>

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.

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.

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.



Another quick point - if you are working with serial ports, and you like 
Python, don't forget that pyserial is your friend :-)

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.

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

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

 
> 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 


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


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. 

Jan Coombs
-- 
http://askubuntu.com/questions/112568/how-do-i-allow-a-non-default-user-to-use-serial-device-ttyusb0
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

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