ImaginationOverflow

The knowings and experiences of a group of developers.

Category Archives: Uncategorized

Embedded Linux, Boot, U-Boot and SD Card deployment

The process of app making: Business model

Loading more data with a ScrollViewer Behavior

Linux Based Mobile Operating Systems

Introduction to Embedded Linux Systems

We moved out!

Its been a while, but we finally decided to go back on blogging, you can find us on

http://blog.imaginationoverflow.com

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

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.

%d bloggers like this: