Differenze tra le versioni di "Gruppo Meteo/CanBus"

Da raspibo.
Jump to navigation Jump to search
 
Riga 18: Riga 18:
 
* Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU] standards
 
* Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU] standards
  
 +
 +
* https://en.wikipedia.org/wiki/CAN_bus
  
 
== corsi ==
 
== corsi ==

Versione attuale delle 01:36, 3 nov 2020

Alternative

estendere un bus I2C

https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf https://www.sparkfun.com/products/14589

rs-485 vs can bus

Can Bus

Overview

The CAN bus is an ISO standard bus originally developed for vehicles. It manages the Chassis Electrical System Control and is responsible for critical activities like engine electrical, and skid control. This system is also used to provide vehicle diagnostic information for maintenance. A multi-star configuration seems typical of this bus with a primary bus line that branches into sub bus lines at its extremities then attaches to multiple device nodes. Differential voltage is applied over twisted pair at 1.5 to 2.5V and 2.5 to 3.5V for noise resistant signaling. Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g., 500 m at 125 kbit/s). (Jeremiah J. Flerchinger Source) Controllers supporting CAN FD, an enhanced CAN version with frames up to 64 byte and bit rates up to 4 Mbit/s, will be available in the second half of 2014. A can4linux version supportig CAN FD on a IFI CAN is ready to be used.

Each node requires a:

  • Central processing unit, microprocessor, or host processor
  • CAN controller; often an integral part of the microcontroller
  • Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU] standards


corsi

CAN message filtering

Use of 32 bit IDMASK filtering

This is a good explanation of how mask and ID are handled in STM32 devices

More around standard and extended ID

Standard ID have a value between 0 and 0x7FF

Extended ID have a value between 0 and 0x1FFFFFFF

A CANBUS B frame (extended) consists of a four byte header (containing a 29-bit identifier), followed by up to 8 data bytes. A receiving node would examine the identifier to decide if it was relevant (e.g. waiting for a frame with ID 00001567 which contains data to switch on or off a motor).

It could do this via software (using a C if or case statement); in practice the Canbus interface contains firmware to carry out this task using the acceptance filter and mask value to filter out unwanted messages. The filter mask is used to determine which bits in the identifier of the received frame are compared with the filter If a mask bit is set to a zero, the corresponding ID bit will automatically be accepted, regardless of the value of the filter bit. If a mask bit is set to a one, the corresponding ID bit will be compare with the value of the filter bit; if they match it is accepted otherwise the frame is rejected.

Default this laibrary accept any frame e.g. no filters are applied

  • set filter to 0
  • set mask to 0

Example 1. we wish to accept only frames with ID of 00001567 (hexadecimal values)

  • set filter to 00001567
  • set mask to 1FFFFFFF

when a frame arrives its ID is compared with the filter and all bits must match; any frame that does not match ID 00001567 is rejected

Example 2. we wish to accept only frames with IDs of 00001560 thru to 0000156F

  • set filter to 00001560
  • set mask to 1FFFFFF0

when a frame arrives its ID is compared with the filter and all bits except bits 0 to 3 must match; any frame other frame is rejected

Example 3. we wish to accept only frames with IDs of 00001560 thru to 00001567

  • set filter to 00001560
  • set mask to 1FFFFFF8

when a frame arrives its ID is compared with the filter and all bits except bits 0 to 2 must match; any frame other frame is rejected

Please read the links to figure out FilterID and FilterMask FilterBank have to be defined pr. CAN interface, 0 to 13 handle Can1 message filters and 14 to 27 handle Can1 message filters You alway have to start with the default filter e.g. 0 for Can1 and 14 for Can2 as they by default is set to allow all messages StdOrExt define ID type, default is standard


CAN-FD

The CAN-FD protocol (CAN with flexible data-rate) is an extension of the classical CAN (CAN 2.0) protocol.CAN‑FD is the CAN 2.0 successor. It efficiently supports distributed real-time control with a very high-level ofsecurity. CAN-FD was developed by Bosch and standardized as ISO 11898-1:2015 (suitable for industrial,automotive and general embedded communications)

