logs archiveBotHelp.net / Freenode / #43oh / 2015 / September / 8 / 3
Rickta59
those sensors are on a ti booster pack?
cambazz
no, they are on i2c. adafruit ina 219 modules.
Rickta59
ic
that video talks about energia and CCS
maybe he talks about sharing data between tasks
cambazz
i made all on a breadboard, i developed it with msp430f5529 and now porting it to my new lovely msp432
Rickta59
neat
cambazz
well i will watch the video for sure now, then ask a question maybe on the 43oh forum
Rickta59
yeah rei vello seems to a dog with a bone about energia mt
you might ask him
cambazz
ok thanks.
Spirilis
hmm, compiler's throwing some weird errors when passing a reference to the RSPI0 register struct. http://dpaste.com/342QWRF
iodefine.h defines RSPI0 as (*(volatile struct st_rspi *)0x88380)
and RSPI_RX210's template argument is defined as a volatile struct st_rspi & rspidrv
huh http://www.avrfreaks.net/forum/c-template-specialization-sfr
if I'm reading that right, the only way around this is to declare a volatile struct st_rspi in my code, but ensure the ldscript points it to the correct location
that sounds completely asinine
and why doesn't msp430-elf-gcc complain about that?
Rickta59
can't you make it a static?
it is just a const no?
or a reference
Spirilis
it's not even a const, it's a #define, but then again, so are the SFRs in msp430xxxxx.h right?
Rickta59
that is your define?
Spirilis
well, it's Renesas's define, comes standard with the project generator and may differ from chip to chip
iodefine.h defines RSPI0 as (*(volatile struct st_rspi *)0x88380)
Rickta59
basically it is the base address of the struct
that isn't going to change
Spirilis
yup
so what would I do, a "const volatile struct st_rspi *rspi0 = &(RSPI0);" in test.cpp and pass rspi0 as an argument, then expect the template to use it as a pointer to the struct (i.e. ->)?
Rickta59
i ran into various c++ differences
trying to get stuff to work in both ti c++ and g++
i think i ended up using static functions returning const &
Spirilis
yeah just strange to me that this is g++
Rickta59
https://github.com/RickKimball/fabooh/blob/master/include/cortex-m0/core/gpio.h#L110
Spirilis
rx-elf-g++ but still
Rickta59
what version?
which --std?
Spirilis
oh interesting I see what your code is doing. one sec
Rickta59
it will take all that crap and basically come up with an address
constant
https://github.com/RickKimball/fabooh/blob/master/board/lpc1114fn28/LPC11xx.h#L551
Spirilis
looks like 4.8.3 btw
not sure what std
Rickta59
https://github.com/RickKimball/fabooh/blob/master/board/lpc1114fn28/pins.h#L13
so i just use constant integers
and then return the address based on the integer
but it is a function so it whines a lot less
but everything is a const so it all gets done at compile time and distills down to a constant in the code
Spirilis
I see...
yeah I could probably do something like that
Rickta59
just another approach
i'm sure you can get your style working with enough self flogging :)
the key is getting to all be constants
Spirilis
yeah this is a rats nest, can't figure it out
gonna have to look more later
https://gist.github.com/spirilis/e40e7037300bc00e5f64 so far
right now the template is there but not actually used
template arg rather
Rickta59
i noticed in the newer gcc .. __always_inline is defined in the gcc headers
* nicer looking than my screaming ALWAYS_INLINE
Spirilis
ah lol
Rickta59
lib/gcc/arm-none-eabi/4.8.4/include-fixed/sys/cdefs.h
and __noinline
... some useful stuff in there now
Spirilis
weird that it's saying invalid cast from type 'volatile st_rspi::<anonymous union>::<anonymous struct>' to type 'uint16_t {aka short unsigned int}'
struct st_rspi has a bunch of unions and bitfields 'n stuff
but wtf
Rickta59
might be throwing it off
pointers are 32 bits?
Spirilis
yeah
Rickta59
just pass it as a uint32_t
and cast it
Spirilis
not sure what you mean
Rickta59
template< const uint32_t base_addr> ....
RXSPI_RX210<0x12345666> foo;
in the code ..
cast using ...
(volatile struct st_rspi *)base_address;
or c++ style
<volatile struct st_rspi *>(base_address);
Spirilis
hm
yeah the general idea is to prevent from having to do that so I can leverage what iodefine.h already has
since it may vary from chip to chip
but if this isn't resolveable I may have to resort to something like that
well I want to try the ldscript option for offering the address next.... that would be somewhat tenable since I'd already decided to ship modified ldscripts with each RX impl-specific port of AbstractWiring
« prev 1 2 3 next »