Balancing Low-Level vs.

High-Level Programming
Knowledge in an Undergraduate Microprocessors
Course
Mohammed El-Abd, SMIEEE
Electrical and Computer Engineering Department
American University of Kuwait
Salmiya, Kuwait
melabd@auk.edu.kw

Abstract— In this work, we address the issue of balancing
low-level vs. high-level programming knowledge and experience
in embedded systems courses. On one hand, low-level
programming (i.e. Assembly) is important for the students to
fully understand how the machine works and have full control
over its different capabilities and hardware features. On the
other hand, high-level programming experience (i.e. C/C++) is a
must to cope with recent industrial and embedded market trends.
We aim to investigate one teaching approach that could be used
to adequately deliver both learning experiences in an
undergraduate microprocessors course. Sample lab sheets and
assignments that demonstrate the proposed approach are
presented. The approach is tested over two consecutive semesters
and both students’ feedback and performance are used to
evaluate the proposed methodology.
Keywords—microprocessors; engineering education; embedded
systems; low-level programming; high-level programming;
teaching methodology; laboratory component
I. INTRODUCTION
Embedded systems in the engineering discipline refer to
systems that are built around and operated by a computing
entity. The controlling computing element could be a
microprocessor, a microcontroller, a Field programmable Gate
Array (FPGA), or a Digital Signal Processor (DSP). This
ubiquitous concept currently spans more applications than
anyone can imagine. Such applications range from household
appliance and office equipment, home automation, to the
automotive industry and beyond.
A final computer engineering curriculum model was
completed in 2016 by the joint ACM/IEEE task force [1]. In
this model, the embedded systems knowledge area is
comprised of 40 core hours. This knowledge area covers many
topics including, but not limited to, software design, digital
interfacing, analog interfacing, and mobile and wireless
embedded systems. This number of core hours is double the
number of hours allocated for the same knowledge area in the
2005 curriculum. In addition, some areas were minimized in
favor for expanding system on chip (SoC) and embedded
systems. This decision is a reflection of directions to which the
engineering practice has been heading in the past decade.
One of the areas of scope for embedded systems in the
model curriculum clearly states “Embedded systems software
design, either in assembly language or a high level language or
both, for typical embedded systems applications using modern
tools and approaches for development and debugging.” This
statement indicates that software design using low-level
programming language only (i.e. Assembly) is considered
sufficient. However, recent industrial trends in embedded
applications, which were revealed by the 2017 embedded
market study [2] conducted by EEtimes and Embedded.com,
shows that approximately 82% of embedded applications are
currently implemented in higher level languages (C, C++, C#,
and Java). This is not to mention other software tools like
MATLAB or LabView. On the other hand, only around 4%
are implemented in Assembly. Moreover, 81% expressed the
intention to use the same higher level languages in their
upcoming projects while only 2% selected Assembly. The
study concluded that C is still the most dominant used language
(at 52%) with no challengers.
The programming languages ranking, shown in Fig. 1,
provided by the interactive IEEE Spectrum tool [3] is another
measure of the importance of different embedded programming
languages. This interactive tool combines data extracted from
12 different websites to produce the shown rankings based on
different settings. For example, to produce the Job Ranking,
more weight is given to job-postings websites like
CareerBuilder and Dice. The ranking places C and C++ ahead
of Assembly for the most sought after languages in the
embedded market. To produce the Open Ranking, more weight
is assigned for data extracted from source codes sharing
websites like GitHub and Stack Overflow. Again C, C++, and
also Arduino are ranked higher than Assembly. To produce the
Spectrum Ranking, more emphasis is placed on data extracted
from IEEE Xplore. Such a ranking shows that C, C++, and
Arduino are getting more popular among academicians and
researchers as well. Finally, to produce the Trending Ranking,
more importance is given to websites like GoogleTrends,
Reddit, and Twitter. This again illustrates that C and C++ are
placed higher than Assembly while Arduino closely follows.
Note that Arduino still presents a platform for higher-level
knowledge with its C-like programming language.

