Tuesday, October 6, 2015

The first post

Hello All,

For some reason I decided to start a technical blog about sw development for Atmel's SAM4S MCU. In my first post I would write a few words about myself and my motivation.

About me: I'm a software developer who works mainly with high level languages such as C# and Java. I just started to learn C also I've never worked with 32bit MCUs, so, this blog is going to be a beginners blog in this regard. In the other hand, I have 6 years experience in software design also have experience with Atmel's mega family which means, I'm not completely newbie for the topic.

As you may already noticed my English knowledge is still on a low level, I'm sorry about that. However, I think I can share here useful content with those who are interested in SAM4 development. That's why started it, regardless the lack of English skills. Since literature is out of scope here, I think that's not a big issue.

Why did I start this blog:
Internet is full with tutorials and working examples for AVRs. A significant part of my AVR related knowledge derives from the net. I thought that I will find a similar community, a similar support for SAM controllers too. Well, I didn't. I've found a bunch of forums full with unanswered questions. When there are answers for the questions, they are rarely accurate or complete so the quality of them is questionable.

Atmel provides nice sample projects which usually work out of the box. Almost all sample project for the SAM evaluation boards based on Atmel Software Framework (ASF). This framework supposed to hide the low level register operations and provide a higher level API. Such a framework is a very good initiative. However, the documentation of this framework is almost useless which results in a useless framework. Even if I have a good framework, it is useless if I don't know how to use it.

Anyways, it was much more harder to implement even a simple SPI communication in master mode compared to AVR because of the poor documentation of the framework and because I tried to collect the necessary knowledge only from the forums. Finally, I realized that this approach just wont work now. I have to actively use the datasheet and understand all the registers. Yes, I know, that's the right way. If somebody want to create something using an MCU, she/he should know the device well. But then what is the point of a framework (pushed hardly by the manufacturer) which tries to hide the chip?

So, I decided to document my way of learning SAM4, more specifically SAM4S16C. I will share with you my experiences and provide with use-cases and code snippets.


Regarding the methodology:
I've started working on a (hobby) project which involves a lot of technology I don't have (much) experience with. I'm going to implement a Building Automation system, which for I need a central device with a relatively cheap but fast processor. This system is also out of scope of this blog (just like literature), however, all the necessary knowledge needed to implement the firmware of that device will be documented here.

That will involve:

  • SPI communication
  • UART communication
  • interrupts
  • external RAM
  • TCP/IP communicaton (using W5100)
  • RS-485
  • ZigBee with XBee®
  • etc


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

2 comments:

  1. Hi! I am currently in this exact situation right now. I am fairly experienced in AVR development but grasping at straws when it comes to SAM (ARM). I have read numerous articles including yours that ASF is something you would only go with if i do not plan to deviate much from the sample code, which we all know is very limiting.

    As somebody who came from AVR moving up to SAM, how to you propose one should go? Are there any tutorials you previously used that I can follow?

    Also, do you plan on writing one? ;)

    Thanks, and have a great day!

    ReplyDelete
    Replies
    1. Hi Mark!
      My opinion changed a little bit since I wrote this post. I think ASF is the best choice for beginners, but only if you have an explained demoboard. I strongly recommend to spend some time experiencing an explained board and the sample projects. Study the source code and do some trivial changes to it and see the result. You wrote that you have experience with AVR. Then, I suppose you have some AVR boards laying around. Implement some basic SPI or UART communication between them. I think ASF is very good initiative and most of the source is well written, however, it contains strange things too. What you need is patience and the datasheet of the SAM you are working with. You have to know well the registers of the MCU even if you are using ASF. Sometimes you need to check what ASF does in the background, you need to check the source of the given ASF function and check what registers being modified by the given function to understand how is it working exactly.
      I'm working on a project where I use ASF, I can recommend it.

      There is another thing which may helps deciding this ASF question. I don't know if you heard about it, but Microchip has acquired Atmel which could have a major impact on ASF and on Atmel's MCU portfolio. I'm not sure if it is a good idea to learn and use a technology which's future is unpredictable.

      Delete