logs archiveBotHelp.net / Freenode / #43oh / 2015 / September / 9 / 1
Hey guys, question: I have a stellaris launchpad that got smooshed, and a lot of the pins got bent. Is there a good way to test all of pins and see if they all still work?
Like my idea would be to set every pin to output a high and go through to see if they all read high on a multimeter -- I guess I'm wondering if there is some flaw in that plan
try that, then try with them all low
ok.... tried the ldscript option, now it's boiled down to C++ bi**hing about the whole concept of the struct st_rspi I think.
SPI.h has stdint et al in it
Spirilis, thanks
ohhhh, nevermind, this is a genuine bug in my code
it's not rspidrv.SPDR.WORD, it's rspidrv.SPDR.WORD.H
there's a member inside the struct
though I'm not sure why there's just an H in there and not an L
though apparently that's how it's always been so oh well
H is just the lower 16 bits ... to get the longword you just use the LONG symbol in the union
got it to build
apparently the ldscript is auto-generated by eclipse, but you can add custom options to the linker so I added a -T${workspace_loc:/test/src/rx210_peripherals.ld} where that .ld has the _SFRBASE_RSPI0 defined in a special section at the 0x88380 address
defined the struct in test.cpp as extern volatile struct st_rspi SFRBASE_RSPI0;
and provided SFRBASE_RSPI0 as the template arg
template itself defines it as a volatile struct st_rspi & rspidrv
then it does rspidrv.SPDR.whatever type of stuff
no pointer references, just straight out struct stuff
only bi**h of it is having to generate SFRBASE_* for all the iodefine crap
guess I'll generate a script for that
which generates an .ld and a .h
ok enough fun for now... will have to actually *test* this later ;)
Hey, off the top of anyone's head. Is there anything special about PB0/PB5 on the stellaris that would cause them to output 1v as high?
or are they b0rked
OK, so I retested at a different point on the pin and I get 3.3v! Coolbeans!
hmm, the C++ template sniff test so far is mixed.
I got the program working and SPI firing signals..... but there were some bizarre quirks with the IDE
and/or compiler
like static allocated classes trigger continual breakpoints somehow
as if some sort of exception is being triggered (i.e. IRQ or NMI)
can't view the variables.... not sure why
breakpoints in main() don't show the source
that is really bizarre, wonder if I have to do extern "C" around main or something
not sure what PCLK is currently set to coming out of the gate but it's lower than I thought it would be
either way, making progress
got caught up with an RX210 quirk that didn't exist in the RX62N, in order to turn on peripheral modules' clocks you have to disable the write protection on the MSTP registers
that was fun hunting down, then you can't just set the write protect bit individually, you write word-at-once a key along with the new value
(makes sense I guess, just, wow, 2 subsequent layers of "write protection" there)
Hm. Strange. The built in RGB led doesn't seem to work on the board
isn't PB5 one of the uart pins?
or is that supposed to be the led?
no .. nm it isn't either of those
http://energia.nu/img/StellarPadLM4F120H5QR-V1.0.jpg did you find that?
there is something weird with a couple of the pins if i remember right ..
a 0ohm resistor that connects another pin
or maybe that was the tiva board
pb7 and pd1 are 0 ohm connected
as are
pb6 and pd0
Looks like Ketra fell through. Think it's time to start applying to do manual labor.
hehe, TI is "inviting" me.
Texas Instruments is currently recruiting highly qualified engineers for the Texas Instruments Expert Advisory Panel. Your specific skills and experience put you in a special position to provide key insights
How the **** did they ever think that a dude that proved that he could make a blink program work on the $4 launchpad is worth spamming as "an expert" is beyond me. 8^D
Gives a new meaning to how to visualise the difference between depth-first and breadth-first searches, I guess.
Rickta59: hmm, there shouldn't be any problem in a C++ template calling another overloaded version of a function from an overloaded version of itself right? let me explain...
begin(SPISettings s)
the latter copies the contents of 's' into its internal SPISettings instance and then runs begin()
kinda looks like the rx-elf-gcc compiler is fu*king the last part of that up
it's taking the address of the current object, extracting some address from that, then jsr (jump to subroutine) into that
thus ensuring it ends up executing 0x00000000 (beginning of SRAM where SPI instance is located in the .bss)
pull out the begin() call and run it separately from the caller (SPI.begin(SPISettings(8000000UL,MSBFIRST,SPI_MODE0)); SPI.begin();)
and it's good
ok, reproduced and confirmed the bug
it's a problem with derived virtual functions
with a straight library not inherited from another, the problem doesn't happen
but if it's inheriting from a library with a pure virtual definition for void begin(void) = 0; .... it gets confused
at least I have something decent to report now
aight, reported to the kpit guys
my guess is redhat would have to get involved with that
assuming it's a bug in the upstream
interesting ..
got some TI fodder today ..
new tm4c1294 launchpad .. actually tm4c129e .. $16.99
not a bad price for a ethernet enabled 1M flash lots of ram board
supposedly with crypto support ..
sounds like something a Spirilis would like
i was just checking ..
the nuttx supposedly supports the tm4c1294 ..
might make a decent nrf24l01+ gateway
Cypto Connected
well that's good they're getting into crypto
256k .. ram .. * was just looking at specs
yeah same as the TM4C1294 then
1MB flash, 256KB SRAM
is the flash on those 0 wait states?
I don't think so
not sure though
pretty certain not
prefetches 256 bits at a time
hmm .. slow actually
5 wait states
« prev 1 2 3 next »