|
|
Line 1: |
Line 1: |
− | == Why CAN? ==
| + | [[Category:Deleted]] |
− | | |
− | 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.
| |