WP7 App nº3 and nº4 published!!

                           

(Click on the images to download)

Two more apps by the IO team.

The first is a mobfox client, mobfox is an ads provider that we have been using on our apps, and since I visit the site some times every day, I though that when eventually I get a WP7 this will be useful, at least for me xDD. The app shows all your overall and app reports, just like on the website.

The other app name is What’s Close, it uses the google services to fetch places around your current location and shows details of those locations, the rating other people gave them and lets you get directions to that location, this one was made by @Paletas.

Enjoy

My Vandalized View of Mvvm – Lets code

In the last post I gave an overall view into the MVVM pattern, in this I will put my hands to work and give some examples on what I meant.

In the last post I refereed that the MVVM pattern have three main layers, the view, view model and model. When you are coding to Windows Phone 7 (or WPF in general) the view layer is divided in two parts:

• The Xaml, the actual user interface.
• The code behind, code that is associated to behaviors or events of the user interface.

The xaml is just xml, used to define the UI, here is an example:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
  <Button Content="GetBytes"  Name="GetBytesButton"  />
  <TextBlock Name="textBlock1" Text="TextBlock"  />
</Grid>

MPLAB X theme – Pseudo WekeRoad Ink

I decided to share with the world my theme on MPLAB X, since my plays on the AVR32 I’ve started working on a embedded company that uses PICs as is main architecture (yup I’m sick too). This problem aside the IDE that we use to program such devices is the MPLAB X (aka NetBeans), and since I’ve WekeRoad on eclipse and visual studio, I tried to make a clone to this IDE.

Here is the preview:

And the download link

To install just unrar to the folder : C:\Users\{your user}\AppData\Roaming\.mplab_ide\dev\v1.00\config

My Vandalized View of Mvvm

As I said before, me and guys are developing stuff to windows phone and what is the architectural pattern for wp7 applications? Model View ViewModel.

So MVVM came after MVC other very popular architectural pattern and I should try to explain one on the concepts of the other. The MVC uses three distinct layers to separate logic:

• Model – The business layer.
• View – The presentation layer.
• Controller – The one responsible to talk and control the other two layers.

Probably the worst error that I’ve made when studying MVVM is to try to connect or treat MVVM as a sub-pattern or a specification of MVC. So try to avoid compare the both until you totally understand MVVM.

MVVM also uses three layers:

• Model – Same as MVC, your business logic.
• View – The presentation Layer
• View Model – The bridge between Model and View, can also be described as the binder.

So what are the differences? The interaction between view and view model is similar to MVC the views notifies the view model that something happened, like a button click, some text inserted etc,etc. The difference is how the view model talks to the view, the view model never (should) call anything related to the view. As an example in MVC is common to you call the view, controller code like view.showData(data) is normal and acceptable since is the way MVC works. In MVVM the view model updates the view changing its own public properties.

 

With the above image, you probably figure out what is happening. The view binds its the graphic elements to properties of the view model, by doing so, it will receive notifications when those properties changed, updating the view. Consider the follow example:

class ViewModel
{
 public string SomeText{get;set;}
 public ICommand SomeOperationThatChangesSomeText {get;set;}

}
class View
{
 Label label;

 public View(ViewModel viewModel)
 {
   label.Text = Bind(viewModel.SomeText);
   viewModel.SomeOperationThaChangesSomeText.Execute();
 }
}

The value of the property Text in the View is binded to the value of the property SomeText in the view model, now imagine that the command SomeOperationThatChangesSomeText changes the value of SomeText, when that happens the labels property Text will “automatically” change to the new value setted by the command.

As you saw there is no direct interaction between view model and the view, that is nice because it completely separates the user interface logic from the business logic.

Note that this post talks only about the practical terms of mvvm there is much more to it, for more details check out the roots of mvvm in the Presentation Model pattern by Martin Fowler

In the next post I’ll show this concepts using the windows phone platform.

WP7 2º app published

So has I said the second Imagination Overflow App is online!!!

This app was born on my interest to know how the thomson routers default password were generated, so I implemented the algorithm described in here, tried to optimized it so it runs as fast as possible in a windows phone and make an app around that XD. Enjoy

http://www.windowsphone.com/en-US/apps/5073c9da-9b3a-4d36-9ce7-5140c0f7a28f

On the next post I will try to explain MVVM, the architectural pattern that is embedded in the windows phone programming interface.

EDIT: I open-source the implementation of the default passwords algorithm check it out:
https://gist.github.com/1922997

The windows phone playground

So since the last post many things happened, we drop the kinect to a corner waiting for that big idea to come up and became windows phone 7 developers !!!

