Difference between revisions of "FAQ"

From DistRap wiki
Jump to: navigation, search
(init FAQ)
 
(rename FAQ)
 
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.
 

Latest revision as of 02:20, 30 September 2017