Tuesday, October 6, 2015

Should I use ASF?


I have already spent around 20 hours with implementing SPI communication between SAM4S16C and Wiznet W5100. For that I'm using a SAM4S XPlained board and a WIZ812MJ. W5100 is a well-known chip for me, I've already used with ATmega 128 many times. Still, to get it working, I had to power on my old good Tektronix to check the lines one-by-one and go step-by-step.

Here is the story and my first impression of ASF:
So, I've started with a quick research on others opinion about ASF. Those who already have experience with it say that, beginners should start with ASF since it's easier to write some working program with ASF. That's true if you:

  • are happy with the pre-written sample projects
  • don't want to write a program which is more complex than blinking a LED
However, if you would rather do something on your own, questions start to rise immediately which you will rarely find answers for in ASF's documentation.

BTW documentation. Atmel released a series of "ASF - Getting started video". First part available here: https://www.youtube.com/watch?v=r9UFzNEC62E

In this videos they are very proud of that, help and documentation is available directly from AtmelStudio's ASF Explorer. Well, not really.
ASF Doc inside AtmelStudio

Otherwise, the video series is helpful and helps to get a basic understanding of ASF.

Since people are suggesting to start with ASF, I thought, I give it a try. I've setup an ASF project and decided to:
  1. implement USB CDC-stdio  to get an interface which helps me to debug further code
  2. implement SPI between the MCU and W5100

I didn't have any issue with the first objective. I have used the sample implementation and didn't change anything.

Implementing the second objective was much more painful. Atmel provides a so called "Quickstart Guide" for each driver and service. Here is the one for SPI if you want to see. Well, a "Read the datasheet and implement it yourself!" sentence would have been more useful and time saving than the actual content of that guide.

It just doesn't work. It is missing instructions how to assign the I/O lines with the peripheral. Also, no code for sending or receiving data. The example SPI Project is a bit more verbose. Still, it was not enough. Also, for the SPI example they use the deprecated GPIO service (may be for the others too). Since it's deprecated, I didn't want to use it. Instead, I've added it's successor, IOPORT Service to the project. However, I was not able to figure it out how to assign  the I/O lines to SPI with IOPORT service. IOPORT services documentation doesn't say a word about that... Neither GPIO's documentation, however, at least, we can find an example for that in the SPI example project's init.c file Configure SPI pins section. I needed around 15 hours to get the code working. For that, I had to:
  • use an oscilloscope to check the outputs
  • read the datasheet and check the registers
  • kind of reverse engineer ASF to find out what happens in the background.
I have to say, if I would have started implementing the code without ASF, just using the datasheet then I would have finished it earlier.

For the same task(SPI comm. with W5100) I needed approx 2 hours for the implementation on ATmega128 and I didn't need an oscilloscope to make sure the things goes well. 


If you like my post and/or it was useful, please, leave some comment. If you don't, let me know that too. :-)

3 comments:

  1. I'm spending my time on this task now. You saved an hour or probably more of my life by advising to take a look at init.c.

    ReplyDelete
  2. Haha, made the same experience. That's why I'm here ;)

    ReplyDelete
  3. Atmel has always had terrible documentation. Now that Microchip has bought them it looks like they're going to abandon ASF3 and use a graphic configuration IDE. The commercial compilers have had those for years.

    ReplyDelete