We all attended the Portugal code camp where we found out what the big fuzz was all about.

Today we have just submitted the second app to the marketplace, more on that later, but first check out our first app, http://www.windowsphone.com/en-US/apps/c7778f6a-de31-4e46-a996-cd5323269ce2
So this long time without posts probably is over since there is much knowledge to shar.

AVR32 Interrupt System and Wrap up

It’s been a while since the last post, this is the last post on the AVR32 4 dummies series because after this one there isn’t nothing to talk about. I decided not to talk about the UC3 peripherals because is standard stuff, UART, SPI, I2C, about the device drivers construction, the reason is the same there are thousands of ways to do it, and I still didn’t found the ideal way to do them.

MOS Interrupt Handling and interrupt thread switch.

In the previous post, I talked about the different ways that MOS has to switch threads, one of them was via interrupt, to do that MOS vector the interrupts via software, by doing this it looses precious time attending interrupt, because every time that an interrupt is signalized MOS  code runs to find out what interrupt it was and if is time to switch threads.

This indirect way to call an interrupt service routine makes the code to configure them portable, meaning that I didn’t touch my Kernel code between architectures, that may seem obvious but I’m very proud of that XD.

Going back to the interrupt thread switch, the MOS common trap (when an interrupt is signaled the CPU jumps to this function) is responsible to arrange things to MOS interrupt handling system. That arrangement is as simple as passing a pointer to pointer to the thread context.  As I said before, the context switch routine and the common trap are directly connected, they store the CPU registers and flags by the same order (so that when a thread is switched back all registers are popped the right way).

Although the common trap is architecture dependent the system common trap is not (it’s writted in C), so the purpose of the common trap is to store the all the registers not saved by the CPU and call the system common trap.
The system common trap simply delegates to the (MOS) interrupt controller the handling of the interrupt. In the middle of the interrupt handling the interrupt controller queries the kernel to check if a thread switch is needed. Remember the pointer to pointer that the common trap saves? The context switch happens by changing the value pointed (by the pointer xDD) to the next thread stack. By doing this when the common trap returns from the interrupt, it will restore not the thread that was running before the ISR but a new thread (how not confusing is this xD).

You can found on github the system common trap and the common trap   (labelled as int0)

UC3 Interrupt Controller

I didn’t make my own irq controller (shame on me), I browsed the Atmel peripherals library and take out the sources to the MOS. The main reason for that was the initialization stuff, and the fact that in UC3 the mask and unmask operations are done directly on the peripheral not on the interrupt controller. So there isn’t much to do, just initialization, ISR configuration and non vectored interrupt discovery.

As I said in one of the previous posts, the AVR32 architecture doesn’t have fixed memory positions for the exceptions/interrupts (being the reset exception the exception xDDD), they all have an indirect location. That locations is given by the Exception Vector Base Address (EVBA). The interrupt handlers and exception handlers have their location fixed in relation of the EVBA value. By having this kind of mechanism you can virtually have your handlers in any location that you want, that is a cool feature of this architecture. So when making your own interrupt controller driver don’t forget to set the evba correctly 😉

Wrap Up

First I apologize for the lack of AVR32 content on this post, the reality is that there isn’t much to talk about about interrupt handling on AVR32, is very simple to understand. I learn a precious thing by not making any kind of device driver, learn how to read and understand other people code, really usually I just go and make everything from the bit on register X to the pretty printf that writes on uart. In embedded world that is an interesting skill to achieve, since in the real world you don’t make all device drivers, you use what you have and most of the time, those were made by people that don’t understand how software is supposed to be done.

I had fun with AVR32, didn’t really like some stuff, like the fact that you can’t mask and unmask specific peripheral interrupts in one place (in the UC3, this doesn’t mean that all CPUs work this way), I liked the many modes of interrupt and the fact that you can individually disable them, but honestly in real world you don’t use just 4 interrupts, you want to map all of them and not care about the interrupt controller.

Finally I’m sad about not liking this architecture, the main reason is the development environment, because all that I tried to this point were horrible, and AVR studio was really a breath of fresh air and astonishing way to program to embedded systems.

The Codebits Experience

The last Thursday, Friday and Saturday probably were the best 3 days I had as a developer.

Me, Sorcha and PaletaS were at codebits making a cool project using kinect, Imaginect, and the experience was just awesome!!!!

Codebits can be easily described as a geeky developer convention where 800 nerds join together on the same spot to code 48h non-stop. But the chosen-ones that have been there know that the previous description is vague.

