Mecrisp on the TI Stellaris Launchpad

Den torsdag den 16. april 2015 kl. 23.24.07 UTC+2 skrev rickman:
> On Monday, April 13, 2015 at 7:18:08 PM UTC-4, sbat...@gmail.com wrote:
> > On Thursday, April 2, 2015 at 6:08:24 PM UTC-7, rickman wrote:
> > > 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
> > 
> > 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!
> 
> 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?

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

On 4/16/2015 6:11 PM, Paul Rubin wrote:
> rickman <gnuarm@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!?

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

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

On 4/16/2015 11:37 PM, rickman wrote:
> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnuarm@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!?
>
> 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.

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

rickman <gnuarm@gmail.com> writes:
> I was using a gadget to measure the voltage and current going into the
> rPi.  That side is at 5.25 volts give or take with around 400 mA of
> current.  I moved the meter to the launchpad and the output on the USB
> port is only 4.95 volts.

I remember reading somewhere (probably adafruit.com) that you should use
a pretty beefy 5V power supply with the rpi especially if it's under any
type of load.  They actually tweak their rpi power supplies to deliver
5.25 volts to compensate for some inevitable sag.

I don't remember hearing that the USB ports themselves are out of spec
but it's possible.  Despite popular misconception USB ports are only
supposed to be able to deliver 100 mA unless they grant the client
"permission" to draw more (up to 500ma), through a power negotiation
protocol that's part of USB.  Most x86 motherboards can deliver 500 mA
with no problem, so lots of badly designed client devices just assume
the power is available, and try to draw it without bothering with the
protocol.  Maybe something like that is going on here.

In article <mgpv33$469$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnuarm@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

On 17.4.2015 г. 13:52, Albert van der Horst wrote:
> In article <mgpv33$469$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>>> rickman <gnuarm@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/

On Thu, 16 Apr 2015 20:59:28 -0700, Paul Rubin wrote:

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

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.

On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnuarm@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

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