logs archiveBotHelp.net / Freenode / #43oh / 2015 / September / 21 / 1
Spirilis
Rickta59: hmm, looks like I got my first taste of a template fabooh-esque GPIO library working :)
Rickta59: https://gist.github.com/spirilis/9da2de9a6343183bf9ee
Rickta59
you are either up early or up too late Spirilis :)
Spirilis
heh yeah
daughter woke us up at 3:30, I had fell asleep at 8:30 last night.... realized I wasn't tired when she woke us up
Rickta59
does that generate decent code for you?
Spirilis
I have no idea yet ;-)
it does work though
checking now to see what the write/read's look like
had to comment out other cruft
hmm
not quite familiar with RX ASM yet to determine if this is actually "good" code...
seems a little verbose but then it's no MSP430
http://dpaste.com/2TDYCX7
actually I think half that sh*t is just processing the read-then-!
using a variable that gets XOR'd every loop instead- http://dpaste.com/0P7EA9X
very slightly smaller
Rickta59
you don't get a mixed listing?
Spirilis
not sure why but no
Rickta59
compiling with -g ?
Spirilis
should be... let me check
that's with rx-elf-objdump -C -dS
yeah -Os -g2 -g apparently
-Wa,-adlhn="$(basename $(notdir $<)).lst" -nostdinc -ffunction-sections -fno-function-cse -fdata-sections -fsection-anchors -free -flto-compression-level=0 -fno-cse-follow-jumps -fno-jump-tables -fno-guess-branch-probability -fno-move-loop-invariants -I"C:\Renesas\workspace\sci_uart_drv\src" -I"C:\Renesas\workspace\sci_uart_drv\src\AbstractWiring" ...
... -I"C:\PROGRA~2\KPIT\GNURXV~1.01-\rx-elf\rx-elf/lib/gcc/rx-elf/4.8-GNURX_v15.01/include" -I"C:\PROGRA~2\KPIT\GNURXV~1.01-\rx-elf\rx-elf/rx-elf/include" -fno-exceptions -fno-rtti -D__RX_LITTLE_ENDIAN__=1 -DCPPAPP -Os -g2 -g -flto -mlittle-endian-data -mcpu=rx200 -nofpu
Rickta59
seems like a lot of code
Spirilis
it does
heh up above where the port modes get set, that is kind've neat though
BSET
"Setting a bit"
specify the register and bit# and it'll set that bit
so that _pinmask = (1 << PIN) thing gets optimized down to BSET #5, [r14].b et al
Rickta59
mov.b r7, 32[r14] ... very msp430ish
Spirilis
oh holy crap, didn't realize the GPIO ports are actually all interleaved
#define PORT0 (*(volatile struct st_port0 *)0x8C000)
#define PORT1 (*(volatile struct st_port1 *)0x8C001)
#define PORT2 (*(volatile struct st_port2 *)0x8C002)
#define PORT3 (*(volatile struct st_port3 *)0x8C003)
#define PORT4 (*(volatile struct st_port4 *)0x8C004)
the struct always has some dummy char wk[31] between each SFR
now I see why...
ok well BSET and BCLR are very msp430-ish I'd say
sort've like a 1-bit-only variant of BIS/BIC
ok now not changing 'val' at all...
http://dpaste.com/11MF4YM
hm that's just a tad weird
Rickta59
P1_7.write(val ? 1 : 0);
P1_6.write(val ? 1 : 0);
make it a constant
Spirilis
gotcha
http://dpaste.com/25KQQHV
no difference at all actually
Rickta59
put the val change back in
Spirilis
http://dpaste.com/3Z3AFNX
just seems awfully verbose the more I look at it
Rickta59
yeah not so good
Spirilis
like why not BCLR the bit, it knows how to do it for P1_6
since it's doing mov.b 32[r14], r7 ... bclr #6, r7 ... mov.b r7,32[r14]
ohhh
limitation in the instruction I think
When dest is a register:
register unsigned long dest
dest &= ~(1 << (src & 31));
(that's effectively what the instruction does)
er
nevermind 7 is less than 31
what's also bizarre is the RX does support memory direct addressing here
but gcc isn't using it, opting instead to load into register, modify then write
yeah I cannot think of any good reason why it's doing an AND on P1_7 but a BCLR/BSET on P1_6
okay what hte heck, using -O2 it shows the code
Rickta59
you might have to try some other approaches to make it generate decent code
Spirilis
guess -Os was stripping too much
huh
so the compiler has some aversion apparently to doing BCLR on #7
with P1_6, P1_5 setting val, it still does some suboptimal sh*t but it's more like:
mov.b 32[r14], r3
bclr #6, r3
mov.b r3, 32[r14]
bclr #5, 32[r14].b
.....
does the full deal on P1_5 in one instruction, but 3 instructions for P1_6
that makes no fu*king sense lol
okay even weirder, seems like when I do all 3 pins in that while loop... the first one requires its fancy mov 32[r14], r3, then set whatever, then set back, while the other 2 just do direct bset #<6 or 5>, 32[r14].b
seems like just crappy inconsistent code generation to me
anyway, it's an RX, damned thing has enough speed and flash and runs 0-waitstate, guess I don't need to care that deeply
the ability to declare const gpio's as template arguments for drivers is reason enough to use this as is
now the next item of fun is..... testing the extended serial API
such as break callbacks, 7-bit, parity
think I am going to try adding RTS/CTS to this one too
ike
atmel
did you get it?
Spirilis
yeah I saw atmel got bought
not shocked :)
ike
I was hoping that microchip will buy atmel ;)
I wonder if this is better than msp430 http://linuxgizmos.com/16nm-zynq-soc-mixes-cortex-a53-fpga-cortex-r5/
16nm four Cortex-A53s cores, a faster FPGA, a GPU, and two Cortex-R5 MCUs.
Spirilis
doubtful
ike
DDR4 support of up to 2,666Mbps for massive memory interface bandwidth
Spirilis
that is utterly ridiculous
like a beaglebone on massive amounts of crack
« prev 1 2 next »