Mecrisp on the TI Stellaris Launchpad

[rickman]

I am trying out Mecrisp on a TI Stellaris Launchpad I have had for
sometime. This is a program to be loaded onto the Launchpad over the
debug USB port using the on board debugger chip. The Mecrisp
instructions are shown here...

;------------------------------------------------------------------------------
Hardware and configuration for LM4F120 and TM4C123:
;------------------------------------------------------------------------------
Connect your cable to the Debug-USB-Port,
set "PWR SELECT" switch to DEBUG and
close VDD jumper.

Flashing is possible with lm4flash:
https://github.com/utzig/lm4tools

On startup, this runs with internal PIOSC at 16 MHz,
which is specified +-3% over whole temperature range.

I can figure out the switch part and I found the debug port. But I am
stumped with the lm4flash tool. I managed to download the directory
from github, but I don't see an executable, only sources. Clearly I am
expected to be able to compile C code on the PC, but it has likely been
a decade since I've done that. I don't even have a C compiler on this
machine.

I guess the idea is that anyone wanting to use this flashing tool would
be doing C development and so would be familiar with how to compile the
sources. I really don't want to have to figure out where to get C tools
for the PC and how to get them running. Heck, it might be easier in the
long run to transcribe the program into Forth and run it that way. 800
line of source counting white space, but few comments... oh, the code
uses libusb-1.0 for USB. I don't know how to deal with that. Crap...

--

Rick

[sbat...@gmail.com]

Should be very easy to take care of, unless you are hoping to do this on Windows.
Assuming you are on Linux and depending which distro you use, either apt-get or yum install libusb-dev and type make from the lm4flash directory off of the github. That should pretty much be all!

[sbat...@gmail.com]

OK I gave it a quick try on my Ubuntu vm out of curiosity. I already had the libusb-dev package installed, but the makefile is actually set up to depend on the 1.0 specific version of that package. Turns out that's fixed by just doing "sudo apt-get install libusb-1.0-0-dev" which took just a few seconds to do, then typing "make" worked out of the box with the makefile from that repository. Hope that helps!
I highly doubt it would work under Windows but I imagine you can use another flasher utility (with an exe out of the box) in place of lm4flash in that case.

Steve

[sbat...@gmail.com]

Last reply to this thread.. if you're on Windows it looks like TI provides what you need here: http://www.ti.com/tool/LMFLASHPROGRAMMER

I'd be more than willing to bet it can accomplish the same task, though it's TI proprietary rather than open source for Linux. Whoever wrote up the instructions for that Mecrisp just probably hasn't tried it out or thought about .

[rickman]

Yes, I'm on windows and have downloaded the TI tool, but not yet tried
to use it. I would like to run this on a raspberry pi as it is much
smaller and suits my lab use better in some respects. I will try
installing lm4flash the way you describe.

There is a bit of irony in that to use a Forth tool I need to understand
how to compile a C program. lol I am rather weary of learning all the
ins and outs of complex tool, never knowing for sure what they are doing
or if I am using them correctly. That's the main motivator for using
Forth on this target. I'm trying to implement a rather simple function
and would like to have a simple tool. Even once I get this installed on
the host machine and I get Mecrisp installed on the target, I will still
need to learn the details of using Mecrisp. At least then I am learning
something I expect to use many times in the future. I plan to help with
the documentation of Mecrisp. I think that is the big weakness of most
open source tools, rather limited docs.

--

Rick

[rickman]

> smaller and in some respects suits my lab use better than a PC. I will try

> installing lm4flash the way you describe.
>
> There is a bit of irony in that to use a Forth tool I need to understand
> how to compile a C program. lol I am rather weary of learning all the
> ins and outs of complex tool, never knowing for sure what they are doing
> or if I am using them correctly. That's the main motivator for using
> Forth on this target. I'm trying to implement a rather simple function
> and would like to have a simple tool. Even once I get this installed on
> the host machine and I get Mecrisp installed on the target, I will still
> need to learn the details of using Mecrisp. At least then I am learning
> something I expect to use many times in the future. I plan to help with
> the documentation of Mecrisp. I think that is the big weakness of most
> open source tools, rather limited docs.

Oh, I forgot to say thanks. Thanks :)

--

Rick

[sbat...@gmail.com]

>
> Oh, I forgot to say thanks. Thanks :)
>
> --
>
> Rick

Sure thing!

That's how open source software tends to be a lot of the time, it is built for Linux or similar, and comes with a makefile, maybe a configure script, and not a lot of documentation. If you're on Linux, the C compiler is already there 99% of the time (Raspberry Pi should have a compiler on board as well) so as long as you have the library sources you need you can usually get away with just typing "make" and when you get an error, somebody on one of the Linux forums or stackoverflow has probably asked about it already.

[rickman]

Yeah, the rPi was an afterthought. I get tired of lugging my laptop
around and there really isn't a lot of space on the work bench. Trouble
with the pi is that it is far too slow for useful for web browsing.
When I have a problem I still have to go back to the laptop to research
it and possibly download something that then has to be transferred to
the pi by sneaker net. I guess in theory they could be networked. I
had that working on my old Win2K PCs some years back, thanks to World of
Windows Networking (which appears to have been sold and is no longer
very useful). But with Vista and now Win8 I can't get any of my PCs to
talk to each other.

Compared to the average person I am very computer literate, but when it
comes to dealing with Microsoft, I just can't keep up with them breaking
everything all the time.

--

Rick

[rickman]

I took the 5 minutes to do this today... well, more like 15 with me stumbling around Linux on the rPi. I did manage to get lm4flash to compile, but I can't seem to figure out how to run it. I type lm4flash at the command line, but it says "command not found". The file has no visible extension. Is that expected? What am I missing?

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> compile, but I can't seem to figure out how to run it. I type
> lm4flash at the command line, but it says "command not found". The
> file has no visible extension. Is that expected? What am I missing?

Try ./lm4flash

[lasselangwad...@gmail.com]

generally executables don't have an extension on linux/unix

by default the current directory is not the path, so you have to type
./lm4flash to run it

-Lasse

[rickman]

Yes, I figured that out. It seems the current working directory is not
considered under Linux for finding executables... really!?

I got things working to the point that I could run the program with the
binary file and used the -v and -E options. I get an error message
saying "Unable to find any ICDI devices".

