Mecrisp on the TI Stellaris Launchpad

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:

formatting link

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
Reply to
rickman
Loading thread data ...

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!

Reply to
sbattazzo

--------

--------

s
e

Windows.

get or yum install libusb-dev and type make from the lm4flash directory off of the github. That should pretty much be all!

OK I gave it a quick try on my Ubuntu vm out of curiosity. I already had th e libusb-dev package installed, but the makefile is actually set up to depe nd on the 1.0 specific version of that package. Turns out that's fixed by j ust doing "sudo apt-get install libusb-1.0-0-dev" which took just a few sec onds 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 anothe r flasher utility (with an exe out of the box) in place of lm4flash in that case.

Steve

Reply to
sbattazzo

Last reply to this thread.. if you're on Windows it looks like TI provides what you need here:

formatting link

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 .

Reply to
sbattazzo

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
Reply to
rickman

Oh, I forgot to say thanks. Thanks :)

--

Rick
Reply to
rickman

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 alrea dy there 99% of the time (Raspberry Pi should have a compiler on board as w ell) so as long as you have the library sources you need you can usually ge t away with just typing "make" and when you get an error, somebody on one o f the Linux forums or stackoverflow has probably asked about it already.

Reply to
sbattazzo

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
Reply to
rickman

--------

--------

s
e

Windows.

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 stumbli ng 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 li ne, but it says "command not found". The file has no visible extension. I s that expected? What am I missing?

Reply to
rickman

Try ./lm4flash

Reply to
Paul Rubin

----------

----------

m

am

en

s

ld

he

ols

the

00

.

n Windows.

t-get or yum install libusb-dev and type make from the lm4flash directory o ff of the github. That should pretty much be all!

ling 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

Reply to
lasselangwadtchristensen

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
Reply to
rickman

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.

Reply to
Paul Rubin

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
Reply to
rickman

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.

Reply to
Paul Rubin

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.

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

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.

Reply to
Mel Wilson

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

Reply to
Blajrs Jrolrsen

...

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 
 Click to see the full signature
Reply to
Anton Ertl

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.