978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 268
 These strong statistics clearly pose an educational dilemma.
On one hand, it becomes a necessity to teach embedded
systems courses using C/C++ to cope with recent industrial
trends. On the other hand, the students cannot fully understand
what’s happening and might not have full control over the
hardware without low-level knowledge and experience. In our
opinion, the more experience current students have with low-
level programming, the more efficient embedded applications
would be when developed by future engineers using high-level
languages.
Fig. 1. Different rankings of embedded programming languages in 2017
provided by the IEEE Spectrum interactive tool.
In this work, we aim to identify an appropriate balance
between low-level and high-level programming knowledge
delivered in an undergraduate microprocessors course. In our
engineering program, “Microprocessors and Interfacing” is a
three credit hours third-level core course acting as a pre-
requisite to the capstone project. In addition, there is a co-
requisite one credit hour laboratory component. The
microcontroller adopted for the course belongs to the
Microchip PIC midrange family. Selecting the PIC
microcontroller for this course is driven by the fact that it is the
most dominant technology in the market among the available
978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 269
8-bit microcontrollers [2] since 2014. Moreover, the same
study shows that Microchip and Arduino constitute 11.5% of
development boards used in starting an embedded design.
The rest of the paper is divided as follows: Section II
explains how the current issue under investigation was
approached before. The new approach is explained in Section
III. Section IV presents the study results. Finally, the paper is
concluded in Section IV.
II. HISTORY OF THE COURSE
In our computer engineering program, which started in
2010, “Microprocessors and Interfacing” is a three credit hours
third-level core course acting as a pre-requisite to the capstone
project. In addition, there is a co-requisite one credit hour
laboratory component. The learning outcomes of the course
include understanding the internal architecture of the PIC
microcontroller, writing assembly programs covering different
addressing modes, performing input/output operations,
studying different interfacing techniques on the hardware and
software levels, using the PIC’s interrupts and timers features,
covering multiple subjects including signal conversion and
serial/parallel communication, and the ability to design and
implement a microcontroller application. As for the laboratory
component, learning outcomes cover implementing all what is
learned in class using MPLAB-X [4] and the available
microcontroller hardware kit. As illustrated by the course
learning outcomes, the main orientation of the course was to
use the Assembly language.
At first, the project component of the course was handled
using the Restricted approach, which means that all students
were to implement the same project using the same technology
(The PIC microcontroller studied in the course). However, in
2012, a decision was made to switch to the Free approach,
which means that students have the freedom to select their
project topic and the adopted technology. The new approach
gave the students the chance to work on projects they are
passionate about using the technology they are more interested
in. Furthermore, in-class presentations exposed each student to
a wide range of applications implemented by other class mates.
Another advantage is that some of the students continued
working on their class projects towards their capstone courses.
Finally, such a decision was also taken to foster the students’
long-life learning abilities. A major advantage of this approach
was the implementation of a number of interesting and creative
projects. Furthermore, the students’ exposure to this
technology in such a setting has subsequently improved their
performance in capstone courses [5, 6].
A side benefit that resulted from this switch is that students
gained some high-level experience as well. As the students
were obliged to implement the project component of the course
using a different microcontroller, than the one studied in the
course, of their choice and using the programming language
they prefer, almost all students opted to use the Arduino
microcontroller and its C-like programming language. Arduino
being the dominant choice was due to several reasons including
its low cost, adoption of the open-source philosophy,
 TABLE I. COVERED TOPICS IN THE LABORATORY COURSE.

Lab
Covered Topics C Questions
Sheet
An introduction to MPLAB and the PIC Instruction Set. This set of lab sheets is mainly focused on writing, debugging,
1-3 x
and simulating Assembly language programs using MPLAB-X.
PIC Input/Output capabilities. Starting with this sheet, students will begin downloading their Assembly programs to the
4 ¥
hardware kit and running them in real-time.
Software generated time delays (dummy loops and nested loops), Time delays calculations and adjustment, Square-
5 ¥
wave generation and Interrupts (external and on-change).
6 Keypad scanning and relevant applications. ¥
7-segment displays (conversion to 7-segment format and multiplexing multiple displays) and LCDs (communication
7 ¥
with the onboard LCD display using I2C protocol).
Timers, Hardware generated time delays, Time delays calculations and adjustment, Square-wave generation and
8 ¥
Interrupts (Timers overflow).
9 Motor control, DC motor speed control using pulse width modulation and Stepper motor position and speed control. x
Data conversion (using the onboard ADC chip when interfaced with potentiometers, a pressure sensor, or a temperature
10 x
sensor).

