Jump to content
igor

eLua for Stellaris Launchpad

Recommended Posts

This is what I got on my connected launchpad:

 

> print(cpu.clock())

9600000

 

9.6MHz?

 

Just a simple while loop setting and clearing a port bit yielded 2.3kHz (~400us) if that gives any clues.

Share this post


Link to post
Share on other sites

Anyway, on the uart clock version I can duplicate cpu.clock returning 9600000.

 

I have tried all the sample programs

 

adcpoll.lua and adcscope.lua both appear to function correctly

 

led.lua has board detection as part of the script and throws an error about not recognising the board.

 

life-bit works

 

lm4f-inttest returns

lua: /rom/lm4f-inttest.lua:12: attempt to call field 'set_int_handler' (a nil value)
stack traceback:
        /rom/lm4f-inttest.lua:12: in main chunk
        [C]: ?
 

pwmled also has board detection and prints that the TM4C1294 is not supported by this demo.

 

sam\cnt, sam\inttest and sam\stars also error although I think target another board so I can't say I am surprised

sam\life does work though

Share this post


Link to post
Share on other sites

Scratch that, I'm a fool that forgot to set the pin directions to output beforehand

 

(previously posted about not being able to blink the LED's)

 

 

 

Entering the following to a lua prompt currently works fine

led = pio.pin.PN_0
push = pio.pin.PJ_0
pio.pin.setdir(pio.OUTPUT, led)
pio.pin.setdir(pio.INPUT, push)
pio.pin.setpull(pio.PULLUP, push)
pio.pin.sethigh(led) --Led comes on
pio.pin.setlow(led) --Led turns off
print(pio.pin.getval(push)) --returns 0 if I hold SW1 and 1 if I release the button, multimeter returns 0.01v and 3.26v respectively (I did only pay £2.50 so any inaccuracy is likely in the meter itself)

Share this post


Link to post
Share on other sites

Have you just attached a new binary on the previous post? Both windows explorer and 7 zip are reporting the zip as invalid

 

Yes - there was a new version.  I removed it and uploaded a fresh copy.

 

Sorry about the led.lua and pwm.lua not working, looks like I accidentally used older versions.  Fresh upload has versions that should work with connected launchpad.

 

As you surmised, the files in the sam directory are specific to the Arduino Due port.  (Not intended to work on the launchpad).

 

Thank you for running the tests.

Share this post


Link to post
Share on other sites

Igor, i've tried building lm3s6965 and lm4f120 versions under linux, but the resultant binaries dont work. Official builds do. I've tried both codesourcery and building gcc with the same result. Is there some magic i must do? Or should it just work out of the box?

Share this post


Link to post
Share on other sites

Igor, i've tried building lm3s6965 and lm4f120 versions under linux, but the resultant binaries dont work. Official builds do. I've tried both codesourcery and building gcc with the same result. Is there some magic i must do? Or should it just work out of the box?

 

No magic that I can think of.  

Just to be certain I just rebuilt the lm4f120 from the current state of the LM4F branch, flashed it to the Stellaris launchpad.  Got the shell prompt, etc.

lua build_elua.lua board=EK-LM4F120 prog

I have not tested the lm3s6965 build from my branch, so it is possible that it might have been inadvertently broken by some of my revisions.

I have tested the lm3s8962 build from my branch, and it works.

 

I am using Windows, but I don't think that should make a difference.  (I hope the tools are smart enough to handle the different line end characters in the source files, which is the only relevant difference I can think of.)  

 

Do you get any characters on the serial console when press reset?

You could try disabling as many modules as possible in the board configuration file, see if you can get a stripped down version going, then add bits back in.

(to try to identify what module is causing problems).

 

What version of the LM4F120 do you have?  Mine is an A3.  Currently the build doesn't specify what version of the silicon to build for, but you could add a macro to the board file to tell it to build for your version. e.g. add to macros section something like

{ "TARGET_IS_BLIZZARD_RA2", "" },

(I do not expect that to make much difference - but something one could try.)

 

I assume the LM4F120 binary I posted works on your Stellaris LP?

Share this post


Link to post
Share on other sites

Igor, your builds work. The lm3s6965 that i built was from the main branch of code. The boards are dead - nothing from the serialport so something is very wrong. I'll try under Windows and see if that works.

Share this post


Link to post
Share on other sites

Turns out lm3s6965 would not build in the lm4 branch due to changes in the libraries.  I fixed it so it now at least compiles.

(I also found an error in the main repository for that board - it used the wrong cpu.  Have submitted pull request with fix.)

Share this post


Link to post
Share on other sites

Just latest binary for connected launchpad.

 

cpu.clock returns: 117440512

my little lua script from above works as before

led works

pwmled appears to do absolutely nothing besides printing "Control LED with PWM (fade up/down)"

Share this post


Link to post
Share on other sites

Igor - you're the man! I was able to successfully build the ek-lm3s6965 with the mods you suggested. Strangely, I had noticed the wrong cpu, but thought it was meant to be that way.

 

I downloaded your latest branch and made some mods to get the mmc/sdcard working. I used ssi1 and did some brutal changes to make it work. I chose ssi1 as this is supposedly the only one that will work in legacy (spi) mode according to the errata. I haven't tried any others ssi ports to verify this. I'll see if I can do a readup on the sdcard 4 bit mode and see if the ssi can support this - thus we can use the other ssi ports if this comes to fruition.

 

Interesting side effect is the adcscope.lua program generates a FAULT message and dies. I gather this is a fault exception. Something is NQR (not quite right)

 

Again, thanks for your great work.

 

[edit] Just did a readup on sdio - it was a bit different than i had first envisioned - ssi won't do it.

Share this post


Link to post
Share on other sites

I downloaded your latest branch and made some mods to get the mmc/sdcard working. I used ssi1 and did some brutal changes to make it work. I chose ssi1 as this is supposedly the only one that will work in legacy (spi) mode according to the errata. I haven't tried any others ssi ports to verify this. I'll see if I can do a readup on the sdcard 4 bit mode and see if the ssi can support this - thus we can use the other ssi ports if this comes to fruition.

 

Interesting side effect is the adcscope.lua program generates a FAULT message and dies. I gather this is a fault exception. Something is NQR (not quite right)

 

Again, thanks for your great work.

 

[edit] Just did a readup on sdio - it was a bit different than i had first envisioned - ssi won't do it.

 

Are you sure about ssi1 being the only one that will work in spi mode?  My understanding of the errata was that in the first revision of the chip, all of the ssi's were limited to 

legacy (spi) mode, but in the second revision, ssi1 was the only one limited to legacy mode, and the rest could do legacy or advanced modes.  I can see where the language is a little bit ambiguous, and I may have misinterpreted the errata.

Did you try running any of the other ssi's in legacy mode (the proof being in the pudding)?

 

Disappointing to hear that the ssi won't do higher speed i/o for sd cards.

 

I just pushed a few updates to github which should fix some problems.  

 

Yes, the FAULT message means a fault exception.  I haven't looked at the ADC code yet.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×