As a recent developer (+/- 4years) I always knew that in this world there were many fabulous people that have awesome ideas and skills to implement them, but I never thought that being so close to those people would effect me so much. I’m not saying that those 800 people in that place were the best of the best, but being close to so many projects and ideas really stroke me hard.

Whatever I looked I saw great things being constructed, I saw people working with Kinect creating innovative ways to interact with the PC, I saw people using Augmented Reality to create new ways to see the world, I saw people reinventing products giving them news ways to be used, and a lot more.

That kind of environment is really contagious, I always thought that it would be a little overwhelming,  and that showed on the project that we did. Nothing fancy or good, but considering the lack of knowledge on the Kinect SDK and the XNA framework we did something in 48h, namely understand concepts and utilization of those frameworks. That may not seem hard, but when I say understand we really mean understand, not doing something with it XDD.

Imaginect3D were born, the idea? A simple modulation application for developers that don’t really want to understand complicated applications like blender to make simple 3D objects for they game or app. The final application didn’t do much, just a non-physical mouse (kinect style), a simple menu with 4 3D primitives, a way to select them and place them on the world, using voice. But in the process we defined and implemented a way to make rotation and scale just with gestures, that may not seem much but try to define a way, touch-free to rotate a 3D object on all possible axis (x,y,z). The lack of time and experience on making this kind of speed projects were noticed when we didn’t incorporate all the different parts that we develop thorough the project in the final application.

But we have fun, and learn stuff, a lot of stuff and we did win a Kinect XDD, so probably our second try on imagine cup will use Kinect. Imaginect3D is on our github repository check it out.

Where the hell is XML successor?

Today me and some colleges were discussing random stuff as usual, somewhere in the middle someone said something about XML, I  yawn (as always) and a discussion started about my XML hate relationship.

When I learnt XML (2 or 3 years ago) I loved it, it was easy to understand, very declarative and readable. But back in those days I knew nothing about the computer world, I only knew java and C, I didn’t knew what the hell was design patterns, code conventions, pretty code, etc.

When I learnt JSON I didn’t really understand its purpose so it was one more way to send data from one place to another.

Today I’ve a different view on how code and information should look like: namely, simple, concise, easy to read and the most important should be easy to write (low on chars). This last characteristic is probably the most important since its less memory used to save the data or less bandwidth used to exchange data, etc.

At first JSON seems perfect, it’s much more readable than XML and more compact. Then there is the underground MGraph by Microsoft with a really appealing syntax and is more compact than JSON, the problem is its inventor, Microsoft. The hardcore open-source community would never accept using something made by Microsoft so an overall usage would be automatically denied. Finally there is the YAML, my shame in all of this, since until today I never tried to found out what it was.

Let’s see it first, YAML version:

Course:
  Name: Web Programming
  Teacher: ATeacher
  Year: 2011
  Grades:
  - Student: Student A
    Value: 17
  - Student: Student B
    Value: 18

The XML version;

<Course Name="Web Programming" Year="2011">
  <Teacher> ATeacher </Teacher>
  <Grades>
     <Grade Value = "17"> Student A</Grade>
     <Grade Value = "18"> Student B</Grade>
  </Grades>
</Course>

Is it really necessary more comments? No, I fell in love with this new way to show data. Maybe I’m going to make a blog series on this, seems a really nice thing.

YAML have all the characteristics that I enumerated before, people will say that XML will always be here, because things like HTML, config files and schema support. The question is, isn’t XML a bit outdated? Its syntax didn’t get better or evolve with the technology, it’s pretty much the same thing that SGML (invented in the 60s), are we too accommodated with XML? Since when did the computer world stop searching for the best next thing? Think on it.

Resources:

YAML official site
MGraph the next xml

AVR32 First Contact, First Code

So this is the third of the AVR32 4 dummies post series, you can check the other blog posts on:

• The Abstract
• The first discoveries
• The Micro Operating System

I finally started coding some stuff, namely the board startup, the context switch, the interrupt controller driver and the system timer driver. Along the way I discovered more things about the architecture, namely where the AVR32 call convention is documented. The Atmel support, when I contacted them to know about the call convention, forwarded me to the IAR compiler Reference Guide. I loled and checked if my reverse engineering discovers were right (they were).

Before any more comments and discoveries, here it is the overall description on my development board and CPU:

Board: EVK1104:

• CPU : AT32UC3A3256, AVR32.
• RAM: 128Kb.
• ROM: 256Kb.
• SPI: 6.
• UART: 4.
• I2C: 2.
• ADC: 10bits (max resolution), with 8 channels, up to 384 ksps.
• Speed: up to 66MHz.
• 16 bit DAC.
• SD card.
• 256 Mbyte external RAM.
• 256 Mbyte external ROM.
• Touch Wheel for QMatrix.
• 240×320 RBG LCD