availability of online resources, and ease of expandability. All
these properties make Arduino a suitable choice for
implementing a fully-functioning project in less than two
months, a period dictated by the fact that the course is
delivered in a single semester.
However, with the availability of many online resources, it
becomes more difficult to identify the students’ contribution
and measure their true understanding of the acquired high-level
knowledge [7-9]. One solution to overcome this challenge was
introduced in [8], where the student assessment scheme was
based on a deliverable document in which the student clearly
distinguishes his/her contribution from used resources.
The work in [10] provided a comprehensive survey of how
Arduino was adopted in embedded systems education. Several
research directions were proposed; one of which was how to
balance the low-level and high-level programming knowledge.
As indicated by the recent market trends highlighted earlier,
it becomes a necessity to develop different teaching methods to
appropriately deliver both low-level and high-level knowledge
for students. Although the use of Arduino by many students in
their projects has contributed to that direction, this approach
suffers from a number of shortcomings:
x The actual knowledge gained by students cannot
be directly controlled and/or measured,
x The knowledge gained by students is not
consistent, different from one group to another, as
students are implementing different projects,
x The comparison between low-level codes
(implemented in the course and lab) vs. high-level
codes (implemented in the project) is impossible
as they are targeted for different hardware
platforms (PIC and the project hardware).
III. THE LABORATOY COURSE
A. The Proposed Approach
The laboratory course provides a natural venue for
achieving the goal of our study and addressing the
shortcomings explained in the previous section. In addition to
using Arduino in the project component of the course, high-
level language knowledge will be delivered through the co-
requisite laboratory course as well. The laboratory course
includes 10 lab sheets that cover multiple topics as shown in
Table I.
The current set of experiments and laboratory activities
provided to students are written in Assembly and targeted for
the PIC16F84A microcontroller. The students use MPLAB-X
to write, debug, and simulate their programs. Students also
download there programs to the available hardware kit to run
their codes in real time.
As a transitional modification stage, the report sections of
the lab sheets are updated asking students to repeat selected
experiments using the C language. We provide the students
with sample C codes and ask them to either complete the codes
or modify them to re-implement the laboratory experiments
previously implemented in Assembly.
We believe that such an approach, along with using
Arduino in the course, has a number of advantages:
x Students will understand the strengths and
weaknesses of both programming paradigms
(Assembly and C) as they apply both to the same
set of experiments on the same hardware (PIC),
x The instructor can easily assess the students high-
level knowledge using their submitted reports
and/or exams,
x Students could be introduced to the concepts of
compiler code optimization by comparing their
own low-level code and the low-level code
generated by the C-compiler,
x The students’ knowledge is clearly expanded by
experimenting with two different microcontrollers
(PIC and the project hardware) and two different
programming paradigms (Assembly and C) in the
concurrent course and laboratory.
B. Sample Codes
Starting with lab sheet 4, the report section at the end of the
lab sheet (to be submitted before the next lab session) is
extended with questions asking the students to repeat the lab
exercises (already implemented in Assembly during the current

978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 270
lab session) using the C language. The students are provided x The explicit statement placing the interrupt service
with one sample C code that they are asked to extend for routine at address 0x04 is not needed in the C
implementing other exercises. The students utilize the XC program,
compiler [11] available under MPLAB-X, so they are basically x The direct access to bits using their names (i.e.
using the same IDE. INTF, GIE, and INTE) without explicit reference
As an illustration, Fig. 2 presents a sample Assembly code to the register(s) they belong to as in Assembly
(i.e. INTCON),
provided as one lab activity for implementing a simple output
x The definition of new bit names as in TRISB0,
operation. As shown, the code is an introductory level code
x The use of the interrupt keyword in the C
with comments that explain the purpose of each instruction.
language to define the interrupt service routine
The report section provides the students with a sample C code,
that would be automatically placed at address
shown in Fig. 3, which implements the same function. 0x04.
ORG 0x00
BSF STATUS, RP0 ; Go to bank 1 ORG 0x00
CLRF TRISB ; Set PORTB all outputs GOTO MAIN
BCF STATUS, RP0 ; Go to bank 0
MOVLW 0xFF ; W = 0xFF ORG 0x04
MOVWF PORTB ; PORTB = W GOTO ISR
LOOP COMF PORTB ; Complement PORTB
GOTO LOOP BSF STATUS, RP0
END CLRF TRISA
BSF TRISB, 0
Fig. 2. A sample output capability Assembly code. BSF INTCON, GIE ; Enable Interrupts
BSF INTCON, INTE ; Enable External
Interrupt
#include <htc.h> BCF STATUS, RP0
#define _XTAL_FREQ 4000000
LOOP CLRF PORTA
void main() GOTO LOOP
{
TRISB=0X00;
PORTB=0XFF; ISR BCF INTCON, INTF ; Clear Interrupt Flag
COMF PORTA
while(1) RETFIE
{
PORTB = ~PORTB;
}
} Fig. 4. A sample interrupt capability Assembly code.

