Make it with Micromite
Phil Boyce – hands on with the mighty PIC-powered, BASIC microcontroller
Part 36: How it works: The Electronic Door Lock software
specific requirements. Remember, changing program code
really is the best way to learn more about the amazing power
of MMBASIC.
System features
I
n the previous Make it with Micromite article
(PE, April 2022), we discussed the hardware assembly of
our current mini-project; the iButton Electronic Door Lock
(iEDL). As a brief recap, the iEDL hardware comprises a handful
of components and modules attached to a Micromite; these are:
a touchscreen, an iButton reader (on pin 9), an LED (on pin
10), a relay module (on pin 21), and a piezo sounder (between
pins 22 and 26). To bring all these hardware elements alive we
will use MMBASIC program code running on the Micromite
so that they work together as a system. This month, we will
discuss the iEDL software, providing a simplified overview,
and explaining how it works.
System features
We begin by listing all the features that will be incorporated
into the iEDL and give a brief explanation of why these features
are required. From this features list, we will then map out the
required process flows that the iEDL needs to follow, which
will in turn make the program code much easier to understand.
It will also help define all the different screens with which a
user will interact.
We will also describe how an iEDL reader uses three pieces
of configuration data: the Admin-Key-ID, a Description and
the Access-Group-ID for the iEDL. Turning to the iButton, we
will discuss how different configuration data is formatted (and
stored) in an EEPROM iButton key (hereafter referred to as an
‘iKey’), and how this configuration data is used by the iEDL.
One point worth emphasising here is that any code presented
in this series is primarily provided for learning purposes.
Once you feel that you understand how a topic works, we
strongly encourage
you customise the
Micromite code
program code so
The code in this article is available
that it suits your
for download from the PE website.
own preferences and
54
The whole system uses the following three elements:
User iKey (one issued to each user). Configuration data is
stored in the iKey’s EEPROM and comprises: the keyholder’s
Name, permitted Door-Group-Access-Levels (a value from 0
to 255), and an Identifier (the word ‘iKey’).
iEDL (one required for each secured door). Configuration data
is stored in the iEDL’s memory and comprises: a Description
for the iEDL (eg, its location), an Access-Group-ID (a number
from 1-8), and an Admin-Key-ID (a specific iButton’s unique
8-byte ID value).
Single Admin-Key to confi gure the whole system and
issue iKeys.
Together, these three elements need to provide the following
high-level capability:
When a person taps their user iKey onto an iEDL’s reader,
their access level (stored in the iKey’s EEPROM) is checked
with the Access-Group-ID stored in the iEDL. The user is
then either granted or denied access to the secured door;
with a suitable message (containing their Name) displayed
on the iEDL’s touchscreen
Any iButton without the iKey Identifier (read from EEPROM)
will not be considered part of the system, and will result in
an ‘Invalid iKey’ message being displayed
If the Admin-Key is detected – the iButton’s unique ID matches
the iEDL’s stored Admin-Key-ID – then the iEDL switches
into ‘Admin Mode’. This allows any configuration data to
be adjusted either in the iEDL itself, or in a user’s iKey. For
example, in Admin Mode, you can change the iEDL’s location
Description, or you can alter the Door-Group-Access-Levels
in a user’s iKey
Admin Mode is also used for issuing new iKeys to new users
When the program code is run for the very first time, the
iEDL needs to define the single Admin-Key-ID by displaying a
simple prompt to tap the desired iButton (any type) onto the
iEDL’s reader. Once confirmed, the iEDL will automatically
enter Admin Mode so that the default Description (‘Micromite
iEDL’), and default Access-Group-ID (‘1’) can be altered.
Reasons for features
Let’s expand on the above points and discuss why some
of these features have been implemented. The overriding
Practical Electronics | June | 2022
E E P R O M
b yt e
1
2
3
4
5
6
7
8
9
1 0
1 1
1 2
1 3
1 4
i K E Y M i c r o m i t e
Id e n tifie r
( 4 b yt e s)
N a m e
( 1 6 b yt e s)
1 5
1 6
1 7
1 8
i E D L
1 9
2 0
2 1
2 2
2 3
2 4
2 5
2 6
2 7
2 8
2 9
3 0
3 1
3 2
1 x
D o o r - G r o u p - A ce
s
( 1 b yt e )
C R C
( 1 b yt e )
U n u se d
( 1 0 b yt e s)
Fig.1. The user iKey stores configuration data in EEPROM – 22-bytes of the available 32-bytes are used.
idea behind the iEDL is for it to be a secure alternative to
the classic digital combination lock. The big disadvantage
with most digital combination locks is that when an
authorised user enters the ‘secret’ code on the keypad, any
‘unauthorised’ person nearby may be able to observe the
code, re-enter the code and gain access. The iEDL eliminates
this disadvantage by not requiring a code to be entered;
instead, it allows access only with the possession of a valid
iKey. All a keyholder needs to do is tap their iKey onto the
iEDL’s iButton reader.
However, we don’t just want any iButton to be able to
‘unlock’ the door, so we’ve added some intelligence to the
system with door access permissions. An iEDL is configured
with an Access-Group-ID, which is a single value between
1 and 8. Also, when a user is issued with an iKey, the
door group IDs that the keyholder is permitted to access is
stored on their iKey (this can be multiple Access-GroupIDs). The iEDL can then determine whether to grant access
to the keyholder. If access is granted, the iEDL releases the
electronic door locking mechanism.
Where multiple iEDLs are implemented (ie, multiple
doors are secured), the door access permissions allow us
to configure a user to be granted access to some groups of
doors but denied access to others.
Another important design requirement (where multiple
iEDLs are implemented) is to eliminate the need for having
to connect the iEDLs to each other. By avoiding potentially
complex cable runs between doors, it not only makes for
an easier install, but also makes the solution very scalable.
So, regardless of whether just one iEDL is used (for a single
door), or multiple iEDLs for multiple doors, each iEDL can be
regarded as a standalone unit which just needs power (and
a connection to the door’s electronic locking mechanism).
The iEDL’s stand-alone capability (and the ease of scalability)
is possible thanks to the smart way in which EEPROM
iButtons have been implemented as iKeys. Not only is a
keyholder’s Name stored on their iKey (allowing their Name
to be displayed on the iEDL’s screen when the user taps their
iKey onto the iButton reader), but also the groups of doors
that the keyholder can access is stored on the iKey too.
Another design aim for the iEDL was for there to be no need
to connect it to a computer. This is achieved by including
a touchscreen. Being able to put an iEDL into Admin Mode
means it is possible to configure certain attributes of the
system via the touchscreen (instead of via a computer).
The touchscreen also enables an iEDL to be used to issue
iKeys to keyholders (because the keyholder’s Name can be
entered on a touch-keypad).
To switch an iEDL into ‘Admin Mode’, we have created
a dedicated Admin iButton. Whenever this Admin iButton
is presented to an iEDL, it switches the iEDL from ‘Normal
Mode’ to Admin Mode, thereby giving access to all the
configuration functionalities. Note that the Admin iButton
is not used to unlock a door.
Summary of features and configuration data
Let’s summarise these main features, along with defining
some of the more specific details about the configuration
data for the iEDL and the iKey. Note that no configuration
data is required for the Admin-Key.
Practical Electronics | June | 2022
An iEDL has two modes of operation: Normal and Admin
Normal Mode is the default mode. In this mode the
iEDL is simply waiting for any iButton to be tapped
onto the iButton reader
Admin Mode allows the system to be configured with
various settings, and to issue (and check) iKeys.
The iEDL configuration data is stored in the Micromite’s
Flash memory, and comprises the following:
Admin-Key-ID – this is the 8-byte ID number of the
iButton; ie, the iButton’s Family-Code, its 6-byte ID, and
the CRC (8 bytes stored as the string: AdminKeyID$)
Description for the iEDL – eg, a location description (16
bytes stored as the string: Desc$). This is displayed at
the top of the screen when the iEDL is in Normal Mode
Access-Group-ID – a number from 1 to 8 (1 byte stored
as the variable: AccessGrpID).
There are two types of iButton recognised by an iEDL:
User iKey and Admin iKey
User iKey is based on a DS1971 iButton (ID + 256-bit
EEPROM)
Admin Key can be any type of iButton. It is used to
switch the iEDL from Normal Mode to Admin Mode.
User iKey configuration data has a capacity of 32-bytes;
however, (referring to Fig.1) only 22-bytes are used:
Identifier containing the ASCII characters ‘iKey’ to
signify it is an iKey (4 bytes)
Keyholder’s Name (16 bytes)
Keyholder’s Door-Group-Access-Levels (1 byte)
Error-checking CRC (1 byte).
The iEDL functionality has been broken down into four
distinct process flows:
1. Normal Mode
2. Power Up
3. Admin Mode (reader configuration)
4. Admin Mode (iKey configuration).
We will now discuss each one in turn.
Process flow 1: iEDL Normal Mode
In Normal Mode, the iEDL will display the iEDL’s Description
on the touchscreen and a flashing message will prompt the
user to tap their iKey onto the iButton reader.
From the user’s perspective, all they need to do is tap their
iKey onto the iEDL’s iButton reader. If they have permission for
the door group that the iEDL belongs to, then the user will see
a confirmation message displayed on the iEDL’s touchscreen,
and they are granted access. However, if the keyholder doesn’t
have permission for the door group then access is denied, and
an ‘access denied’ message is displayed.
If the Admin Key is detected by the iEDL, then the iEDL
switches to Admin Mode. Finally, any invalid iKey will result
in an ‘Invalid iKey’ message being displayed.
To map out the process flow, the above can be summarised
as the following:
Display the iEDL Description and wait for an iButton
When an iButton is detected, read the 8-byte ID (and
error check with CRC)
Is it the Admin Key? If yes, then switch the iEDL into
Admin Mode
55
D o o r - G r o u p - A c c e s s - L e v e ls b y te in iK e y
B it
8
7
6
5
4
3
2
N o rm a l M o d e
1
0 0 0 0 1 0 0 1
iE D L A c c e s s G r o u p ID
8 7 6 5 4 3 2 1
W a it fo r iB u tto n
If B itn = 0 th e n d o o r a c c e s s d e n ie d fo r A c c e s s G r o u p n
If B itn = 1 th e n d o o r a c c e s s g r a n te d fo r A c c e s s G r o u p n
E x a m p le : if iK e y D o o r - G r o u p - A c c e s s - L e v e ls v a lu e = 9 ( a s s h o w n )
th e n a c c e s s g r a n te d fo r a n y iE D L w ith A c c e s s - G r o u p - ID
N
o f 4 o r 1
Fig.2. The eight bits in the Door-Group-Access-Levels byte
(stored in the iKey’s EEPROM) determine which of the eight
possible Access-Group-IDs that the keyholder can access.
For example, if the Door-Group-Access value is 9 (binary:
00001001), then they keyholder only has access to iEDLs that
have their Access-Group-ID set to either 1 or 4.
iB u tto n
d e t e ct e d ?
Y
R e a d ID
N
Is it a DS1971? If yes, then read EEPROM to get: the
Identifier, the keyholder’s Name, their Door-Group-Access
permission value and the CRC. If not a DS1971, or the
Identifier doesn’t match ‘iKey’ then display an ‘Invalid
iKey’ message
If the Identifier and the CRC are both correct, then check
door permissions with the iEDL’s Access-Group-ID to
determine if access should be granted or denied (with
an appropriate message also displaying the keyholder’s
Name). If access is granted, then momentarily trigger
the relay module. (See Fig.2 for more details about how
the door permissions work.)
Refer to Fig.3 to see the above list converted into a process
flow diagram. This diagram is a useful reference when
working through the iEDL’s program code and makes
program comprehension much easier.
C R C
lid ?
va
Y
Y
S w i t ch t o
A d m in M o d e
Y
A ce
L e ve
A d m in
ke y?
N
R e a d E E P R O M
N
C R C
lid ?
va
Y
Process Flow 2: Power up
On Power up, the iEDL must determine if this is the first time
that the software has ever run, and if so, it prompts the user
to define one iButton for use as the Admin-Key; otherwise,
it starts the iEDL in Normal Mode (discussed above).
To determine if the iEDL software has previously been
run, the program code must first read the contents of
the Micromite’s Flash memory by using the MMBASIC
command VAR RESTORE. By using this command at the very
beginning of the program, two strings (AdminKeyID$ and
Desc$) and one variable (AccessGrpID) are automatically
loaded with whatever is currently stored in Flash memory.
So, the very first time the iEDL software is run, the two
strings will be empty, and the variable will have a value of
0. Hence, by checking if AdminKeyID$=”” (shortly after
the VAR RESTORE command) it can be determined if the
program code is running for the first time.
If it is running for the first time, then a message prompts
for an Admin-Key to be defined, and the following points
then become relevant:
The Admin-Key can be any type of iButton (ie, the family
code is irrelevant; it is just the iButton’s unique 8-byte
ID number that the iEDL will read)
The user needs to be prompted to tap the desired AdminKey a second time. This guarantees a match so that
the user knows which key it actually is (it can become
confusing when surrounded by many iButtons!)
Once the Admin-Key has been confirmed, the iButton’s
unique ID is stored in the iEDL’s Flash memory by using
the command: VAR SAVE AdminKeyID$)
If a different iButton is presented on the second occasion,
the user is prompted to repeat the process from the start
56
D S 1 9 7 1
a n d
iK e y
N
I n va
s
l O K
N
Y
l i d ke
y
G ra n te d
P a u se
f o r 2 se
D e n ie d
c
Fig.3. Process flow for iEDL Normal Mode.
Admin Mode is automatically entered once the Admin-Key
has been successfully defined
To exit Admin Mode to Normal Mode, press the ‘EXIT’
button on the iEDL touchscreen.
The Power Up process flow diagram is shown in Fig.4.
Admin screen
When the iEDL is in Admin Mode, there are two main
functions that can be performed: Reader configuration and
iKey configuration.
Practical Electronics | June | 2022
The Admin screen (Fig.5) displays the current settings
for the iEDL’s Description, and Access-Group-ID, and
also prompts the user to tap an iKey (if an iButton needs
processing). At the bottom of the Admin screen there are
three buttons: ‘Desc’, ‘Group’ and ‘EXIT’.
P o w e r u p
R e a d F l a sh m e m o r y
( VAR RESTORE)
Process Flow 3: iEDL Admin Mode
(Reader config)
F l a sh
m e m o r y e m p t y?
( AdminKeyID$=””)
This section covers the reader configuration, which is
how to alter the iEDL’s Description, and/or the iEDL’s
Access-Group-ID.
On pressing the touchscreen ‘Desc’ button, a pop-up
touch-keypad appears (see Fig.6). The keypad enables
a Description to be defined (ie, entered) for the iEDL.
To be precise, it allows the current Description to be
edited. Note that on first power up, this defaults to
‘Micromite iEDL’). On saving the edited Description,
it is stored in the Micromite’s Flash memory (using the
MMBASIC command: VAR SAVE Desc$) and the user
is then returned to the Admin menu
On pressing the ‘Group’ button, one of eight possible
buttons (numbered 1-8) are displayed. Pressing one of
these buttons defines the iEDL’s Access-Group-ID (and
the value stored in the variable: AccessGrpID. This
value is saved in Flash memory (using: VAR SAVE
AccessGrpID), and the user is then returned to the
Admin menu.
On pressing the ‘Exit’ button, the iEDL will switch back
to Normal Mode.
N o rm a l M o d e
Y
F i r st
tim e r u n
P r o m p t to ta p iB u tto n
i B u t t o n d e t e ct e d ?
N
Y
R e a d iB u tto n ID
C R C
N
va
lid ?
Y
S to r e iB u tto n ID
( AdminKeyID$=ID)
Process Flow 4: iEDL Admin Mode
(iKey config)
This section covers how to process an iButton. There are
several scenarios that can occur. For example, it could
be to check an iButton (to see if it is configured or not),
or to issue a new iKey, or to edit the configuration data
stored in the EEPROM of an existing iKey.
On presenting an iButton in Admin Mode, it will be
processed depending on the following:
A blank DS1971 iButton has the option to be assigned
to a user (via the touchscreen) – in other words, issue
a new iKey
The keyholder’s Name is entered via the pop-up
touch keypad
The keyholder’s Door-Group-Access-Levels value
is entered on the touchscreen
on pressing ‘Save’, the user is prompted to tap the
same iButton on the iEDL’s iButton reader. If the
same iButton ID is detected, then all the relevant
data is written to the iKey’s EEPROM. If a different
iButton ID is detected, then a suitable message is
displayed (with the option to Exit, or try again).
An existing iKey (DS1971) can be wiped, or the
configuration data can be changed (keyholder’s Name,
and/or their access permission) via the touchscreen in
a similar way to issuing a new key
If the Admin-Key is detected, the iEDL will simply
display a message on the touchscreen stating that it is
the Admin-Key.
N
M e sa
g e b o x
C o n fir m iB u tto n
r e m o ve d O K
P r o m p t t o t e st
A d m in - K e y
i B u t t o n d e t e ct e d ?
N
Y
R e a d iB u tto n ID
C R C
N
va
lid ?
Y
M e sa
g e b o x
E R R O R : W r o n g ke
st a r t a g a i n O K
y
N
S a m e iB u tto n
d e t e ct e d ?
Y
S a ve A d m i n - K e y I D
i n F l a sh m e m o r y
( VAR SAVE
AdminKeyID$)
M e sa
g e b o x
S U C C E S S O K
A d m in M o d e
Message box
Another useful feature (borrowed from Geoff Graham’s
SuperClock) is the pop-up message box. As commented in
the program code, this handy routine draws a message box
on the touchscreen, with an OK button. When a message
needs displaying, this is used to halt the program, and it
simply waits for the OK button to be touched, after which
the program continues (see Fig.7).
Practical Electronics | June | 2022
Fig.4. Process flow for Power Up.
57
(left to right) Fig.5. The Admin screen is used to either configure the iEDL, or to issue (and check) iKeys.
Fig.6. This pop-up keypad (adapted from Geoff Graham’s SuperClock program) makes it possible to enter an alphanumeric
description. In the iEDL software, it is used to enter an iEDL Description, and a keyholder’s Name when issuing/editing an iKey. Note:
the large left and right arrows navigate to different sets of characters (with 12 being shown at a time).
Fig.7. This pop-up message box (borrowed from Geoff Graham’s SuperClock program) displays warning messages and effectively
halts the program until the user clicks the OK button.
iEDL software
Ideas for customisation
The iEDL software (iEDL.txt) can be downloaded from the
June 2022 page of the PE website. Once installed, look
through the code so you can compare it to the process flows
provided above. We will not go into any further discussion
here about how it works as the comments in the code (along
with the process flow diagrams) should be easy to follow.
Run the code and have a play.
At a minimum, you will need to have two iButtons and
a single iEDL (but there’s no need for a door complete with
electronic door-locking mechanism!). At any time, you can
stop the code (Ctrl-C) and examine what is going on. You
should be able to work out how the program code works
as a standalone system.
As with any code supplied, we encourage you to make
changes to it. This project allows for modification, so here
are a few ideas to think about:
Change the colours
Alter the characters available, and/or the sequence they
appear) on the pop-up touch-keypad
Add a real-time clock (RTC) and display the date and time
on the screen (in Normal Mode)
Add automatic time-outs in the Admin screens so that
the system doesn’t get left in Admin Mode
Increase the number of Access-Group-IDs to allow for
more than eight groups (only sensible when more than
eight doors need to be secured)
Use the spare bytes in the iKey EEPROM to store some
additional data
Add a list of blocked keys in an iEDL.
ESR Electronic Components Ltd
All of our stock is RoHS compliant and CE
approved. Visit our well stocked shop for
all of your requirements or order on-line.
We can help and advise with your enquiry,
from design to construction.
3D Printing • Cable • CCTV • Connectors • Components •
Enclosures • Fans • Fuses • Hardware • Lamps • LED’s •
Leads • Loudspeakers • Panel Meters • PCB Production •
Power Supplies • Relays • Resistors • Semiconductors •
Soldering Irons • Switches • Test Equipment • Transformers
and so much more…
Monday to Friday 08:30 - 17.00, Saturday 08:30 - 15:30
I hope this has sparked some ideas of your own – remember,
the best way to learn is to study and adapt the software.
We hope you have enjoyed this mini-project. Do contact us if
you build an iEDL and let us know how you get on, and what
modifications you may have made. And remember, if you get
stuck, just reach out to us and we will do our best to help.
Next time
Unfortunately, the ongoing chip shortage has greatly affected
the availability of many Micromite and Maximite products.
However, another product that is readily available is the
Raspberry Pi Pico (as featured in last month’s PE). Not only is
it available, but it is also extremely cheap (typically around
£3.50). Wouldn’t it be fantastic if a version of MMBASIC was
available for the Pico? Well, we have some great news for
you; MMBASIC is now available for the Pico, and next month
we will show you how easy it is to get started. As an added
bonus, the MMBASIC for the Pico is the Plus version, which
provides many more features than the Standard version. And
in case you’re wondering, yes it can also control many of the
Pico add-on boards that are currently flooding the market.
So be prepared to be amazed next month when we show
you everything you need to know to get up and running.
Until then, stay safe, and have FUN!
Station Road
Cullercoats
North Shields
Tyne & Wear
NE30 4PQ
Tel: 0191 2514363 sales<at>esr.co.uk www.esr.co.uk
58
Questions? Please email Phil at:
contactus<at>micromite.org
Practical Electronics | June | 2022
