logs archiveBotHelp.net / Freenode / #43oh / 2015 / September / 5 / 2
with the way memory gets split in 2 parts, even if they got all the stuff right you are constantly going to be playing the packing game to figure how best to place your code/memory and data
* this is with regard to chips with more than 64k of flash/fram
once you leave a single segment with the msp430 .. i'm not sure it is fun any more
it is just so much easier to use a bigger chip and not have to think about that kind of thing
bigger / different arch
ok fuggit
msp430fr59xx, fr41xx support
that's as far as I need to go
not that there's much difference between those two, it's eUSCI
and clocking is different but then again... AbstractWiring has you do that yourself
doesn't have to
implementation-specific section can have clock configuration too, and should if you wanted to roll some fancy dynamic clocking
and that might be worthwhile on the FR chips
but either way
sounds like the safest bet is to stick with <64K stuff
fact is fr59xx wiring core would work with >64K stuff you just have to doctor your own ldscript, and the whole abstractwiring idea is meant to be "copied into" your pre-existing environment
i.e. bolted on
is all the fram at less than 64k on the fr41xx? I thought they had stuff up high
or is that 16k only
fr41xx is 15KB FRAM total
or 15.5KB or whatever
FR59xx has 16K above 64K
ah .. yeah that is fine than
so that wouldn't be accessible unless you use that HighMem library I wrote ;-)
or use the new stuff and manually distrubute your code/data
man I must have a hidden hardware stash somewhere I forgot about.... cause now I can't find my RF430CL330H boosterpack
which was my go-to target for I2C testing
* the wife is secretly throwing out one each week
just found it
a CC3100 boosterpack box
had it in the back of my shelf
i have a insane amount of boards
not sure how that happened
impulse buying i guess
looks like this was to be my beaglebone play box
got my beaglebone launchpad adapter cape, nrf24 bpak, GPS bpak, RF430, and the lightning sensor module + diy pcb bpak
what were youj going to power all that with?
battery or wall socket
I have a wall adapter for the beaglebne
although none of those require much power
also my coworker bought some cheap Cubieboard 1's a short while ago when newegg had some deal
so we have one of those at work on my desk
tell you what, that thing doesn't miss a ping and doesn't go out to lunch within a few days of idle time like my beaglebone
Allwinner A10 chip... SATA, but only 100Mbps ethernet
only heh
I was thinking it'd be cool to try the Banana Pi, with the A20 (SATA + GigE) as a backup storage device
do you have any hard drives connected to it?
not yet, I have a suitable SATA power adapter cable coming next week though :-)
i heard those cubies get hot
and a bunch of crappy old SATA 250GB disks in my desk cabinet
hm guess we'll see
here we go, found the 1st gen Educational bpak, good for ADC testing
lol, analog tempsensor reading works, but it is rather chatty
bouncing from 25 to 32C rather fast
got ADC10DIV_5, ADC10SHT_3 active...
got a __delay_cycles(128); after turning ADC10ON | REFON | etc.
meh, tempsensor isn't sampled that often, I just resorted to doing 8 samples and then >>= 3
pretty stable now ;)
4 samples was still a tad noisy
ok, ADC sampling looks good enough
0-1021 with the edubpk potentiometer
pretty stable
it uses the G2553's built in calibration constants too
though I do need to put some logic in to interpret the TLV table for those chips (and most of the value line ones are like this) that don't list the TLV table location for ADC constants in their header file
....probably another TI fail
stuff like the G2744 and G2955, newer value-line's, don't have those TLV tables listed in their header files, although I would bet they have them
how big is a typical app?
Rickta59: edubpk_pot.elf 5154 bytes, spi.elf 4908, spitrans.elf 4558, tempsensor.elf 5470, test.elf 3358, uart,elf 4306, wire.elf 5156, wire_rw.elf 6482
tempsensor is probably big because there's some int32_t math involved in using the built-in temp sensor constants
i'll have to check out your github and see what we can do
are you using msp430-gcc?
ah .. well of course ; )
the version I built like back in April still
not the very latest TI d/l
it has probably grown since then : )
anyway these sizes aren't too bad for now
yeah .. i often stress over it ..
but as long as you still have flash who cares
ram is usually the gating factor
speaking of which, I do need to audit the bss on those
seems a bit high
have you tried the -minrt thing?
well data+bss
oh hm, msp430-elf-size was showing data as 306 bytes or something, but msp430-elf-objdump -x shows the .data segment as 0x3e
hm, some constants ending up in .data
forget how to do that...
declaring them as const volatile uint8_t *'s, but, how to make the array itself store in .text
beyond just using __attribute__
const volatile uint8_t * const
« prev 1 2 next »