Fig. 3. A sample output capability C code.

#include <htc.h>
Providing the students with these two sample codes will #define _XTAL_FREQ 4000000
help them identify the following differences:
void interrupt isr()
x The infinite-looping structure of embedded {
applications (the LOOP … GOTO LOOP in INTF = 0;
Assembly vs. while(1) in C), PORTA = ~PORTA;
}
x The bank switching necessity in Assembly to
appropriately setup the port is not explicitly done void main()
in C as it becomes the job of the compiler. {
x The availability of a port complementing TRISA= 0x00;
instruction in Assembly which is implemented TRISB0 = 1;
using the complement operator ~ in C. GIE = 1;
INTE = 1;
A different example for lab sheet 5 is shown in Fig. 4,
while (1)
which presents a sample Assembly code provided as one lab {
activity for experimenting with the interrupt feature. The report PORTA = 0x00;
section provides the students with a sample C code, shown in }
Fig. 5, which implements the same function. }
Providing the students with these two sample codes will
Fig. 5. A sample interrpt capability C code.
help them identify the following differences:

978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 271
 Moreover, students can compare the Assembly language
programs generated for the provided C programs to the
programs written directly in Assembly. For example, the
Assembly program generated using the XC compiler, for the C
code in Fig. 3, is shown in Fig. 6 below.
Fig. 6. Assembly listing for the sample output C program.
From the given Assembly listing of the simple output
program, students can identify the following:
x How the C compiler translates the while loop into
instructions at lines 1021 and 1021 that are
exactly similar to the Assembly code LOOP part
in Fig. 2,
x How the C compiler translates the ~ operator into
the COMF instruction at line 1021.
x How the C compiler only switches banks when
needed. This results in having the order of
instructions at lines 1018 and 1019 different than
in the Assembly code.
x How the C compiler handles the reset vector
(highlighted with an arrow at address 000) by
jumping to line 3FE in which it clears the status
register and jumps to the beginning of the code at
line 3F7.
x How the C compiler ensures that the code will
always be running (even without the while loop)
by having the GOTO instruction at line 1024.
The Assembly program generated, for the C code in Fig. 5,
is shown in Fig. 7 and Fig. 8 below for the main and isr
functions.
Fig. 7. Assembly listing for the sample interrupt C program – main function.
978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 272
Fig. 8. Assembly listing for the sample interrupt C program – isr function.
From the given Assembly listings of the simple interrupt
program, students can identify the following:
x How the C compiler translates the main function
into the code in Fig. 7, which is exactly similar to
the original Assembly code in Fig. 4,
x How the C compiler translates the ISR code into
instructions at lines 012, 013, and 01E that are
exactly similar to the Assembly ISR code in Fig.
4.
x How the C compiler automatically generates the
code needed for the context save (not shown) and
the context restore (lines 014 to 01D).
IV. RESULTS
A. Students’ Feedback
The proposed methodology was tested in two consecutive
semesters during the academic year 2016-2017 with classes
having a total of 58 students (71% females and 29% males). At
the end of each semester, the students were presented with a
survey to collect their feedback. Questions of the distributed
survey are shown in Fig. 9. Survey questions are designed to
receive the students’ response regarding the new lab sheet
questions while giving them the opportunity to suggest
promising modifications or provide further comments.
The approach relied on the students’ previous experience
with Java as a basis to easily introduce the C language into the
course. The reason for this is that in our engineering
curriculum, Java rather than C is covered as the main
programming language in second-level programming courses.
As expected, majority of the students (77.6%) indicated that
their experience with Java was helpful to understand the C
samples provided. Moreover, 64% of the students found the C
sample codes provided to be helpful. Nevertheless, a total of
81% of all students (and a total of 82% of students who
indicated that their Java knowledge was an asset) expressed the
need for at least one tutorial session to further master the C
language. Since most of the C codes provided and programs
required are rather straight forward, providing a dedicated lab
session for the C language will allow for more advanced
exercises in the future.
Questionnaire: A very interesting result is that slightly over one third of all
students (34.5%) have indicated that the introduction of the C
The introduction of C-language questions in the lab reports was to provide language has helped them in improving their Assembly
the students with the experience of programming embedded applications in
Assembly (low-level) and C (high-level) using the same technology (PIC).
language skills. Out of these students, 65% prefer to have the C
In this questionnaire, we would like to assess the effectiveness of such an language as a component of the course, whether as a stand
approach and solicit students’ feedback. alone or with Assembly. Around 41% of all students have also
recommended the use of the C language. Although there are 4
1. Gender: students (7%) highlighted that the C component has negatively
a. Male. affected their Assembly programming skills, all of these
b. Female. students had a Grade Point Average (GPA) below 2.72.
Overall, this feedback provides a very interesting future
2. Are you repeating the lab course?
research direction on how to design exercises in Assembly and
a. Yes. C that complement each other and enhance the students’ skills
b. No. in both programming languages.
Another observation is that all students repeating the
laboratory course, except one, preferred to only use Assembly.
3. Did your experience with Java programing help you better This could be due to the fact they are repeating the course and
understand the C language samples provided? do not prefer to be presented with new material.
a. Yes.
b. No. As for question 9, it was added to the survey to study the
possibility of upgrading the microcontroller used in the course.
However, 93% of the students thought that it was of moderate
4. Did you find the C language samples provided helpful? complexity and thus suitable for the course. Only a single
a. Yes. student expressed that this microcontroller is simple. Hence, in
b. No. future course offerings, one possible option it to switch to a
more powerful microcontroller from the same 8-bit midrange
family. It will almost have the same internal architecture of the
5. Is it essential to have one or two tutorial sessions on current used microcontroller but with extra capabilities (bigger
programming the PIC using the C language? memory, more timers, analog comparators, serial
a. Yes (These sessions are a must). communication modules … etc.) that will allow for more
b. No (Sample codes provided are simple enough to advanced applications while not over complicating the
understand). technology.
Finally, a number of students provided some interesting
6. How did the C language questions affect your Assembly comments that can help in further tuning the current teaching
programing skills? approach:
a. Made it better.
b. Made it worse. x Some students commented that C is not needed as it’s
c. Not related (Had no effect). covered in another course. The other course referred
to is the “Computer Organization and Architecture” in
which the students are exposed to the C language for
7. Which programming language you believe is better for the MIPS processors. In that course the sole emphasis was
microprocessors course? on the students to manually translate provided C
a. Assembly only. codes to equivalent Assembly language programs.
b. C only. However, no programs were written for embedded
c. Both Assembly and C. applications using the features of I/O interfacing,
interrupts, timers, and the like. This could be another
Kindly provide further comments below. reason to include C sessions in the course, not only to
explain the syntax, but also to help illustrate the
difference in using the C language for embedded
8. How do you assess the complexity of the studied PIC16F84A? applications rather than general purpose computing,
a. Simple (A more advanced microcontroller should be x Some students commented that an Assembly program
studied). is clearer than a C program. Although such a
b. Moderate. comment might be unexpected, it shows that some
c. Difficult. students can get confused by writing a C program that
hides a lot of the details the students see and control
using Assembly,
9. Kindly suggest topics you believe should be covered in the lab. x On the other hand, some students expressed the ease
of using the C language and the effort and time it
saves.
Fig. 9. Questionnaire distributed among students at the end of each semester.