I am having to share the USB port between the launchpad and the mouse.
I can't think that is the problem though. I set up the command, unplug
the mouse, plug in the launchpad, give it a few seconds and hit return
to run the programmer. I'm using the debug port on the launchpad, the
switch is set to debug (otherwise it wouldn't have power). The RGB LED
will cycle the colors, but as soon as I hit any key on the keyboard it
turns Green and after a pause resumes the color cycle. I find that odd
since the keyboard is on the rPi on the other port. I can't imagine the
power on the USB port is not sufficient to power this dongle.

I have a powered hub on order, but it won't be here for a week or two.
I'm hoping this is not the problem.

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Yes, I figured that out. It seems the current working directory is
> not considered under Linux for finding executables... really!?

Yes, it's so that if you type something like "ls" in a directory, you
get the normal system ls instead of a possibly malicious one that was
sitting in the directory. I guess this was more of an issue in the
timesharing era.

[rickman]

I think that is the problem. I found mention of a program, lsusb, which
lists the USB devices. 1st time the launchpad didn't show up, 2nd time
it did, 3rd time it didn't.

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. This time when I ran the lm4flash command it
seemed to work. Maybe on the higher current side the meter was dropping
enough voltage that it was less than marginal. Now at least it has a
shot at working and clearly I need a powered hub for anything on the rPi
USB ports. Seems they did a poor job on power distribution on the
original design. The rPi 2 model B is supposed to be better. It can
also be used for real PC work... like web browsing.

Now I have to figure out how to get a terminal emulator working on the
rPi. Can't be too hard... I just have to research it on my laptop
rather than on the rPi.

--

Rick

[Paul Rubin]

rickman <gnu...@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.

[Albert van der Horst]

In article <mgpv33$469$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnu...@gmail.com> writes:
>>> compile, but I can't seem to figure out how to run it. I type
>>> lm4flash at the command line, but it says "command not found". The
>>> file has no visible extension. Is that expected? What am I missing?
>>
>> Try ./lm4flash
>
>Yes, I figured that out. It seems the current working directory is not
>considered under Linux for finding executables... really!?

Not correct. The PATH for finding executables is fully under control.
It is urban legend that there is a security leak by having de current
directory in the PATH. ("someone could have sneaked an ls in your directory
that installs a rootkit.") This is nonsensical for normal users.
So blame the idiots that have nothing better to do than this, not linux, and
put the line
PATH=".:$PATH"
in your profile.
If you're still a bit worried, you could do
PATH="$PATH:."
and refrain from doing it for the root user (assuming
you've ditched sudo).

This should be in the Unix FAQ.

<SNIP>
>
>--
>
>Rick
--
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

[Dimiter_Popoff]

On 17.4.2015 г. 13:52, Albert van der Horst wrote:
> In article <mgpv33$469$1...@dont-email.me>, rickman <gnu...@gmail.com> wrote:
>> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>>> rickman <gnu...@gmail.com> writes:
>>>> compile, but I can't seem to figure out how to run it. I type
>>>> lm4flash at the command line, but it says "command not found". The
>>>> file has no visible extension. Is that expected? What am I missing?
>>>
>>> Try ./lm4flash
>>
>> Yes, I figured that out. It seems the current working directory is not
>> considered under Linux for finding executables... really!?
>
> Not correct. The PATH for finding executables is fully under control.
> It is urban legend that there is a security leak by having de current
> directory in the PATH. ("someone could have sneaked an ls in your directory
> that installs a rootkit.") This is nonsensical for normal users.
> So blame the idiots that have nothing better to do than this, not linux, and
> put the line
> PATH=".:$PATH"
> in your profile.

I think what Rick was saying is that the current directory is not
searched for executables in unix, not that it cannot be made to be
searched.
Even I know it can be made (and once I knew how....), and I am not
a unix user much more than a windows one (i.e. I can use either as
a computerized TV set but not much beyond that).

Dimiter

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

[Mel Wilson]

If you must have this, you can get it with a command like (the bash
version here)

PATH+=:.

which makes the current directory, whatever it is or will be, the last
directory searched for commands. I never do this. I like the
predictability. "./" is always available.

[Blajrs Jrolrsen]

On 2015-04-17, rickman <gnu...@gmail.com> wrote:
> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnu...@gmail.com> writes:
>>> compile, but I can't seem to figure out how to run it. I type
>>> lm4flash at the command line, but it says "command not found". The
>>> file has no visible extension. Is that expected? What am I missing?
>>
>> Try ./lm4flash
>
> Yes, I figured that out. It seems the current working directory is not
> considered under Linux for finding executables... really!?

Why would it be? Most of the directories where binaries are stored are
called bin or sbin. For example

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin

It is really not appropriate or orderly to have binaries in your home
directory. The home directory is the top level directory for each user. It
is expected to contain other directories in an organized manner. If you want
to make a directory for binaries the normal way to do that is

mkdir ~/bin # one time only
export PATH=$PATH:~/bin # this goes in your logon proc depending on shell

Blajrs

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> Not correct. The PATH for finding executables is fully under control.
> It is urban legend that there is a security leak by having de current
> directory in the PATH. ("someone could have sneaked an ls in your directory
> that installs a rootkit.")

No it wasn't an urban legend, it was a real issue. In the old days "."
was the first thing on the path and there were actual incidents of what
you described. E.g. you'd be a sysadmin of some university timesharing
system, you'd get told that some student had porn in his home directory,
you'd cd to the directory and type "ls" as root, and hilarity ensues. I
think there is a paper by Fred Grampp about this, that introduced the
practice of getting "." off of the standard path.

> This is nonsensical for normal users.

I'd say it's still not nonsensical: you unpack an archive, cd to it and
type "ls", same situation. Or even in non-malicious cases, someone
might have chosen a program name that wasn't a standard Unix command,
but that happened to match something that you used and was on your path.
Like I think there are at least 2 different Forth implementations called
pforth. So maybe you use one of them and the directory you cd to has
the other one, so you type "pforth" and get the wrong one, etc.

[Anton Ertl]

Blajrs Jrolrsen <boe...@no.com> writes:
>On 2015-04-17, rickman <gnu...@gmail.com> wrote:
>> Yes, I figured that out. It seems the current working directory is not
>> considered under Linux for finding executables... really!?

...

>It is really not appropriate or orderly to have binaries in your home
>directory. The home directory is the top level directory for each user. It
>is expected to contain other directories in an organized manner. If you want
>to make a directory for binaries the normal way to do that is

The home directory was not the issue here, the current working
directory was.

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). They don't benefit from "." in the PATH at all,
so it was removed from the default. Programmers know how to add it
back.

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.

That had a security disadvantage: If an attacker can get you to unpack
a package, and that package contains, say, an executable "ls", then,
if you are in the directory containing that executable and try to list
the files, you will execute the attacker's executable.

That disadvantage was worked around by removing the "." from the front
and putting it on the back of the PATH. This allows programmers to
call their programs in the current directory without "./", unless a
version of that program has been installed in another directory in the
PATH. I guess that, if you have that, you may start to use "./" a
lot, so then you can eliminate "." from the PATH completely.

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

[David Brown]

And while it is true that when running under a standard user, you cannot
easily install a rootkit (the malicious program would have to persuade
you to do a "sudo" or similar), you can make a real mess without that.

Albert, try putting this in a file called "ls", with the executable flag
set:

#!/bin/bash
rm -rf ~/

[glen herrmannsfeldt]

In comp.arch.embedded Paul Rubin <no.e...@nospam.invalid> wrote:
> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> Not correct. The PATH for finding executables is fully under control.
>> It is urban legend that there is a security leak by having de current
>> directory in the PATH. ("someone could have sneaked an ls in your directory
>> that installs a rootkit.")

> No it wasn't an urban legend, it was a real issue. In the old days "."
> was the first thing on the path and there were actual incidents of what
> you described. E.g. you'd be a sysadmin of some university timesharing
> system, you'd get told that some student had porn in his home directory,
> you'd cd to the directory and type "ls" as root, and hilarity ensues. I
> think there is a paper by Fred Grampp about this, that introduced the
> practice of getting "." off of the standard path.

OK, so at least you should put the . at the end of the path.
That will still surprise you if you name your program the same
as a system program, though.

>> This is nonsensical for normal users.

> I'd say it's still not nonsensical: you unpack an archive, cd to it and
> type "ls", same situation. Or even in non-malicious cases, someone
> might have chosen a program name that wasn't a standard Unix command,
> but that happened to match something that you used and was on your path.
> Like I think there are at least 2 different Forth implementations called
> pforth. So maybe you use one of them and the directory you cd to has
> the other one, so you type "pforth" and get the wrong one, etc.

By now, I have gotten used to putting ./ in front of names.
Especially interesting is:

./!$

for ordinary users on systems with no public users, and who don't
download files without looking at the names, . at the end should
be safe enough. For root, it probably isn't safe enough.

As far as I know, MSDOS and its successor, Windows, have an
implied . at the beginning of the path.

-- glen

[rickman]

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.

--

Rick

[rickman]

Do you not understand what I was doing? I was working on compiling an
executable to see if it worked. Before I went to the bother of (if I
was ever going to) copying the exe to one of the bin directories, I
wanted to test it. I likely won't move it to a bin directory because it
is likely not more than a one time use thing.

--

Rick

[rickman]

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.

--

Rick

[Albert van der Horst]

In article <mgr288$4dr$1...@speranza.aioe.org>,

Blajrs Jrolrsen <boe...@no.com> wrote:
>On 2015-04-17, rickman <gnu...@gmail.com> wrote:
>> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>>> rickman <gnu...@gmail.com> writes:
>>>> compile, but I can't seem to figure out how to run it. I type
>>>> lm4flash at the command line, but it says "command not found". The
>>>> file has no visible extension. Is that expected? What am I missing?
>>>
>>> Try ./lm4flash
>>
>> Yes, I figured that out. It seems the current working directory is not
>> considered under Linux for finding executables... really!?
>
>Why would it be? Most of the directories where binaries are stored are
>called bin or sbin. For example
>
>/bin
>/sbin
>/usr/bin
>/usr/sbin
>/usr/local/bin
>/usr/local/sbin
>
>It is really not appropriate or orderly to have binaries in your home
>directory. The home directory is the top level directory for each user. It
>is expected to contain other directories in an organized manner. If you want
>to make a directory for binaries the normal way to do that is

I never work in my home directory, always in PROJECT/<whatever> or $HOME/euler
or sometimes in /tmp.
But I do make programs there that I want to run, all the time, up to a hundred
times a day, easily.
Need a test version of lina with a cramped 2M dictionary space?
"
lina64 -i linaG forth.lab \ install copy in current dir
linaG -g -7998 lina \ "grow by" minus 7998 Megabyte.
rm linaG

"

>
>mkdir ~/bin # one time only
>export PATH=$PATH:~/bin # this goes in your logon proc depending on shell

That is indispensable for all kind of utilities.

Groetjes Albert



>
>Blajrs

[mm0fmf]

When in doubt check the spec... USB2.0 ports are 5v +/- 5% so 4.75V to
5.25V between the pins on the connector.

4.95 is almost perfectly in the middle.

[Martin Gregorie]

On Fri, 17 Apr 2015 15:12:13 -0400, rickman wrote:

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

This has been rewrapped by Pan because it needed to add "> " at the
beginning of each line, but as received, your appended text was wrapped
at between 71 and 74 characters. I think it wraps whenever the next word
would make the line longer that 74 chars, which is a bit odd seeing that
you set the limit at 72. The last word at the end of each line in the
para were:

that
Anyone
you
at
now.


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

[rickman]

Thanks. The 72 columns was just my recollection. I can't find the
setting now.

--

Rick

[rickman]

I never said that measurement was out of spec. I was commenting on the
facts that there is a quarter volt lost across the rPi and that the
launchpad seems to reset when I type on the USB keyboard. Maybe it's
not voltage related, but the quarter volt drop is unexpected and there
are plenty of cases where even an older mouse, like the one I have,
can't be powered through the rPi.

--

Rick

[Hans-Bernhard Bröker]

Am 17.04.2015 um 16:42 schrieb Anton Ertl:
> Blajrs Jrolrsen <boe...@no.com> writes:
>> On 2015-04-17, rickman <gnu...@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.

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

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> 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.

Linux has its roots in Unix which goes back to the 1970's, long before
the existence of PC's, so it tends to use old-school approaches:

http://2ndscale.com/rtomayko/2006/that-dilbert-cartoon

[rickman]

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.

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?

--

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> 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?

Do "ls /dev/tty*" and it should give you a list of possible devices
where the port is.

Do you use irc? You can probably get quicker help on the #raspberrypi
Freenode channel.

[rickman]

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. But then it has it's own table,
burns enough power to warm a cat very nicely while the rPi serves as a
night light and sits on top of my monitor... lol

--

Rick

[Paul Rubin]

rickman <gnu...@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

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.

[rickman]

On 4/17/2015 8:24 PM, Paul Rubin wrote:
> rickman <gnu...@gmail.com> writes:
>> 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?
>
> Do "ls /dev/tty*" and it should give you a list of possible devices
> where the port is.

That gives me a list of tty, tty0 through tty63, ttyAMA0 and ttyprintk.
The list is the same if the device is plugged in or not. Of course, I
don't know for sure what the board should do, but my understanding is
one port is for use as a debugger and this port is for use as a UART
interface to the target MCU. I had found a web page where they were
developing on this target under Linux. I'll go back to that to look for
info. But I think it was more debugger oriented.

Trouble is most of these pages are from experienced users and they have
long ago forgotten all the small stumbling blocks to getting started.

> Do you use irc? You can probably get quicker help on the #raspberrypi
> Freenode channel.

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.

One of my problems is there really isn't room for the pi, the laptop and
all the other misc stuff on my work table at the moment. Maybe I need
to just work remotely from the laptop. That would solve my lack of a
USB hub as well. I have to unplug the mouse to plug in the launchpad.

--

Rick

[rickman]

My problem isn't the size of the laptop exactly. It is the smallness of
the space available, lol. I can't use such small machines really. In
fact one of my complaints of this 17" laptop is they didn't use all the
space available for the keyboard so there is no space between the key
sections. It is impossible to feel for any keys like the arrows or the
Home, End, PgUp, PgDn keys. You have to look every time you reach for
one. Then the rPi is tiny, but the 19" monitor is not and the compact
Dell keyboard is wider than the 17" laptop, along with all the tools,
drawers, lamps, outlet strips and misc junk on the relatively small
table top. If I put the laptop where the keyboard is I have to lay the
keyboard behind it... I could bring another table in just for the
laptop. Or I could admit I am never going to fire up the XP computer
again and use that tray.

But for the short term, I'm just looking for a way to talk to the
launchpad from the rPi.

--

Rick

[Paul Rubin]

rickman <gnu...@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.

[Mel Wilson]

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.

[Robert Wessel]

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.

[rickman]

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

[David Brown]

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.

[David Brown]

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

[David Brown]

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 :-)

[David Brown]

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.

[Jan Coombs <Jan-54 >]

On Fri, 17 Apr 2015 20:20:30 -0400

rickman <gnu...@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

[Albert van der Horst]

In article <87oammu...@jester.gateway.pace.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>rickman <gnu...@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

[Anton Ertl]

=?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBr...@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/

[David Brown]

On 18/04/15 11:15, Anton Ertl wrote:
> =?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBr...@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.).

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

[Hans-Bernhard Bröker]

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.

[Dimiter_Popoff]

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/

[Anton Ertl]

David Brown <david...@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.

[rickman]

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

[rickman]

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

[rickman]

On 4/18/2015 4:38 AM, Jan Coombs <Jan-54 wrote:
> On Fri, 17 Apr 2015 20:20:30 -0400
> rickman <gnu...@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

[Martin Gregorie]

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 |

[rickman]

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

[rickman]

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

[rickman]

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

[David Brown]

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.

[Albert van der Horst]

In article <mgtsk2$v6j$1...@dont-email.me>, rickman <gnu...@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

[David Brown]

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

[David Brown]

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

[mm0fmf]

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

[Niklas Holsti]

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

[Paul Rubin]

David Brown <david...@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.

[Alan Adams]

In message <mgtmbd$582$1...@dont-email.me>

rickman <gnu...@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 <gnu...@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
al...@adamshome.org.uk
http://www.nckc.org.uk/

[David Brown]

On 18/04/15 14:16, Dimiter_Popoff wrote:
> 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.

That is - at best - an extraordinary exaggeration. The number of people
who choose Linux /because/ they don't want to do the same as most people
(use Windows) is tiny.

There is the argument that one of the many reasons why Linux is (in
general) more secure than Windows is that there are fewer users of
Linux, but even that is a minor issue.

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

The kernel and base system are all Linux. The gui and many higher-level
features are Android specific.

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

It's the gui and user interface that causes this, and that is
Android-specific. Much of it is written in Java, and runs on a JVM.

[David Brown]

On 18/04/15 15:08, Anton Ertl wrote:
> David Brown <david...@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.

Yes, but nano is provides an essential function - a simple command-line
editor. And it takes about 100 KB - as compared to eclipse at about 100
MB or so. Eclipse is useful to many programmers (I use it myself), and
equally it is despised by many programmers. But the cost (in terms of
disk space, network download, etc.) is significant for those that don't
need it - unlike the cost of nano.

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

Some distros still have it (or are by their nature a "typical desktop"
or "typical server", such as Linux Mint or Centos).

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

Just a point here - if my post was an "ad-hominem attack" (which I don't
think it was, and it was not intended to be), then so was your
characterisation of /opt users as "lazy" and "nonsense". So let us move
past that.

In the beginning of unix, /usr was the place for site-specific or
user-chosen software. Gradually, due to the way disks and filesystems
were often mounted, more and more of the standard or base files ended up
in /usr. People put their own software in /usr/local. Then people
started looking for a place to put software that would not interfere
with system software (i.e., distro-provided software for Linux, in /usr)
or software chosen, compiled and installed by users (in /usr/local).
/opt became common as a distro-independant place to put things.

So on my systems, I have software from the likes of Atmel and Freescale
in /opt. This is software that came pre-compiled, and could have
paid-for licences. The tools are not on my path - nor should they be,
as the compilers are specified explicitly in Makefiles as needed. If I
want a short-cut for starting an IDE, I put a symbolic link in ~/bin (or
sometimes a bash wrapper).

Is it a perfect system? No, there is no such thing. But it works
simply, easily and conveniently, and makes it very simple for me to
distinguish between distro software and third-party software, and makes
it simple for upgrading or moving to a new system.

[Simon Clubley]

On 2015-04-17, Mel Wilson <mwi...@the-wire.com> 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? 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.

To expand on that:

There's a standard for accessing serial ports on the USB specifications
which is the CDC ACM specification. This is fully open and documented
and many implementations exist (I did a simple version myself as a
learning exercise a few years ago).

However, as you say, it's targetted towards modems in it's model of
operation although serial ports work just fine with it. However, the
hardware flow control signals don't get directly passed through to
the host (there's no direct handling of CTS for example).

The way people like Microchip appear to handle this (in devices like
the MCP2200) is to handle the flow control on the device itself.

FTDI (and Prolific (PL-2303)) have their own closed USB protocol
specifications for their own devices. These specifications are not
available without signing an NDA (I know; in the case of FTDI I actually
asked them about this).

There are however drivers for these manufacturers in the Linux kernel
and (as you have discovered) they show up in a different way to the
standards compliant CDC ACM devices.

As for how Linux knows the difference, the different types of USB serial
ports are encoded differently in the configuration descriptors on the
device (with the CDC ACM devices using configuration values assigned
by the USB standards).

Simon.

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

[lasselangwad...@gmail.com]

Den fredag den 17. april 2015 kl. 20.47.55 UTC+2 skrev rickman:
> On 4/17/2015 12:56 AM, Paul Rubin wrote:
> > rickman <gnu...@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.
>

> --
>
> Rick

yep, that is what I read too, they didn't consider that running a polyfuse
at it's rated current would be a problem

I'd just short it

-Lasse

[Stephen Pelc]

On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnu...@gmail.com> wrote:

>Seems they did a poor job on power distribution on the
>original design. The rPi 2 model B is supposed to be better. It can
>also be used for real PC work... like web browsing.

The B2 is significantly faster than the B+, even for single core
apps. We are using Raspbian.

>Now I have to figure out how to get a terminal emulator working on the
>rPi. Can't be too hard... I just have to research it on my laptop
>rather than on the rPi.

The "standard" Linux terminal program is minicom.

You will get far less noise in responses if you post the Linux
questions on a Raspberry Pi group. RPi respondes seem to be much
nicer than the average Lunux person. Similarly, I get much better
Google responses when Raspberry Pi is included in the search request.

Stephen


--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Dimiter_Popoff]

On 18.4.2015 г. 20:57, David Brown wrote:
> On 18/04/15 14:16, Dimiter_Popoff wrote:
>> 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.
>
> That is - at best - an extraordinary exaggeration. The number of people
> who choose Linux /because/ they don't want to do the same as most people
> (use Windows) is tiny.
>
> There is the argument that one of the many reasons why Linux is (in
> general) more secure than Windows is that there are fewer users of
> Linux, but even that is a minor issue.

I was being general, I did not mean people chose linux just in order
to be different. I said only "doing something because other people
do it is no better than not doing it for this reason", no unix
etc. implied - though I can see how in this context it may have
come across this way (which was neither intended nor meant).

>>
>> 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?
>
> The kernel and base system are all Linux. The gui and many higher-level
> features are Android specific.
>
>> 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.
>>
>
> It's the gui and user interface that causes this, and that is
> Android-specific. Much of it is written in Java, and runs on a JVM.
>

This must be it, the sync issues I see are mainly between user
clicks (taps)and what is tapped on - at times many seconds apart,
you tap and tap on a link and after half a minute may be the browser
hears your tapping and takes you to some other link you did not even
suspect was there let alone tap on it. What a mess, if I try to sell
something 1/10th that messy I'll never get away with it.

[Hal Murray]

In article <mgtro8$reh$1...@dont-email.me>,

rickman <gnu...@gmail.com> writes:

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

What I do for things like that is keep a small text file
with all the details I need. Often it's a command line
that I can cut-paste when setting up a copy of the system.
(or putting the system back together)

You don't need the whole story, just enough to trigger your memory,
or contain the magic phrase that will let man or google find it for you.
If google finds multiple pages, I often save the URL with the one
that had the answer I liked best.


--
These are my opinions. I hate spam.

[Rod Pemberton]

On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnu...@gmail.com> wrote:
> On 4/18/2015 4:00 AM, David Brown wrote:

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

That guy may be a nut, but he's *correct* about your lines.

Your lines aren't wrapped correctly for Usenet. This is not a Google
Group.

Your lines should hard wrap with a newline, i.e., ASCII CR LF per spec.,
at 72 characters or so. Either your Usenet reader has a setting to do
this, or you must manually hit return before 72 characters. I.e., on
my browser, I had to enter newlines above or it would be one single line.

In this thread, Usenet text wrapping for posts by "rickman" and by
"David Brown" are incorrect.


Rod Pemberton

--
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[The Natural Philosopher]

On 18/04/15 23:55, Rod Pemberton wrote:
> On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnu...@gmail.com> wrote:
>> On 4/18/2015 4:00 AM, David Brown wrote:
>
>>> 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.
>
> That guy may be a nut, but he's *correct* about your lines.
>
> Your lines aren't wrapped correctly for Usenet. This is not a Google
> Group.
>
> Your lines should hard wrap with a newline, i.e., ASCII CR LF per spec.,
> at 72 characters or so. Either your Usenet reader has a setting to do
> this, or you must manually hit return before 72 characters. I.e., on
> my browser, I had to enter newlines above or it would be one single line.
>
> In this thread, Usenet text wrapping for posts by "rickman" and by
> "David Brown" are incorrect.
>

Thunderbird has a 'rewrap text' option that does this.


>
> Rod Pemberton
>


--
Everything you read in newspapers is absolutely true, except for the
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[Dimiter_Popoff]

On 19.4.2015 г. 01:55, Rod Pemberton wrote:
> On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnu...@gmail.com> wrote:
>> On 4/18/2015 4:00 AM, David Brown wrote:
>
>>> 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.
>
> That guy may be a nut, but he's *correct* about your lines.
>
> Your lines aren't wrapped correctly for Usenet.

Don't know about nutcase but his lines here seem quite correct to me.
I checked a few messages at a glance and examined in detail one (I think
it was his second one).
His lines are well within 72 characters. The quoted lines are left
alone; some of them are much longer than they should be but this
has been the fault of *their* poster, not Ricks. If someone has
the expectation people will edit the line length of everything
they quote.... well, this is unrealistic to say the least.

Dimiter

[David Brown]

On 18/04/15 22:11, Dimiter_Popoff wrote:
>
> This must be it, the sync issues I see are mainly between user
> clicks (taps)and what is tapped on - at times many seconds apart,
> you tap and tap on a link and after half a minute may be the browser
> hears your tapping and takes you to some other link you did not even
> suspect was there let alone tap on it. What a mess, if I try to sell
> something 1/10th that messy I'll never get away with it.
>

I think this is entirely up to the app. Input events get put in a
queue, normally handled by the main thread (as is common on most gui
systems AFAIK). If the app keeps the main thread too busy to see the
events for a while, you get delays.

[Dimiter_Popoff]

It may be down to some app but it applies to all apps (i.e. there is
no scenario where if one browser window gets stuck you can switch
and talk to some other task, everything stays stuck for a very long
time). Then if an app is allowed to block the system task doing user
I/O this is a very poorly organized system (which it is, it becomes
obvious immediately when one touches it - but it is good to have it
in ones pocket nonetheless, better than nothing anyway).

[David Brown]

Other than that, the only difference I see between the lines in my and
Rick's posts, and Rod's posts, is that Thunderbird has spaces at the end
of the lines, while Rod's do not. (Nor do yourrs, Dimiter.) I suspect
that Thunderbird uses these spaces to identify wrapped paragraphs, which
it can then re-wrap to the window width for display in Thunderbird (but
not for posting).

It could also be that there is a difference in the line ending
characters, but it would surprise me if a Usenet client is fussy about
the line endings it accepts.

[rickman]

On 4/18/2015 12:21 PM, Niklas Holsti wrote:
> 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.

Thanks, that will make me happier.

--

Rick

[rickman]

On 4/18/2015 12:06 PM, mm0fmf wrote:
> 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.

You are confused. The only reason why the output voltage is in spec is
because the input voltage is well above the nominal voltage required on
the input. With another power module the output voltage would be
outside of spec and even now, the output is not able to supply much
current. Connect a device that draws more current and the voltage sags
more.

This is not so much about the USB spec as it is the design of the rPi
which creates a lot of voltage drop on what should be very nearly a wire
with nominal resistance.

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

Such a switch would typically have a resistance of low mOhms and create
a correspondingly low voltage drop... much less than the 0.25 volts we
are seeing in the rPi.

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

Bingo.

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

The rPi does not have switches in the power path I believe. But if it
does, they should be designed for a much lower voltage drop than a
quarter volt, hence the problem.

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

I find your description of the rPi to be interesting. Battery powered
is a bit tongue in cheek as this level device is on par with phones and
tablets which can't be away from a power plug for hours rather than
days. I think of "battery powered" as describing equipment that can be
left unattended for many days without an external power source. But
whatever, one man's battery is another man's RTG. lol

Enjoy

--

Rick

[rickman]

On 4/18/2015 3:22 PM, Stephen Pelc wrote:
> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnu...@gmail.com> wrote:
>
>> Seems they did a poor job on power distribution on the
>> original design. The rPi 2 model B is supposed to be better. It can
>> also be used for real PC work... like web browsing.
>
> The B2 is significantly faster than the B+, even for single core
> apps. We are using Raspbian.
>
>> Now I have to figure out how to get a terminal emulator working on the
>> rPi. Can't be too hard... I just have to research it on my laptop
>> rather than on the rPi.
>
> The "standard" Linux terminal program is minicom.
>
> You will get far less noise in responses if you post the Linux
> questions on a Raspberry Pi group. RPi respondes seem to be much
> nicer than the average Lunux person. Similarly, I get much better
> Google responses when Raspberry Pi is included in the search request.

Thanks. I've been trying to get minicom installed and have not figured
it out. I have crossposted to the rpi group, but some folks don't
crosspost their replies which is ok with me. So I am discussing this
there as well.

--

Rick

[rickman]

On 4/18/2015 11:52 AM, Albert van der Horst wrote:
> In article <mgtsk2$v6j$1...@dont-email.me>, rickman <gnu...@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.

That's one of the things I like about Mecrisp, it is on two families,
MSP430 and ARM CMx and lots of boards supported. I'll keep note of
noforth.

--

Rick

[rickman]

On 4/18/2015 12:42 PM, Paul Rubin wrote:
> David Brown <david...@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.

The rPi is not my target processor, a TI Stellaris Launchpad is. I want
to use the rPi as my development system.

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

Is it really? I mean, is it doing more *useful* stuff? I think most
web sites are loaded with glitz and crap and for the semiconductor
makers the sites are just noise. For example TI used to have an
excellent site, clearly organized with a lot of input from the
engineering staff or customers. Now it is full of glitz and advertising
so that it is hard to find what you want in a way that makes it all easy
and clear. The result is pages that run slowly and are hard to even
scroll.

--

Rick

[Alan Adams]

In message <mh14qa$u9a$1...@dont-email.me>

rickman <gnu...@gmail.com> wrote:

> On 4/18/2015 12:06 PM, mm0fmf wrote:
>> 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.

> You are confused. The only reason why the output voltage is in spec is
> because the input voltage is well above the nominal voltage required on
> the input. With another power module the output voltage would be
> outside of spec and even now, the output is not able to supply much
> current. Connect a device that draws more current and the voltage sags
> more.

> This is not so much about the USB spec as it is the design of the rPi
> which creates a lot of voltage drop on what should be very nearly a wire
> with nominal resistance.

and to make it worse, and fluctuations in the current drawn will
produce fluctuations in the voltage. Checking with an oscilloscope is
the only realistic way to see whether this is affecting the problem.

[Tauno Voipio]

screen is much better for direct connection. It is a bit of a
challenge to make Minicom not use any modem controls or dialing
sequences.

--

-TV

[Anton Ertl]

David Brown <david...@hesbynett.no> writes:
>On 18/04/15 15:08, Anton Ertl wrote:
>> David Brown <david...@hesbynett.no> writes:
>> So what? The distro also installs stuff like nano and an inetd that
>> most people don't use.
>
>Yes, but nano is provides an essential function - a simple command-line
>editor. And it takes about 100 KB - as compared to eclipse at about 100
>MB or so. Eclipse is useful to many programmers (I use it myself), and
>equally it is despised by many programmers. But the cost (in terms of
>disk space, network download, etc.) is significant for those that don't
>need it - unlike the cost of nano.

187KB, and it does not even have Emacs or vi key bindings. I wonder
what it is doing with all that space, but it's certainly nothing I
use.

Looking at the popularity-contest results, some form of vi seems to be
installed more often than nano (it seems that there are people who
uninstall nano), so Debian could install vi in the first place.

Anyway, not installing a programmer's editor and installing nano
instead supports my claim that they do not target programmers.

name inst vote old recent no-files (maintainer)
nano 170116 32133 119241 18640 102 (Jordi Mallach)
vim-common 174062 59805 87555 26616 86 (Debian Vim Mai
vim 67701 23297 36271 8105 28 (Debian Vim Mai
vim-tiny 169261 13839 120285 35040 97 (Debian Vim Mai
emacsen-common 54751 10282 37601 6821 47 (Rob Browning)
emacs23-bin-common 16067 5231 10516 312 8 (Rob Browning)
emacs23 13261 4400 8585 271 5 (Rob Browning)
emacs24-bin-common 6512 3233 2460 819 0 (Rob Browning)
emacs24 5696 2811 2135 750 0 (Rob Browning)
emacs24-common 6521 1526 3820 1166 9 (Rob Browning)
emacs23-common 16092 1392 14170 497 33 (Rob Browning)
eclipse-platform-data 7092 1840 3736 1511 5 (Debian Orbital
eclipse-rcp 7249 1700 4112 1429 8 (Debian Orbital
eclipse-platform 6962 1628 3914 1414 6 (Debian Orbital
eclipse-jdt 6903 1185 5290 369 59 (Debian Orbital
eclipse-pde 6859 1184 5292 368 15 (Debian Orbital

>> 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.
>
>Some distros still have it (or are by their nature a "typical desktop"
>or "typical server", such as Linux Mint or Centos).

Which one still has "typical development environment"?

>>>> 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.
>>
>
>Just a point here - if my post was an "ad-hominem attack" (which I don't
>think it was, and it was not intended to be), then so was your
>characterisation of /opt users as "lazy" and "nonsense". So let us move
>past that.

/opt users are victims of their software providers. Concerning the
characterization of the programmers, I stand by that; ok, it could
also be incompetence. If a programmer does not provide a "make
install" or at least an install script that installs the binaries or
links to the binaries in a directory that is in the usual path of
users (such as /usr/local/bin), but instead says in the README that
the sysadmin should create such links manually, or that the users
should put the /opt/.../bin directory in the PATH, no friendly
characterization comes to my mind.

>In the beginning of unix, /usr was the place for site-specific or
>user-chosen software. Gradually, due to the way disks and filesystems
>were often mounted, more and more of the standard or base files ended up
>in /usr. People put their own software in /usr/local. Then people
>started looking for a place to put software that would not interfere
>with system software (i.e., distro-provided software for Linux, in /usr)
>or software chosen, compiled and installed by users (in /usr/local).
>/opt became common as a distro-independant place to put things.
>
>So on my systems, I have software from the likes of Atmel and Freescale
>in /opt. This is software that came pre-compiled, and could have
>paid-for licences. The tools are not on my path - nor should they be,
>as the compilers are specified explicitly in Makefiles as needed. If I
>want a short-cut for starting an IDE, I put a symbolic link in ~/bin (or
>sometimes a bash wrapper).

So the example you gave of using "gforth" to call
"/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" would not even work
for your setup.

>Is it a perfect system? No, there is no such thing. But it works
>simply, easily and conveniently, and makes it very simple for me to
>distinguish between distro software and third-party software, and makes
>it simple for upgrading or moving to a new system.

I see no advantage over using /usr/local.

Upgrading: Get the new version of the software, do "make install".
Ideally the software installs itself with version numbers, so you can
also call old versions.

Moving to a new system: Just copy /usr/local to the new system (or
somesuch; you could also install the new system on a new partition,
and mount the /usr/local there).

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

[mm0fmf]

On 19/04/2015 21:57, rickman wrote:
>
> The rPi does not have switches in the power path I believe.

Dear rickman, having studied many of your posts I have come to the
conlusion that you don't read what people write and have significantly
less comprehension regarding hardware and software in reality than you
believe you have.

And so, given I have fewer tomorrows than yesterdays, I shall let you
stew in your own piss from now on rather than trying to help you.

*plink*

[rickman]

No need to have a pissing contest with anyone, but I don't actually
recall your posts attempting to be helpful. Rather you tried to tell me
the voltage on the USB ports were "in spec" when that was not the issue
being discussed.

plonk yourself, lol

--

Rick

[sbat...@gmail.com]

Rick, if you're using Debian or Ubuntu on the pi then you should be able to install minicom with apt-get install out of the box. Otherwise I think it can pretty easily be installed from source in exactly the same way as the lm4flash thing.. just grab the source off of sourceforge or github or wherever it's being hosted, type "make", and maybe "make install" if the Makefile has that option, and it will copy the executable and man files into the right path.

However if you're using the monitor/keyboard/mouse on the pi, then I might recommend gtkterm instead as it has a graphical menu with drop-downs and pop up boxes, where as minicom requires you to use a bunch of shortcut keys to tweak the settings.. once again apt-get install should do the job.
Similarly I like gedit as a text editor, it's a bit notepad-like but has syntax highlighting and some other helpful features. Not the most full-featured, but at least it doesn't make you do keyboard commands to navigate through different modes to get things done.

Getting the software tools you need on a Linux environment isn't all that bad, most of the time it's a matter of seeing if it's in the repositories, maybe adding a new repository to your sources list, or as a last resort downloading the source and installing. On something like Raspberry Pi the remaining issue is whether or not the software you want actually supports ARM, but with so many platforms being ARM based, I think that will continue to be less of an issue as time moves forward.

[rickman]

Thanks.

At this point I'm getting (or should I say *am still*) frustrated with
the Stellaris Launchpad. I tried using it on my win8 pc and the drivers
won't install. Seems there is much stiffer driver signature enforcement
in Win8 and Win7 so that you have to disable it and reboot. I'm not
sure even then that it will work.

I'm looking to see if using the STM32 would be easier. If I can't get
drivers installed under Windows, I can't imagine how I would get them to
work under Linux.

--

Rick

[Dimiter_Popoff]

Your experience seems to support my view that demo boards like that
are useless. You will design and bring to life your end product
board faster than you will make some demo toy being useful to you,
i.e. all the time you spend on the latter will be wasted.
Unless you want to make a product for sale (say, some piece of
software) to run on exactly that, popular board, targeting people
who already have it.

[rickman]

In this case the project is truly an evaluation, not of the device, but
of the project itself. So the goal is not to design a board, but to
demonstrate the functionality of the end product at the lowest possible
cost. The problem I'm having is not with the eval board, but with the
tools. TI didn't provide a decent driver for their Stellaris Launchpad.

--

Rick

[rickman]

Thanks for the advice. For now I am punting and working under Windows
just to get the project moving along. But that is no greased slide
either as the TI drivers for the launchpad won't install under Win 8
without some pain. So I've ordered a couple of STM Discovery board
which have an ST-link on board and hopefully will just work. While I
wait for delivery I will try installing the drivers and getting ready to
move ahead.

--

Rick

[Waldek Hebisch]

In comp.lang.forth rickman <gnu...@gmail.com> wrote:
>
> At this point I'm getting (or should I say *am still*) frustrated with
> the Stellaris Launchpad. I tried using it on my win8 pc and the drivers
> won't install. Seems there is much stiffer driver signature enforcement
> in Win8 and Win7 so that you have to disable it and reboot. I'm not
> sure even then that it will work.
>
> I'm looking to see if using the STM32 would be easier. If I can't get
> drivers installed under Windows, I can't imagine how I would get them to
> work under Linux.
>

Mistake. For demo boards most of the driver nonsense suffered
by Windows users is absent on Windows. Demo boards typically
have UART interface which is mostly standard and can be handled
by single generic driver. And on Linux it is handled in that
way: demo board and various USB-UARTS are automatically handled
by builtin Linux drives. Only Windows forces you to install
extra drivers.

For Stellaris/Tiva Launchpad main interface is special USB endpoint.
The lm4flash programs uses libusb to contact to this endpoint
and flash your program. Kernel has everything needed to talk
to USB bus, the rest is userland. So no driver installation.
Of course, you need to have libusb and need to compile lm4tools
package. Also, you need appropriate permissions. On my machine
I created /etc/udev/rules.d/46-ev-board.rules and put there
the followings lines:

# Stellaris Launchpad
SUBSYSTEM=="usb",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
KERNEL=="ttyACM*",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"

It is lousy securitywise because is gives access to demo board to
all users, but it works. Other folks posted similar setups.

In another post you wrote that you figured out main trouble, that
is that you need to use 'debug' USB port to connect to PC. 'device'
port is the one connected to Stellaris processor and is for use of
the program on demo board. The 'debug' port is debugging/programing
interface and also gives an USB-UART (the other end of UART is connected
to hardware UART on Stellaris processor). With that problem solved
Launchpad should work without problems. FYI, I connected several
Launchpads to several different Linux machines and things worked
fine from the starts. To be clear: Stellaris errata looks really
bad and for me beakpoints in gdb do not work. But lm4flash
has no problem finding the Launchpad and programming works fine.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[rickman]

On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
> In comp.lang.forth rickman <gnu...@gmail.com> wrote:
>>
>> At this point I'm getting (or should I say *am still*) frustrated with
>> the Stellaris Launchpad. I tried using it on my win8 pc and the drivers
>> won't install. Seems there is much stiffer driver signature enforcement
>> in Win8 and Win7 so that you have to disable it and reboot. I'm not
>> sure even then that it will work.
>>
>> I'm looking to see if using the STM32 would be easier. If I can't get
>> drivers installed under Windows, I can't imagine how I would get them to
>> work under Linux.
>>
>
> Mistake.

Not sure what this means.

> For demo boards most of the driver nonsense suffered
> by Windows users is absent on Windows. Demo boards typically
> have UART interface which is mostly standard and can be handled
> by single generic driver. And on Linux it is handled in that
> way: demo board and various USB-UARTS are automatically handled
> by builtin Linux drives. Only Windows forces you to install
> extra drivers.

Maybe you are right about the drivers, but I haven't been able to get a
terminal program installed and I'm a bit fed up messing with it. So
choose your poison. Go with an OS where the eval board maker can make
it easy to install their board if they want and everything else is there
waiting for me to use, or go with an OS where the board installs easily
and everything else is an uphill climb.

> For Stellaris/Tiva Launchpad main interface is special USB endpoint.
> The lm4flash programs uses libusb to contact to this endpoint
> and flash your program. Kernel has everything needed to talk
> to USB bus, the rest is userland. So no driver installation.
> Of course, you need to have libusb and need to compile lm4tools
> package. Also, you need appropriate permissions. On my machine
> I created /etc/udev/rules.d/46-ev-board.rules and put there
> the followings lines:
>
> # Stellaris Launchpad
> SUBSYSTEM=="usb",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
> KERNEL=="ttyACM*",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
>
> It is lousy securitywise because is gives access to demo board to
> all users, but it works. Other folks posted similar setups.
>
> In another post you wrote that you figured out main trouble, that
> is that you need to use 'debug' USB port to connect to PC. 'device'
> port is the one connected to Stellaris processor and is for use of
> the program on demo board. The 'debug' port is debugging/programing
> interface and also gives an USB-UART (the other end of UART is connected
> to hardware UART on Stellaris processor). With that problem solved
> Launchpad should work without problems. FYI, I connected several
> Launchpads to several different Linux machines and things worked
> fine from the starts. To be clear: Stellaris errata looks really
> bad and for me beakpoints in gdb do not work. But lm4flash
> has no problem finding the Launchpad and programming works fine.

I'm not using gdb, just a terminal interface to the Forth that should be
running on the target processor already.

At this point the rPi is off the workbench and in a box. I'd be happy
to pull it back out if I had any confidence it is more likely to work
than the drivers for the STMdiscovery boards I've ordered, or if it
would save me the time. I don't expect them to be here before Friday at
the earliest.

--

Rick