FrequentlyAskedQuestions

From DistRap wiki
Revision as of 01:20, 30 September 2017 by Srk (talk | contribs) (rename FAQ)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Why CAN?

CAN bus uses differential signaling to provide noise resistant communication between nodes. This is a critical requirement for our applications as they may use high power motor drivers and motors producing lots of EMI. The other reason is the availability of the CAN peripheral on STM32 ARM MCUs which means only adding CAN transceiver like SN65HV is necessary.

Why CANOpen?

Rather than reinventing our custom protocol we're using CANOpen protocol which is designed for industrial applications. This also allows us to stay compatible with wide range of already existing manufacturers.

Why Ivory Tower?

Due to Ivory being embedded in Haskell it reduces a lot of headache associated with maintaining larger codebase as it allows to share code between various firmwares and catch most errors during compilation time. Additional safety provided by Ivory also helps in mission critical deployments such as robotics applications.

Tower allows us to compose code on even higher level and allows us to write concurrently safe programs by providing communication channels which are used to exchange data between various components called "towers".

On the backend side of things Ivory/Tower supports GCC ARM toolchain with either FreeRTOS or EChronos realtime operating system. POSIX backend allows us to run similar code on POSIX and MCU which is quite handy for testing or development without actually using MCU itself (especially handy for protocols related development). Additional backends for verification tools are also provided allowing for verification of critical parts of the code.

Why STM32?

  • natively supported by ivory-tower-stm32
  • supported by EChronos
  • CAN peripheral

Also core clock speeds, high amounts of flash (1Mb quite common on F4 MCUs), advanced timers for 3 phase PWM generation, hardware encoder interfaces, multiple ADCs for simultaneous sampling or sampling of large number of channels in sequence, checksummed parts of SRAM, battery backed parts of SRAM. Good toolchain support and debugging options as well - possibility to use GCC ARM toolchain and GDB directly with Black Magic probe enabled programmer.