Mecrisp on the TI Stellaris Launchpad

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!

--------

--------

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

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

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 .

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.

Oh, I forgot to say thanks. Thanks :)

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.

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.

--------

--------

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?

Try ./lm4flash

----------

----------

am

en

ld

he

ols

the

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

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.

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.

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.

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

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.

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.

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

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

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.

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

...

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