|
|||
| home | track record | |
|
|
d |
|
(Modified:
March 2011) The
projects are listed in reverse chronological order. Embedded systems
consulting
(Nov 2006 – in progress) 1.
Volvo
3P
(Oct 2010 – present) ·
Deployed
from the System Architecture department to a project role as Technical Leader support.
The work involved keeping track of progress within the sub project team and
working with cross-team issues within the total project. Also system
investigations were performed. 2.
Saab
Microwave Systems, Gothenburg
(Nov 2008 – Oct 2010) ·
Development
of distributed power solutions as schematic reuse blocks and also complete
power solution on PBA's. The work involved design of filters, switched and
linear voltage regulators, DC/DC-modules, power budget, thermal calculations,
on-board current and voltage measurements, supporting circuit solutions for
ADC, enable signals etc. Other tasks included verification of power units,
PBA's and practical trouble-shooting. 3.
Saab
Microwave Systems, Gothenburg
(Feb 2008 – Oct 2008) ·
Maintenance
of a radar simulator. The background is that the previous competence &
knowledge had left the company. The work involved trouble-shooting, maintenance
and development of the simulator. The radar simulator consists of a VME crate
with a SPARC and several DSP boards. The maintenance work consisted of building
software able to run on the target machine with old libraries, backing up hard
drives (clone), documentation of the development environment etc. 4.
Ericsson
Mobile Platforms, Lund
(Nov 2006 – Feb 2008) ·
Analyzed
and implemented customer originated Error Reports and Change Requests on core
platform functionality, e.g. mixed signal ASIC driver, battery charging, file
system, NAND driver, error handler, MSL-link, DMA, dump analysis. ·
Involved
in customer projects. Responsible for integration of customized software
modules and building of customer phone software for delivery to customer. The
work consisted mainly of trouble-shooting compile and link errors. M2M-system
(Feb 2006 – Oct 2006) 1.
Introduction
This
project is an addition to the Climate
control system described further down. It is connected to the CAN bus of the Climate
control system. 2.
Description
This
system introduces ARM7 and 32-bit MCU’s to the company. The system
consists of a GSM-module, a bunch of other UART’s, temperature sensors, digital
inputs, two CAN interfaces. The purpose of the system is to connect the Climate
control systems in the trucks with a web server and the standard CAN bus of a
truck and it also adds GPRS-communication to the previous generation of the Climate
control system. The web interface mainly provides the means to show logger data
and geographical position of the trucks. It also gives fleet managers the
ability to remotely perform other tasks such as changing system settings.
Another important function of the M2M-system is to deliver temperature alarms
to the central web server. The application had to be modular because of the
different contexts this system will operate in. As mentioned the system also
need the ability to connect to an older climate control system which does not
have a CAN bus nor the same logger format. It must also be able to operate as a
stand-alone telemetry system. 3.
Responsibilities
My main
tasks were to write the customer specifications, design the architecture of the
system on a system level and do all implementation. Other tasks were dealings
with the M2M/GSM operator and with the company that provides the web server
functionality. 4.
Experiences
4.1.
GSM-module
communication
Having no
experience in this technology it was a bit of a challenge getting it right. I
had to make a parser for AT commands, specify the protocol for the data layer
and at the same time implement my own web server to be able to test it all out. 4.2.
Data
layer protocol
The
M2M-system on the data layer operates in the role of a server. A protocol was
specified for the communication with the web server. This protocol had to be
generic because the M2M-system will also be used by our customer in other
contexts. 5.
Value
Some technical
experiences gained:
Modifications
of an MSSQL report application
(Jan 2004 – Mar 2004) 1.
Description
For a short
while I was on loan to a company that sells software consulting services. They
were selling consulting services to a nuclear power plant. The application we
were working on was a report system that collects data from SQL databases and
creates different types of reports. The GUI
is a Visual Studio C++ DLL which is called from Origin (a scientific graphing
tool). 2.
Responsibilities
Changing
the GUI and adding new functionality. Changing the layout of the reports and
adding new data to the reports which are generated in Origin. 3.
Value
This
assignment introduced me to Visual Studio programming, SQL databases and more
advanced features of version control systems. I have since then been
programming in Visual Studio C++ and setting up SQL (MSSQL, MySQL) databases in
my spare time. Climate control system
(Mar 2003 – Feb 2006) 1.
Description
The
customer of this system manufactures automotive climate control systems. These
are mainly put into your average truck delivering groceries and what-not. These
climate control systems are very complex in terms of hardware configuration as
they are modified for different customers. This puts high requirements on the
embedded system controlling them. The embedded software is basically the same
but also very different and this leads to the requirement of a highly modular
system. The
system consists of one or several main computer boards connected via a CAN bus.
The number of boards required depends on the customer’s system. The
computer board is equipped with what to expect from a control application;
digital inputs, analogue inputs, relays and a multitude of Flash memories (e.g.
data logger, user configuration settings). The physical dimensions of the board
allows for 8 relays. For some applications the number of required relays
exceeds 8 by far so up to two additional computer boards are required. This
system also comes with a Windows application. This is used to download new
firmware over the CAN bus, reading logger data, reading application settings
from Flash and other tasks. It can also simulate the control panel’s
graphic display by running its HC12 code. It simply connects itself to the CAN
bus via our RS232 to CAN converter. To handle
these situations it is required that the OS messaging API is transparent as to
where a certain OS task is located. Task B is located either on the same board
as task A or on a different one. It is all the same to task A where task B is
physically located. The application programmer must however take into account
the data throughput rate. 2.
Project
setup
Five people
have been involved in this project. I and two others were the software
‘core group’. One of the other two wrote the OS himself as no OS
supported the banked memory architecture of the platform. The second of the two
coded the display control panel application. The display is located in the
truck drivers cabin and is connected to the CAN bus. As for
myself I coded most of the drivers and the main application. The remaining project
members designed the data logger and the hardware. 3.
Responsibilities
In 2004 the
other two of the core group left the company leaving me to deal with the incomplete
display control panel which heavily added to my duties. The main application
design was still not complete and I was the one to design and implement it. The
customer specifications of the functionality were continuously being altered. I
also wrote the specifications because they were always given verbally over the
phone and was always ambiguous and lacked information necessary to implement
them. This required a lot of guessing and putting oneself in the customer’s
position. The
Windows application was also added to my responsibilities. The
software release planning, releases, version control and issue/bug tracking are
other functions that I introduced, developed and was responsible for. 4.
Experiences
4.1.
Prototype
start-up
When I
first started working at the company I was put in charge of testing the first
prototype of the computer board. I wrote test code for all the peripherals,
modified the CPLD code for the banked memory architecture, patched the board
etc. The usage of oscilloscope and logic analyzer was quite extensive as almost
all peripherals were external; ADC, CAN-controller, RAM, Program Flash, other
Flash, RTC and the peripheral MCU. 4.2.
The
drivers
Some of the
drivers I designed and implemented:
4.3.
The
application
As
mentioned in the description the application had to be modular. The application
is built up by several tasks and every task is built up by several function
modules that can be either removed or exchanged depending on the physical
real-world configuration of the customer’s control system. 5.
Value
I was
really put in the heat straight away. This was my first job after university
and my education was focused on ASIC design and not on embedded systems.
Working on this project gave me a lot of knowledge about every aspect of
embedded systems design. I also
gained knowledge of EMI related issues through diagnosing problems out in the
field. Some technical
experiences gained:
Some soft
experiences gained:
|