samr21: implemention of transceiver via spi

[Troels51]

Implementaion of the at86rf231 driver for the samr21 chip this include

• A gpio fix
• An SPI implementation with SPI_0 being used for the internal transceiver. Does not support more than 1Mhz transfer

[PeterKietzmann]

I think you just need to use the transceiver module if the netdev is not available. You could do something like this:

ifneq (,$(filter defaulttransceiver,$(USEMODULE)))
    USEMODULE += at86rf231
    ifeq (,$(filter netdev_base,$(USEMODULE)))
        USEMODULE += transceiver
    endif
endif

[haukepetersen]

Hi @Troels51, first of all, very nice work! Sorry for putting quite a few comments in your code. I think the overall SPI driver is in a very good state, most remarks are rather minor structuring things.

I would suggest you put out the fixes to the GPIO driver as separate PR. Important to understand about the low-level driver concept is, that the SPI and GPIO parts should be completely independent. The SPI driver should only care about MISO, MOSI and SCLK pins. All other pins should be simply configured as standard GPIO devices for the GPIO driver. The radio driver will then take care of using these GPIOs...

[PeterKietzmann]

Maybe you can avoid the modulo- and division operations by definig distinct configurations in the periph_conf.h like @haukepetersen said

[PeterKietzmann]

I really like this PR and will test it soon!

[PeterKietzmann]

Even if you did not implement the SPI slave, could you also "implement" spi_transmission_begin (like spi_init_slave) because the SPI test includes this..

[Troels51]

In cpu's with a different endian from the transceiver the short would be reversed right?
I found that my messages were getting filtered by the transceiver.. when i used HTONS this problem disappeared.

[thomaseichinger]

How do you send? When interacting directly with the RIOT transceiver you have to specify the destination address in network byte order. (see _transceiver_send_handler in sys/shell/commands/sc_transceiver.c)

[Troels51]

It came about when i was trying out the rpl_udp example, i could only receive multicasts before trying to reverse the network order. Could it be that the byte order of the address is reversed at another point and i'm just correcting it?

[maxencechotard]

@Troels51 do you know how to use default exemple with shell functionnalities ? Have you ever managed to do this ?

[Troels51]

@maxencechotard Hmm, i just tried the default example (i should probably have tried it before) and it only works without reversing the byte orders, so reversing is not the solution.

But when trying the rpl_udp i can only get messages through when using HTONS on the addresses, so the problem must be somewhere else.

[biboc]

I post here about the GPIO and EIC. @Troels51 I tried the source code by configuring an interrupt on SW0. Here is what I did:
value = gpio_init_int(GPIO_1, GPIO_PULLUP , GPIO_BOTH, callback_test,NULL);
gpio_irq_enable(GPIO_1);
Am I doing right? Because the pull-up doesn't seem to be right set (TP300 is not 1)
The callback "works" but plenty of time instead of only when I press the button.

[biboc]

Ok I found your error.
In gpio_init_int, you use gpio_init_in to configure the pin as an input. Then you use WRCONFIG in gpio_init_int and you write WRPINCFG to 1 which "update the Pin Configuration register (PINCFGy)" so all your previous config are set to 0.
And then the pull up is disable and it was why I observed a weird behaviour of my callback ;-)

You just need to call :
/* configure pin as input */
res = gpio_init_in(dev, pullup);
if (res < 0) {
return res;
}
after WRCONFIG and it works.

[thomaseichinger]

@Troels51 please address @bapclenet's comment and rebase so we can merge this one.

[saurabh984]

@Troels51 Could really do with this merge. Let me know if there's anything I could do to help. I have 15 of these boards lying around gathering dust.

[biboc]

@Troels51, I found another weird behaviour.
Set the switch as an interruption, try it for a while and after 15sec, set it as disable (the interrupt doesn't work which is fine), then set it back to enabled, at this moment when INTENSET bit is set to 1, an interrupt is raised which is not expected as I didn't press the button. Do you see what I mean?

Even if it works after enable it for the second time, the interrupt which is raised after enabling the interruption shouldn't occur. What do you think about that?

PS: I've got the same problem with RTC's interruption

[biboc]

Clear the interrupt flag of the given GPIO:
EIC->INTFLAG.reg = EIC_INTFLAG_EXTINTX;

[biboc]

Ok, I found how to solve your problem:
Clear the interrupt flag of the given GPIO before EIC->INTENSET.reg = (1 << (extint));
EIC->INTFLAG.reg = EIC_INTFLAG_EXTINTX;

[Troels51]

@bapclenet I implemented the change you suggested, do you think that solves the problem you were having? it seems weird that it is connected with the RTC

[Troels51]

@saurabh984 Sorry for being a bit slow, i've been focused on some school work. You could pull the changes from my branch directly to see how it works.

[biboc]

Yes that was the same problem. They are not connected but the interruption system is similar in both component. (INTFLAG,INTENTSET and INTENTCLR)

[Troels51]

So you have to clear the flag before you can enable the interrupt?

[biboc]

Yes, the same as you. I don't know why the flag is set to 1 before renabling the interrupt but this solution works.

[thomaseichinger]

@Troels51 could you address @N8Fear's #1997 (comment) and squash? I'd say we are good to go then. Travis failing for stm32f0discovery and riot_and_cpp seems unrelated.

[Troels51]

Added the newline and squashed the commmits

[thomaseichinger]

Perfect. could you rebase one last time to include #2204. Just to be sure.

[thomaseichinger]

Travis passed, code looks good, tested and works. Let's do this. ACK & Go

[thomaseichinger]

Congratulations.