ŠTUDENTSKÝ VÝVOJOVÝ TÍM
or
How small ideas open the door to great possibilities
Kamila Součková
Join us! ;-)
presentation based on Adam Dej's work (http://slides.com/adamdej/svt-deadlock)
What is it?
...and more!
1. Embedded
Hardware
+
// __attribute__((OS_main)) tells the compiler that this function never
// returns and saves us precious space
__attribute__((OS_main)) int main(void) {
hal_init(&comm_byte_received_callback);
// This is the main handling loop
// It handles all packets that can arrive in the Normal mode
while (1) {
if (comm_wait_for_packet(&p[current_packet]) == 0) {
switch (p[current_packet].id) {
case packet_GET_STATUS:
sendACK();
break;
case packet_RFID_SEND:
// We will send data from this packet, and replace them
// in-place with what we receive
hal_spi_begin_transaction();
for (uint8_t i = 0; i < p[current_packet].length; i++) {
p[current_packet].data[i] =
hal_spi_transfer(p[current_packet].data[i]);
}
hal_spi_end_transaction();
// And suddenly, we are a response packet :)
p[current_packet].id = packet_RFID_SEND_COMPLETE;
transmit_and_flip();
break;
case packet_RX_ERROR:
// Retransmit the last packet
comm_transmit_packet(&p[current_packet ^ 1]);
break;
default:
// Unacceptable packet was received in this mode
p[current_packet].id = packet_INVALID_PACKET;
p[current_packet].length = 0;
transmit_and_flip();
break;
Software
2. Server:
Centralized Management
- access database
- logs / monitoring
- access
- system state
- firmware updates
3. UI:
Interface for Humans
- easy access management
- ~10k people
- ~100 doors
- time of day, day of week, etc.
- also: logs, system state
=> needs to be done well!
We already have that!
But...
not maintainable,
not extensible,
expensive
How?
Server
- "One server to rule them all"
- access database: card ID => when can I open which door?
- distributes data to door controllers
- auxiliary functions:
- centralized logs storage
- firmware updates
Controller
-
controls a single door
- "should I open now?"
- door sensor (was it opened without permission?)
-
should work offline
- so that we don't care about server/connection problems
- custom embedded device
- (optional) Power over Ethernet (standard)
- ARM Cortex M0 MCU
- software in C (+ ChibiOS)
Server ↔ Controller
- standard Ethernet
- Power over Ethernet
- communication over UDP
- encryption, authentication
Reader
- Číta ISIC-y
- Bliká a pípa :)
- Komunikuje buď cez naše rozhranie alebo
cez USB - ARM Cortex M0 MCU
- Naprogramovaný v C (+ ChibiOS)
Controller ↔ Reader
- custom interface
- simple installation, available
- power + data
- based on RS-232
How much better is this?
Price
Cheaper than the commercial alternatives... By an order of magnitude.
(~1e1 vs 1e2 €/door)
Open source &
Open hardware
No vendor lock-in
Available parts / simple alternatives
Practical installation & administration
Plug-and-play
Extensible deployment
HW can be easily replaced
Future-proof
Modular architecture
Ready for changes in ISIC cards
My work
- exact specification
- high-level design
- communication protocol server <--> controller
- => part of controller software design (offline capabilities & such)
- server design and implementation
Conclusion
Project Deadlock
or
How small ideas open the door to great possibilities
...will be fun!
Want to join? :-)
svt.fmph.uniba.sk
fmfi-svt@googlegroups.com
Project Deadlock [bak. seminár, 1. prezentácia]
By Kamila Součková
Project Deadlock [bak. seminár, 1. prezentácia]
How small ideas open the door to great possibilities
- 506