Some fun with matlab

I have not been able to do a lot of blogging on this site of late. Procrastination is the reason. Also, I was a bit busy with my project-work ( or the lack of it!!). Here I write about a small script i wrote to convert from mat files to csv files. I searched a lot for existing solutions but alas none was available though csv to mat converters exit in bulk.  While i wrote the script i realized the reason for non existance of such a script.
In Matlab you can store different types of information into a Mat file and some of it might not be easy to represent directly in a CSV file. for example structures cannot logically be put in a CSV file but arrays are easy to convert into csv.
So i wrote a script which can convert mat to csv but with a restriction. The MAT file should not contain any structures or row array's. It can have only column array's. Ofcourse, i know it is simple to change the column to row.

I dont think i can upload a file on to this blog, so till i can put the stuff on esnips this is the only way to share it.:-(


function mat2csv(fname,target)
% MAT2CSV convert a mat file to csv file
% MAT2CSV('matfilename.mat','csvfilename.csv')
% Output is generated using the data provided in the matfile ( one col per data element)
% Unused cells will be filled with zero's
% TODO: Currently the CSV file does not have column names, this will be
% added in next version
if(nargin<2)
    error 'Incorrect Number of inputs. Refer to usage by using "help mat2csv"'
end
y = open (fname);
largest_entry =0;
flds = fieldnames(y);
for idx=1:size(flds)
    eval ( strcat('if(size(y.',char(flds(idx)),',2)> largest_entry)largest_entry = size(y.',char(flds(idx)),',2); end'));
end
eval ('outmatrix = zeros(largest_entry,size(flds,1));');
for idx=1:size(flds)
    eval ( strcat('outmatrix(1:size(y.',   char(flds(idx)),  ',2),', int2str(idx) ,') = (y.', char(flds(idx)), ');')  );
end
fl ='';
for idx=1:size(flds)
    fl = strcat(fl,char(flds(idx)),',');
end
[rc,cc] = size(outmatrix);
fid=fopen(target,'wt');
fprintf(fid,'%s\n',fl);
for idx=1:rc
   for jdx=1:cc-1
        fprintf(fid,'%d,',outmatrix(idx,jdx));
    end
    fprintf(fid,'%d\n',outmatrix(idx,jdx+1));
end
fclose(fid);
end

Powered by ScribeFire.

Faster and Hotter chips!!

I have not been able to blog here due to two reasons. One I got lazy, two is first as the same. Any way now i have woken up from my slumber. This neat article talks about a new 8 core chip ( for servers) from Intel. However, have you ever wondered why suddenly there was a paradigm shift from having faster chips (3GHz or more) to having more cores?

The main reason ( though there might be many others) is the problem of heat dissipiation. Just to give a little bit more information in this regard i will try to go a bit below the layer. The modern chips are all based on CMOS technology. Though most magazines call them as transistors they are really MOSFET's ( which means MOS Feild Effect Transistors). CMOS has this wonderful property that it consumes literally no power when it is holding a logic 'O' or logic '1'. So why the power loss? The power loss really occurs when there is a switching of the CMOS from the logic '0' to logic '1' or visa versa.

This means that more you switch the transistor the more heat you dissipiate. The more heat you dissipate the more cooling need for your chip. Now we are left with two options, either ensure that  we cool the chip well or we reduce the heat generated. To a great extent we can cool the chip by adding bigger fans and heat sinks, however there is a limit to this ( because the heat generated takes a finite amount of time to get carried out and be dissipiated!!). If we concentrate on the second option we observe that if we do not switch the transistors so fast we can control the heating. This is what Intel has chosen to do by not trying to pump up the gigahertz. However, to boost performance now there are two cores ( which run at a slower rate!!) which can parallely execute instructions which are not directly dependent on each other . The story i am sure is more than this and i am not technically competant enough to put in that stuff here. However, someone i know does. I would be requesting him to add a few lines to this blog in a few days.
Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Time Out!!

This question came from a very good friend and ex-colleague. So just responding it via this post which i trust will be useful to others also.

The question

What is a "Cyclic Wakeup Timer"?

The question can be answered if we understand each of the three terms.

We start with Timer. Timer is a hardware or software that keeps track of time via counts. If we know that each count takes say 10ms then we know that 10 counts will mean 100ms. The timer is controlled by its clock which is usually derived from an external crystal or internal PLL circuits.

Next we take Cyclic. It is clear from the word that this shows a repetitive process. The timer runs continuously and maintains time. Which means i can configure a cyclic timer to create an event every 10ms. When 10ms elapses there is a event generated by the Timer (called the timer interrupt by some people). In the event handler we can choose to reinitialize the timer to count for another 10ms. Various configurations are possible, we will not discuss all of them here.

Last part is Wakeup. This is simple, we do this everyday. In this case we are talking about the microcontroller waking up.

To put it all together, a timer that wakes up the microcontroller at periodic intervals is a CWT or Cyclic wakeup timer.

The pertinent question is now, why do we need this?

I can talk only for automotive and perhaps for some other battery powered devices.

Many devices go into sleep mode when they are not doing anything useful, however the periodically wakeup to check if there is something useful to be done. I quote a few examples :

• A PKE ( Passive Keyless Entry) system might wakeup periodically to see if there is a key in the vicinity of the vehicle. If there is then it automatically unlocks the door. (Note: It is technically quite challenging and complicated)
• A BCM ( Body Computer Module) needs to wakeup periodically to check for monitoring certain inputs.However, this is usually because multiple external events might try to wakeup the ECU but there might not be so many interrupt pins available. 
• I know of a system which used to maintain the time. The system would go to sleep and wakeup every 1 sec to update its time variables. Only when the vehicle was on the system would display the time else it would go to low power mode and wakeup only every 1 sec.

As you can see that the CWT is quite useful. However, it might be a tough job to handle the CWT along with other wakeup sources which try to interfere with its operation.

Hope this clears my buddy's query...

Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

 

Powered by ScribeFire.

Let Us Model

I am not really an expert in this domain. I switched companies about 3 months back and with that i also changed my working area to some extent. Now instead of writing code i model it.

Why does one need to model code?
The reason is that model acts like a common language between the coder and the provider of requirements. However that is not the only reason. Most of the Modeling languages these days provide a mechanism to directly convert the model into code or partial code.

Simple cases:

• UML modeling: These days many if not all commonly used high level languages are object oriented. UML provide a very nice method to model the system in terms of classes, packages and their interdependencies etc. There are free and paid tools that are can directly convert from UML models to skeleton code.
  
• Simulink modeling : Simulink is a very powerful tool available from mathworks. The tool provides you simple gui based interface to create models. These models can be fed with inputs and then the corresponding outputs can be tested for their validity etc.

In the automotive domain currently, Matlab is used very often for verification of complicated algorithms. Once the simulink models are tested extensively, then it is possible to automatically generate floating point code using RTW and Embedded Coder. This code can be directly flashed into controllers which have sufficent floating point muscle power be used to verify the functionality in the real hardware. However, more often than not, floating point muscle power comes at a heavy price and is not preffered for production programs.

So what is the next step?

You got it right!! Convert the floating point code into fixed point code. The fixed point code can run faster on simple µC's. Caution: Note that all processors are capable of doing floating point operations however, in simpler micro processors there is no dedicated hardware unit for doing this. Which means that this has to be done in software which is time consuming and memory consuming. Some processors like PPC are capable of doing this in their hardware
---------------------------------------------------------------------------------------------------------------------------
— Floating point
– IEEE® 754 compatible with software wrapper
– Single precision in hardware, double precision with software library
– Conversion instructions between single precision floating point and fixed point
---------------------------------------------------------------------------------------------------------------------------
Excerpt from PPC mannual.

Obviously we have to understand that due the limitations of the fixed point code there will be resolution error also called quantisation errors. Based on how we choose our scaling ( will talk about this later) we can ensure minimal quantisation errors. Of course, note that fixed point code is not really all that fast but ofcourse faster than floating point code ( slower than unscaled code!!) .

To conclude, these days quite often the system engineers etc use the simulink models to develop their algorithms while software developers work on the simulink models as inputs and create the fixed point code that goes into the ECU.

Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Where does it run ?

This post comes in the wake up some discussions i had with few people working the embedded domain a few days back.

The question was, where exactly does our code in the micro controller run? The answer again unfortunately is not so straight forward. The reason is because different micro controllers behave in different ways. Let us therefore try to understand how the whole process works so that we can judge it better.

Frankly, the micro controllers at its core are just a bunch of registers on which a few mathematical operations can be done by another piece of hardware ( part of the core) called the ALU(Arithmatic Logic Unit). Most of the micro's thus have a Accumalator(Acc). This is like the mother register and most of the operations (mathematical or logical) will use the Acc register (There are instructions that do not involve the Acc also. like mov H,L does not involve the Acc). To ensure that some instrucution is executed, it must be first fetched, decoded and only there can be some action. To fetch an instruction, it should be readily available. Readily is a fuzzy word here because what is readily on 8Mhz system is really too slow on a 1GHz processor. The readiness depends on how fast we can read the said instrucution. The simplest micro controllers like 8051 keep the instructions in their flash memories. These are accessed by the core and then executed. Some industry folks call this as "Executing from the Flash".

Modern micro's have the concept of cache. This means they will pre-fetch and keep some of the instructions in a faster re-writeable memory. The core thus will use the cache to read the instructions instead of reading from the flash. Crude and simpler implementations of cache are in the form of instruction queue etc. These don't have the capabilities of the cache memory but never the less helps in making execution faster. So, now the instructions are stored in flash, but executed really out of cache memory.

Some micro controllers also provide a wonderful feature where in the instructions can be stored in the RAM. This is generally done while reprogramming. More about reprogramming will be there in future posts. Here the real program resides in the flash memory but one can copy the program to RAM and then set the core to fetch the instructions from the RAM instead of the flash.
Some folks call this "Execution from RAM".

The fact is that most modern micro's can read instructions from both Flash, Ram or in some cases even from communication buses (like CAN/FlexRay). The last part is tricky one and will be discussed in some other post ( because i have to get more information on that yet).

My take is this, all code gets executed in the core. All that can vary is where we are fetching it from.


Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Thin in In

I am not putting up too much except this link. It talks about a new age of speakers which use thin films. This means that you can really get rid of those huge speaker boxes. As before it is sometime before one can see these in production.

Wanna
add your point or provide more info ? Please leave your comment. You
can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.