Both the board and CPU websites are linked in the previous list, for more information about the EVK1104, download the Schematics and BOM since there is no user manual. The BOM (Bill of materials) have all the hardware used to create a dev board, so it’s the first place where you should go to find out what kind of hardware is “under the hood” or if you want a specific datasheet.

AVR32 Bootloader

A bootloader is a simple program or piece of code that initializes the hardware so that an operating system or application can run. The bootloader can be “called” by the reset event handler or, as usual, be part of the reset event handler. On AVR32 architecture the reset event is the only event that is statically mapped on the memory layout, at the address 0x80000000.

The bootloader present in the Atmel software libraries for my dev board follows the same principles on the bootloaders that I’ve done before for the ARM architecture:

1. Set stack pointer.
2. Set other system required configurations.
3. Load the .data section (initialized variables).
4. Set the .bss section to 0(uninitialized variables).
5. Load .text to RAM (optional, used for better performance)
6. Run the the global instances constructors (c++ only).
7. Call main (or a operating system boot)

The loads are simple memcpy, from one place to another, in most of the cases from Flash to RAM.

I didn’t do my own bootloader for the board, I used one of the Atmel startups and added what I needed, namely the constructors call (MOS is in C++). I did the same for the linker script, I grabbed the Atmel ldscript and corrected some errors on it, again because of my C++ code (on the default linker scripts, although the C++ init arrays are present, the global variables are misplaced and without any change the init and fini addresses are always the same, for more information about C++ initialization check out the previous link of IAR compiler reference).

You can check out the startup and the ldscript via github.

Context Switch

The context switch is the operating system routine responsible for changing threads, this is done by saving the context of the current thread and loading the context of the next thread. A thread’s context is the minimal information needed to represent a thread’s execution state at the time of the switch. The context should be sufficient so that when a thread is switched its previous execution state can be restored and the thread execution continues like nothing happened.
In CPUs without MMU, FPU, etc, the thread context is reduced to the CPU registers, in AVR32 from R0-R15.

MOS has two ways to switch threads:

• By interrupt: when an interrupt occurs the system checks if it is time to switch threads (MOS have a time-slice scheduler), if so the system changes the current thread context pointer (this context is stored on the epilogue of the interrupt and passed to system interrupt service routine) to the next thread context. With this way the context switch only happens when the interrupt returns.
• By thread choice: when a thread doesn’t have nothing to do or is waiting to be signalized it calls kernel primitives like Yield, Sleep or Wait (in synchronizers), this functions can trigger a context switch.

Because of this feature, the two context switch implementations have to be linked to each other. Since the AVR32 interrupt handling automatically stores the r8-r12 registers, the “normal” context switch must save this registers first by the same order that is done on the interrupt. After that it’s needed to save the rest of the registers r0-r7, lr and pc. You’re probably asking why the sp (stack pointer) isn’t saved, the stack pointer is the only pointer that MOS has to know where the thread context is, so the stack pointer is saved on the thread instance, so that further switches can restore the thread context.

I’ve already pushed the AVR32 thread context and the context switch to github, go check it out.

If you check the context switch code, you will see that I don’t store all registers. Actually what I’m doing in some cases is to move stack pointer further down. For instance when the “normal” context switch is called, the caller must preserve all the scratch registers and since the context switch doesn’t use any local variable, I don’t need to store them (they are already stored in the thread stack by the caller of the context switch) so I move the stack  pointer down, saving precious memory accesses.

But when I restore the next thread I restore all the registers, the main reason is because it’s “impossible” to know how the next thread switched (by interrupt or by the normal way) so I simply restore them all.

On another note, the status register is also saved on the context switch, again this isn’t needed when thread is switched using the “normal” way, but when switched via interrupt is mandatory.

Final Comments

When doing the context switch I felt a bit forced to do things the AVR32 way, since the interrupt handling system stores automatically R8-R12 registers into the system stack. So MOS port will not take advantage of the Application mode, and all the code is going to run on System mode. After browsing the Atmel ldscript I felt a little disappointing on the development leftovers that were present and the fact that they don’t even bother to test the CPU that I’m using with C++, I can say this because the global constructors pointers are not correctly configured on the ldscript.
Also, In a previous post I hysterically talked about the status register being mapped on memory, I was wrong, you need to use special assembly instructions to read and write things to the SR.

On the next post I’ll talk about the interrupt handling system, the UC3 peripherals and the device drivers construction.

Feel free to ask any question or comment, see you next time.