978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 273
 TABLE II. ASSESSING THE LABORATORY COURSE LEARNING OUTOCME FOR WRITING ASSEMBLY LANGUAGE PROGRAMS.
Semester Attainment Percentage
Spring 2017 91.30%
Fall 2016 – S01 85.71%
Fall 2016 – S02 79.17%
Spring 2016 72.43%
Fall 2015 – S01 88.00%
Fall 2015 – S02 90.91%
Spring 2015 71.40%
Fall 2014 – S01 84.62%
Fall 2014 – S02 76.92%
B. Students’ Performance
The survey results provided, although encouraging, only
present the students point of view. As a different measure, we
extracted and examined the data pertaining to the attainment
scores for the second learning outcome of the laboratory course
which is “Write assembly language programs.” These
attainment scores are calculated by counting the number of
students scoring 70% or above in the weighted average of all
the course assessment components tied to this learning
outcome. Subsequently, these scores are mapped to a score
rubric indicating the overall students’ level [12, 13].
Attainment scores for the previous 6 offerings are shown in
Table II.
Results show that attainment scores for the Fall offerings
never dropped below Competent (meaning between 75% and
85% of students have scored 70% or above). In the meantime,
for the Spring semesters, the scores for previous offerings is in
the Developing region (meaning between 65% and 75% of
students have scored 70% or above). This could be due having
a number of students repeating the course in the Spring, which
can considerably affect the attainment scores due to the lower
population size (one section offered in the Spring versus two
sections offered every Fall S01 and S02). However, the last
Spring offering have witnessed a sharp increase in the
attainment scores bringing it to the Accomplished region
(meaning at least 85% of students have scored 70% or above).
This result by itself cannot be taken as a proof of the success of
the proposed approach. However, combining this result with
the fact that 43.5% students taking the course in the Spring
indicated that the C language helped them in improving their
Assembly language skills clearly illustrates the promise of this
methodology.
Although having 20% of students repeating the course in
the Fall 2016 semester, the attainment scores remained in the
Competent region. This again when combined with the fact that
40% of students in that semester indicated that the C language
helped them in improving their Assembly language skills
asserts the potential of the presented approach.
C. Relation to the 2016 Model Curriculum
Finally, an important point to highlight is that adopting the
proposed approach will enable the instructor to cover more
core learning outcomes, for the embedded systems knowledge
area, identified by the 2016 computer engineering curriculum
model [1]. These learning outcomes would not have been
possibly covered by only using the Assembly language. Such
outcomes include:
978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 274
Rubric Score C Usage
Accomplished Yes
Competent Yes
Competent Yes
Developing No
Accomplished No
Accomplished No
Developing No
Competent No
Competent No
x Describing the actions of the compiler in the
program translation process. This is highlighted by
the examples provided earlier.
x Describing the actions taken by the compiler-
generated code after system reset but before user
application execution. To be integrated in the
future.
x Describing memory assignments made by the
compiler for global variables, local variables,
subroutine parameters and dynamically allocated
storage. To be integrated in the future.
V. CONCLUSIONS
In this work, we aimed to modify our teaching approach to
an undergraduate microprocessors course in order to allow
engineering students to acquire low-level as well as high-level
programming knowledge. The need for such a change was
dictated by current industrial trends as identified by recent
embedded market surveys and programming languages ranking
tools.
The proposed approach is applied to the laboratory course.
In a number of selected lab sheets the students are required to
repeat a number of activities (implemented in Assembly during
the lab session) using the C language. A single sample C
program is provided for each sheet and could be used by the
students as a basis for implementing other activities. This
modification enables the students to experiment with both
Assembly and C programming targeted for the same PIC
hardware while using the same IDE.
This approach has been applied in two consecutive
semesters during the past academic year. Both students’
feedback and performances were used to assess its
effectiveness and impact on students’ learning. Survey results
have shown that 40% of the students have recommended the
use of the C language and that 34% of them reported the
improvement of their Assembly language skills by having the
C language as a component of the course. Moreover, 81% of
the students have found the provided C sample codes to be
very helpful. Examining the attainment scores extracted from
the course data for the learning outcome pertaining to the use
of the Assembly language have shown a big increase in the
Spring semester for which the scores are usually lower. Similar
high attainment scores were observed for the Fall semester
despite having 20% of the students repeating the course.
For the future development of the course, it is intended to
further integrate the C language in the course (as for now more
emphasis is still placed on the Assembly language). However,
this integration should be carefully implemented to maintain an
appropriate balance between the two. Integrating the C
language will be also designed to appropriately cover more
core learning outcomes in the 2016 computer engineering
model curriculum. In addition, one or two C tutorial sessions
will be planned and delivered to the students in future
semesters in order to improve the overall learning experience.
REFERENCES
[1] https://www.computer.org/web/peb/curricula
[2] https://m.eet.com/media/1246048/2017-embedded-market-study.pdf
[3] https://spectrum.ieee.org/static/interactive-the-top-programming-
languages-2017
[4] http://www.microchip.com/mplab/mplab-x-ide
[5] M. El-Abd, “How Course Projects can Successfully Prepare Engineering
Students for Capstone Design Projects.” In the IEEE Global Engineering
Education Conference (EDUCON), pp. 746-750, 2016.
[6] M. El-Abd, “Preparation of Engineering Students for Capstone Design
Experience through a Microprocessors Course.” In the International
Journal of Engineering Pedagody (iJEP), vol. 7, no. 4, pp. 91-101, 2017.
[7] P. Jamieson, “Arduino for Teaching Embedded Systems. Are Computer
Scientists and Engineering Educators Missing the Boat?” In the
International Conference on Frontiers in Education: Computer Science
and Computer Engineering (FECS), 2011.
[8] P. Jamieson and J. Herdtner, “More Missing the Boat - Arduino,
Raspberry Pi, and Small Prototyping Boards and Engineering Education
Needs Them,” In the IEEE Frontiers in Education (FIE), pp. 1442-1447,
2015.
[9] P. Herzog and A. Swart,” Arduino – Enabling Engineering Students to
obtain Academic Success in a Design-based Module,” In the IEEE
Global Engineering Education Conference (EDUCON), pp. 66-73, 2016.
[10] M. El-Abd, “A Review of Embedded Systems Education in the Arduino
Age: Lessons Learned and Future Directions.” In the International
Journal of Engineering Pedagody (iJEP), vol. 7, no. 2, pp. 79-93, 2017.
[11] http://www.microchip.com/mplab/compilers
[12] J. Yousafzai, I. Damaj and M. El-Abd, “A unified approach for
assessing capstone design projects and student outcomes in computer
engineering programs.” In the IEEE Global Engineering Education
Conference (EDUCON), pp. 333-339, 2015.
[13] I. Damaj and J. Yousafzai, “Simple and accurate student outcomes
assessment: A unified approach using senior computer engineering
design experiences.” In the IEEE Global Engineering Education
Conference (EDUCON), pp. 204-211, 2016.

978-1-5386-2957-4/18/$31.00 ©2018 IEEE 17-20 April, 2018, Santa Cruz de Tenerife, Canary Islands, Spain
2018 IEEE Global Engineering Education Conference (EDUCON)
Page 275