search

ut-ras / Rasware

A generic robotics controller for the EK-LM4F120XL Stellaris Launchpad.
ras.ece.utexas.edu
Other
4 stars 0 forks source link

Linux instructions #12

Closed robz closed 10 years ago

robz commented 11 years ago

README.md currently has an empty section for compiling and loading RASDemo onto a Launchpad. If this is possible to do, the readme should contain detailed steps for doing it. Cruz, could you do this?

cmonr commented 11 years ago

I'll look into it this weekend. Will also try out the Windows instructions this weekend as well.

robz commented 11 years ago

@theotherjimmy

theotherjimmy commented 11 years ago

I'll look into it tonight. do we have a compiler preference? GCC, IAR, SDCC, others I am unfamiliar with.

theotherjimmy commented 11 years ago

So I looked into it right now, and there is no support for anything other than the keil IDE at all. Cruz, I'm stealing the Makefiles I refurbished for you and using them here. I'm going to use arm-none-eabi-gcc as a compiler because I know how to.

theotherjimmy commented 11 years ago

I have forked the repo, and am creating linux support in my fork. at the moment I am using printf and other things. there is no readme as of yet. I still need to get rasdemo working before I write a readme.

robz commented 11 years ago

aight. thanks for working on this jimmy!

geky commented 11 years ago

This might potentially be useful. At the very least, we should look into using the lm4flash tool.

cmonr commented 11 years ago

We (Jimmy and I) are using lm4flash. The issue is debugging. Not sure how up to date OpenOCD is on other systems (the ICDI interface used by the launchpads just got added in). Arch uses a Rolling Release cycle and has something called the AUR, which is like an in-testing repo.

I think for Ubuntu and other systems, OpenOCD would need to be patched and compiled.

geky commented 11 years ago

Ah, Ok. It looks like the tool already supports some sort of connection to ICDI for GDB here...

cmonr commented 11 years ago

@theotherjimmy Thoughts about using lm4tools over OpenOCD?

theotherjimmy commented 11 years ago

Use both. Can't see why not. The only down side is that lm4flash takes up an extra ~1MB on your hard drive and the install instructions require one more tool.

OpenOCD is good for debugging (hence the D). lm4flash flashes faster and the interface is cleaner. besides, it's older and should be available in more distros because of it.

If you look at my branch, all of this is in place. No instructions as of yet. I have to get everything working first, but it compiles and flashes on my system. Also, we're using printf 'cause we have no 32k limit, just the chips 256KB limit, which is plenty.

theotherjimmy commented 11 years ago

Oh yeah @cmonr, you're wrong, We use both lm4flash and OpenOCD.

cmonr commented 11 years ago

@theotherjimmy I was referring to debugging only...

cmonr commented 11 years ago

Specifically this: https://github.com/utzig/lm4tools/tree/master/lmicdiusb

theotherjimmy commented 11 years ago

Looks like it'll work, but I doubt it's in any Ubuntu-like repo. That being said, it's nine months old, and I would love to be wrong on this one. We really don't need the bulk of OpenOCD, and worst case we can host the flasher and debugger on RAS's website in as many formats as I can auto-generate.

theotherjimmy commented 11 years ago

I would also like to auto-generate arm-none-eabi toolchains for each of the common linux distros and hosting them on the wedsite. If we are already the source of most things linux-lm4f, then we might as well be the source of all things linux-lm4f.

major distros I was thinking of supporting: Debian, Arch, Redhat/Fedora.

geky commented 11 years ago

@theotherjimmy, do we really care if its in the repo? Sure that would make it easier, but we can probably expect linux users to compile it from the github repo....

Also, do we know anyone who actually uses Redhat/Fedora?

theotherjimmy commented 11 years ago

I do, at work. also, I though the point of RASlib was to make things we don't care about them learning easier. In particular, the cross compiling toolchains are among the hardest thing to compile, short of patching your kernel. While we could expect them to compile it for themselves, we might heighten the barrier to entry for using Linux or Robotathon; Both of which I consider bad.

theotherjimmy commented 11 years ago

I'll do it if/when I see fit. I think you mean for it to be a low priority goal, which I agree with.

geky commented 11 years ago

Ok, valid point. I just didn't think not having it in the repo was worth invalidating a simpler tool.

theotherjimmy commented 11 years ago

Yup. We should use it if it's a GDB server (feature compatible) and simpler. At the moment we use OpenOCD as the GDB server. I will look into lmicdiusb after I get RASDemo working. As usual, A working solution now is of higher value than a perfect solution later. To it's credit, lmicdiusb is a ton easier to compile.

theotherjimmy commented 11 years ago

So I looked at lmicdiusb this weekend. I am unhappy with it. Most importantly we would lose all of the monitor prefixed GDB commands from openOCD. The one I use most (in scripts) is the "monitor reset halt" command to put the MCU into a state of halt at the start of the reset handler.

Another update on linux port: I am short a filled out interrupt vector. other than that, I have a working RASDemo.

theotherjimmy commented 11 years ago

I just looked up the minimum version of OpenOCD to get ICDI support: 0.7.0, and the version in Debian at the moment: 0.7.0-2. looks like OpenOCD is in the repos now. unfortunately, lm4tools are not in Debian. They are both in at least the AUR on Arch. and like Geky said, who uses RHEL/Fedora?

Cross Compilers: Arch: In Community repo. Debian: https://wiki.debian.org/EmdebianToolchain, though we just need the compiler and linker. It should be easier because they also discuss libraries. I'd need a Debian box to test, but I think that after adding the repo metnoined in that wiki page, you should be able to just =apt-get search armel= and select gdb and gcc to install

theotherjimmy commented 10 years ago

Looks like both Chris and I are doing a port of RASLib. Mine is 'done' minus clear instructions (I think my instructions are a bit criptic as of the time of writing). Chris will likely be done with his very soon if he's not arleady done.

There are slight differences between our ports, like the wording of our partial instructions, using OpenOCD vs. LM4Flash, and where we put the driver-like udev rules files, that I don't think are that important. Therefore, if anyone has a preferenc on these differences, then they may pick winners for the 'official' linux RASLib.

There are two key differences, or differences that I have opinion about: the startup file, and the Makefile. Chris has created a startup file that is compatible with Kiel. I think that Chris's statup file should be supercede both my startup file and the Kiel assembly file. However I am of the opinon that my Makefile is more appropriate for Robotathon. While I dislike hiding the details of the flashing process and the simple method for communicating over uart, I have hidden them (I saw it as automation when I was writing) with my Makefile. I think this is better for Robotathon as this can help reduce the intimidaton of the *nix environment for newer users. Further, my Makefile prevents a frequent problem: running the uart, but forgetting to flash the board. I prevent this by providing one make target for the whole compile-flash-uart process, the 'uart' target. edit: I think the 'frequent problem' I intended to describe was when the user forgets to recompile and flashes an old executable. My Makefile also prevents this.

If we decide that some of my stuff would be useful to the 'official' port of RASLib, then I volenteer to merge it. However, I don't think the contens of RASLib are my call alone.