Š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.
  • => needs to be done well!

  • also: logs, system state

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

Made with Slides.com