I want to use AT86RF231 with an arm processor. Are threre librairies and code examples available somewhere or do i need to adapt code from avr examples?
Thanks for your advices and answers.
Have a look at the Atmel MAC sourcecode. It contains support
for SAM7 and probably also SAM3 (Atmel Cortex-M3).
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
i've downloaded it already and i will have a look now i know where to look. (there is for SAM3)
I understood i needed to use the PAL and TAL API functions and adapt it tp my Âµ.
Do you know if Âµracoli Libraries contains code for Cortex-M3?
If yes, what is better to adapt, Atmel MAC sources or Âµracoli Library?
Thank you :)
You might find some useful code at http://www.newae.com/tiki-index.php?page=15dot4sniffer which contains a SAM7s sniffer.
> Do you know if Âµracoli Libraries contains code for Cortex-M3?
Not yet. Axel has plans in his mind to eventually extend Âµracoli
to Cortex-M3 devices, but it hasn't been done yet.
In my use of the AT86RF231 i see there are some problems if i don't use a (10k) pull-down on the SLP_TR pin ((the chip version can not be read in trx_init.c)).
Has someone encountered the problem already?
I didn't see in the code that SLP_TR should be configured with pull down and i didn't see it in the application schematics. Are there other pins that need such a configuration?
A 10 kÎ© pull-down on SLP_TR won't do you good. If you put
the transceiver on sleep, the resistor will draw 300 ÂµA!
The transceiver has some internal pulling, but this is only applied
during P_ON state. The idea is that the controller gets time to setup
its SPI interface properly, and once that is done, it can proceed
issuing the CMD_TRX_OFF command to the transceiver. Upon the
transition from P_ON to TRX_OFF, the internal pulling resistors will
be disabled, in the assumption that the controller's interface lines
will now take over full control.
There's only one potential pitfall I could see: if your controller
catches an unexpected reset, it will float its IO lines, leaving them
in an undefined state. However, as long as you don't need the
AT86RF231's CLKM clock to drive the controller (which is fairly
unlikely in your ARM case), nothing bad will happen, since it's always
possible to subsequently get the transceiver into reset once the
controller's SPI interface has been re-initialized.
Thank you for this answer. It made me check my pin configuration and so on... and i found a mistake.
Now everything is working perfectly well for SLP_TR without this pull down.
I'm using the "TAL performance test example" and the hyperterminal to debug my code.
If someone can describe me the behaviour after choosing:
"(D) : Transmit a continuous wave pulse on current channel".
How this is normally ending? Is a timer ending the transmission? if someone can tell me one word about this.
> Is a timer ending the transmission?
Yes, I can see a timer there in the sourcecode. If I'm not
mistaken, it's supposed to stop after 50 ms. That's why it
is called "continuous wave *pulse*".
©2014 Atmel Corporation