Re: spi_sam3x/cc2520 of zephyr


Tomasz Bursztyka
 

Hi,

Meanwhile, I also find that, cc2520 driver is submitted, but it is
never validated.
What do you mean by "validated"?


SPI:
==> spi_sam3x_transceive can not return, and result in system exception
==================================================================
GPIO and SPI configured
verify_osc_stabilization enter
***** BUS FAULT *****
Executing thread ID (thread): 0x20080d04
Faulting instruction address: 0x80480488
Instruction bus error
Fatal fault in essential task ! Spinning...
===================================================================
==> Receiving data cannot occur without transmitting data.
SAM3X[DATASHEET]->32.7.3 Master Mode Operations
==> spi internal nCS may be unusable, instead of it with gpio.
==> it is better to transmit and receive data in fiber context.
Well, I can't find any driver about sam3's SPI on latest master tree.
Are you working with some patches not up-streamed or?
I really would like to take a look at such SPI driver.
cc2520 relies at 90% on SPI. Most of the time, bugs have been found on
SPI side.

And something tells me spi_sam3x_transceivec is not properly implemented.

cc2520:
==>fifop(gpio2) triggers rx processing at rising edge, sfd(gpio4)
triggers tx completion notification, should it be falling edge?
That's all about arduino_due GPIO specifics. In quark_se_devboard that's
rising edge.

==>linux cc2520 driver is very concise and clear, why don't port it to
zephyr?
Sure, because a driver from a totally different OS will just do the trick?

==>cc2520 driver defines macro
"CONFIG_NETWORKING_LEGACY_RADIO_DRIVER", if this means how to
interface cc2520 to zephyr 6lowpan stack still is a uncompleted task,
or the interface will be changed in future.
You don't have to care about that. That's internal stuff, which
application will never ever have to deal with.


Here I greatly appreciate huge contribution from Intel colleagues.
I specially care for spi_sam3x <==> cc2520 driver <==>
6lowpan/ieee802154 <==> ipv6.
To achieve this target, Would you have any information about its, plan
or schedule?
We don't have plans ourselves in porting cc2520 to arduino_due.
It seems to me you are actually doing that yourself right?
cc2520 has been, for now, ported to quark_se_devboard and works well there.

However: this means providing the proper GPIO and SPI configuration.
This all goes through boards/arduino_due/<bfoard.h/board.c and Kconfig>
in your case.
Have you done that? Take a look at same files in boards/quark_se_devboard/

Do you have any patch to show so I can help you with the porting process?

Tomasz

Join devel@lists.zephyrproject.org to automatically receive all group messages.