Improvements and benefits of CAN-FD over CAN 2.0The CAN-FD development responds to the need of communication networks that require higher bandwidth. Thisneed is fulfilled by the CAN-FD having up to 64 bytes per frame and by its possibility to increase the bitrate to upto eight times faster during the data phase, and to go back to a normal bitrate during the second arbitration phase.The data transfer integrity is ensured by:

  • a CRC used to checksum a payload of up to 16 bytes based on 17 stage polynomial
  • a 21-stage polynomial used to checksum the payload between 16 and 64 bytes

CAN-FD featuresMain features of the CAN-FD protocol are listed below:

  • Compatibility with the CAN protocol: CAN-FD node is able to send/receive CAN messages according toISO 11898-1
  • Error-checking improvement, based on checksum field up to CRC 21 bits
  • Prioritization of messages
  • Guarantee of latency times
  • Configuration flexibility
  • Multicast reception with time synchronization
  • System-wide data consistency up to 64 bytes per message
  • Multimaster
  • Error detection and signaling
  • Distinction between temporary errors and permanent failures of nodes and autonomous switching off ofdefect nodes

can-fd-light

can priority inversion

hardware

CAN SPI mcp2515

CAN Transceiver MCP2551

STM32

https://github.com/r-map/rmap/blob/master/platformio/test/canbus-exocan/schematic.png

Can stm32.jpg

software

SLCAN

Can bus in Linux

SocketCAN is a set of open source CAN drivers and a networking stack contributed by Volkswagen Research to the Linux kernel. Formerly known as Low Level CAN Framework (LLCF).

The socketcan package is an implementation of CAN protocols (Controller Area Network) for Linux. While there have been other CAN implementations for Linux based on character devices, SocketCAN uses the Berkeley socket API, the Linux network stack, and implements the CAN device drivers as network interfaces. The CAN socket API has been designed as similar as possible to the TCP/IP protocols to allow programmers, familiar with network programming, to easily learn how to use CAN sockets. More info on SocketCAN can be

Can bus python

CANdevStudio

busmaster per windows

OpenBLT Bootloader

OpenBLT is an open source bootloader for STM32, XMC, HCS12 and other microcontroller targets.

By default, it supports communication interfaces such as: RS232, CAN, USB, TCP/IP and it ships with the easy-to-use MicroBoot PC tool for initiating and monitoring the firmware update. Performing firmware updates directly from an SD-card is also supported.

librerie per STM32

exocan

https://github.com/r-map/rmap/blob/master/platformio/test/canbus-exocan/src/bpCanBlinkInterrupt.ino

STM32CAN

Protocols

  • CANopen - manufacturing process control
  • SAE J1939 - off road truck and bus
  • UAVCAN intravehicular communication in aerospace and robotic applications
  • ISO 11783 - agricultural
  • OBDII - automotive diagnostics
  • NMEA 2000 - GPS and navigation

CanOpen

CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile.

SAE_J1939

UAVCAN

What is UAVCAN?

UAVCAN is an open lightweight protocol designed for reliable intravehicular communication in aerospace and robotic applications over CAN bus, Ethernet, and other robust transports. It is created to address the challenge of deterministic on-board data exchange between systems and components of next-generation intelligent vehicles: manned and unmanned aircraft, spacecraft, robots, and cars.

specifiche

Applicazioni

libreria per arduino


pyuavcan

pyuavcan sub --transport "pyuavcan.transport.can.CANTransport(can.media.socketcan.SocketCANMedia('can0',8),None)" uavcan.node.Heartbeat.1.0


UAVCAN libreria c++ semplificata per arduino

UAVCAN library for Espressif microcontrollers. (Arduino SDK)

https://github.com/JediJeremy/libuavesp


LIBCANARD UAVCAN library for STM32 microcontrollers. (Arduino SDK)

https://github.com/r-map/rmap/blob/master/platformio/test/uavcan-v1/src/example.ino

Estratto da "https://www.raspibo.org/wiki/index.php?title=Gruppo_Meteo/CanBus&oldid=7323"