Is it possible to read the bits directly off the physical ethernet connection interface from a standard computer ethernet interface?
e.g., suppose I want to use the ethernet jack of a laptop as a differential logic probe(using a standard ethernet cable). Could I just potentially write a driver to get at the bits or is there a limit to how low a driver can go?
Essentially does the physical layer just send the bit stream to the device driver or does it do any decoding which will effect the interpretation of the bits or cause the device to malfunction(such using a different encoding scheme).
I guess what it boils down to, is, can we use the ethernet port as any standard digital differential communications link by writing a suitable driver or are we limited to the the ieee spec(8b/10b, etc...).
To answer shortly, probably not.
Here are some of the reason why:
On a hardware link layer, there is actually no electrical connection between the computer and the ethernet cable, it is electrically isolated by small transformer and is current and not voltage driven signal, so this will be the first problem to overcome, as you would have to send a fairly precise current over two lines rather than a voltage on a single line.
Ethernet transformers
PHY Hardware Interface: Then the next step, is that this is simply not controlled by the CPU where your code is being executed but by an ethernet PHY Chip interface, and there you have no (easy) way of flashing and controlling it. Some different PHY chip allows you different level of access, but I doubt you would find any that would allow you direct control over the transmission interface and even if it did, it would have to be implemented into the driver which is as well unlikely.
Ethernet PHY Controller
Perhaps some other solutions
as the comments above, if you want to have direct IO control on a computer, the best solution is over a serial or parallel port, perhaps you can find ethernet to serial or usb to serial port and then play with that but this would be digital signals.
Another thing you may want to use is the microphone input, as this accepts analog signals and you can have direct control over it, though be careful not burning your computer. (I've seen some bank card magnetic band using that on cellphones).
You can use libpcap/WinPcap to do this. Nevertheless you are not completely free in the choise of what you write/read on the wire. e.g. preamble and SFD must stil be there. This is so fundamental (because of noise resistance), that typical hardware just does not support anything different.
If you want to control completely everything, go to embedded hardware, find a board that uses a PHY that can give you that information and a processor that is capable of handling the data rates.
Related
I'm trying to establish Modbus RTU connection (for learning purposes) between two PC's (Win10). I'm using two USB to RS485 converters (D- connected together and D+ also connected together). This converters are connected to USB2.0 ports.
USB to RS485 converter
So I'm using "Modbus Poll" and "Modbus Slave" from "modbus tools".
First computer act as slave and has the following settings:
Slave configuration
Slave definition
Second computer act as master and has following settings:
Master configuration
Master definition
And my problem is, everytime i get "Timeout error":
Timeout error
So, what I'm doing wrong? I'm pretty sure converters are not damaged, because Win10 detecs them.
After all I just want to send simple value to another computer (via Modbus RTU) :)
Thanks
Well, this is not a real answer but I can provide some debugging suggestions.
In the past, I had problems with that RS-485 hardware you're using. It didn't work and I'm not sure why. The one I have uses a strange logic to drive DE pin of the MAX485. If I remember correctly, it inverts the TX line coming from CH340G using a NAND gate and feeds it to DE pin. I'm not sure if it was the problem, but I don't think it's a good design.
You may need pull-up and pull-down resistors on RS-485 lines to prevent it from floating when no driver is driving the bus. Some converters include them internally. Also, you may need 120 ohm termination resistors on both ends.
Instead of working with RS-485, you can simply use TTL logic for testing purposes. Use two USB-TTL converters, connect TX to RX (cross connection).
When debugging communication buses (USART, SPI, I2C etc.) always use logic analyzers. Even the cheapest one saves hours of debugging time.
you need to install proper drivers. I used following link which includes a how to video as well as download link for the drivers . Also disable RTS as its 2 wire RS485 so RTS cant be used.
I'm building a HIL/SIL test with Simulink, which tests the Vehicle Control Unit(VCU) from a vehicle. This VCU talks with a Power Distribution Module(PDM) over a J1939 CAN network. The PDM handles the in- and outputs from switches and to actuators and puts the information on the CAN bus. The VCU then knows what the PDM is seeing from connected sensors. In turn, the VCU puts info on the CAN bus on how the PDM should control the connected actuators.
My laptop is hooked to the same CAN bus with a Vector adapter and Simulink.
To test the VCU, I need to mimic the PDM and send messages to the VCU as if I were the PDM. The VCU then has to take the correct actions and control the real PDM accordingly.
Obviously, if I just mimic the PDM, my messages will interfere with those sent from the real PDM. So basically, I need the PDM to shut up and only listen. I do the talking for the PDM. However, the PDM is not configurable in a listen-only mode, so I have to intercept all messages it sends so they never arrive at the VCU.
My idea was that i'd detect(by observing the arbitration field of all messages) when the PDM starts sending, and pull a bit down in the arbitration field. It'd recognise the priority of my 'message' over its own, and it'd stop transmitting. It'd be as if the CAN bus is always to busy to give room to the PDM. This would shut up the PDM without it throwing errors. But other suggestions are welcome.
So (how) is it possible to intercept J1939 CAN messages in MATLAB/Simulink, or with a separate CAN controller?
Here is an idea, how to realize what you are looking for. You need some extra hardware, however.
This is the rough outline:
Setup a CAN-gateway device, which has two independent CAN-interfaces can0 and can1.
Disconnect the PDM from the CAN-bus and connect it to one of the interfaces of your CAN-gateway, e.g. can0
Connect the second interface of the CAN-gateway, can1, to the original CAN-bus, which also includes your laptop and the VCU
Program your CAN-gateway to forward all incoming CAN-frames on can1 to the can0 interface
As you want to ignore all messages from the PDM, simply ignore the CAN-frames coming in on interface can0 and not forward them to can1
Example, how to realize such a CAN-gateway:
Hardware: Use a Raspberry Pi and a CAN extension board with two can-interfaces, such as the PiCAN2 duo board.
Software: Write a small program to forward traffic between the interfaces can0 and can1, using socketcan, which is already included in the Linux kernel.
In case your devices are communicating via the higher layer J1939 transport protocol, you might also need to get the J1939 transport protocol running on the Raspberry Pi. If you are simply using 29-bit indentifiers with a maximum payload of 8 byte of data, this should also not be necessary.
Alternatively, you could also use a more expensive commercial solution, this CAN-Router for example.
Your original idea:
I think what you are envisioning is technically feasible, but might have some other drawbacks.
As the drivers of can controllers typically don't expose interfaces to interactively manipulate CAN-frames while their transmission is still ongoing, you could directly address a can-transceiver from a microcontroller
A few researchers realized a CAN Denial of service attack by turning the first recessive bit in a CAN-frame after the arbitration ID into a dominant bit for certain selected CAN-IDs. They used an Arduino Uno and a Microchip MCP2551 E/P CAN transceiver. The code used is also available online. As this interactive manipulation of CAN-frames during transmission is related to what you are looking for, this could be a good starting point for you.
Still I see some drawbacks, when you silence the PDM this way:
You will not only silence the PDM this way, but also (at least) delay the transmission of other nodes on the CAN-bus with arbitration IDs that have
lower priority than the messages from the PDM
It is very likely that the PDM will go into some error state, when it is not able to successfully send its CAN-frames to the bus after a certain number of retries
Yet another idea:
In case you are able to adapt the software of the VCU, change it in a way that it does not consume the CAN-frames from the PDM, but CAN-frames from your laptop by using different CAN-IDs for the same messages. You will have to change the dbc-file for that purpose.
Many STM32 chipsets support 1 or 2 channel CAN PIN Outs.
Is there a CAN bus library for STM32 to direct connect with a CAN transceiver such as MCP2551? But it does not matter what the CAN transceiver is.
A CAN transceiver is just a high speed step down converter. (on a basic level)
CAN protocol works in a variant of voltage ranges. MCP2551 is a set CAN transceiver suitable for 12V and 24V systems. With added features to help with the physical layer like externally-controlled slope for reduced RFI emissions, detection of ground fault, voltage brown-out protection, etc.
It has no dependency on the CAN logic. It is just to help you with the bare physical layer.
To answer your question:
As RishabhHardas recommended, use the HAL library provided by STM32 through CubeMx.
Using CubeMx
This is a software provided by ST-Micro to help you setup the boilerplate code for any peripheral application.
You can also check out the examples projects provided by STM in the Cube. This will give you a kick-start in understanding CAN on STM32
STM32Cube_FW_F4_V1.9.0\Projects\STM324xG_EVAL\Examples\CAN\CAN_Networking
After setting it up, you'll be able to call HAL_CAN_Transmit() and HAL_CAN_Receive() by including the header.
Check out this discussion on STM32-Community.
For software, look for the CANtact open source project on Github. It is an implementation for the STM32F042. I had to adapt the project to build it under Atollic but it was not too hard and it works. It provides a SLCAN type of interface over a virtual COM port over USB, which is very fast and convenient.
There is also CAN code for the STM32F103 (Bluepill) (Google "lawicel-slcan") but that chip is not as convenient because you cannot use both CAN and USB at the same time (they share RAM buffers) so if you want CAN, you will not have USB, and routing the CAN messages over a UART will severely limit the bandwidth. That may be OK if your entire application runs on the STM32.
I'm interested in interfacing an STM32-based flight controller with external sensors based on the SPI (Serial Peripheral Interface) protocol. I have a couple of FCs (Flip32 F3, shown in attached photo; EMAX Skyline 32) that have a section of pins marked 5V/GND/RST/SCK/MISO/MOSI, which I presume are there to support ISP (In-System Programming); i.e., these pins allow the FC to act as a slave device for a programmer device that acts as the master. Other boards, such as the multiFlite NANO-B-FC, provide pin headders explicitly for SPI (other attached image), with CS (Chip Select) instead of RST.
Am I correct in these assumptions: i.e., the first kind of pinout (RST/SCK/MISO/MOSI) does not support an external SPI sensor, and the latter (CS/SCK/MISO/MOSI) does?
Flip32 F3 flight controller; ISP pads upper-left:
MultiFlight Nano-B flight controller pin header schematic:
I don't know these boards, just had a look at some pics on the internet.
The Flip32 F3 seems to have an Atmel ATMEGA microcontroller on board. (as an auxiliary MCU) I would assume that the 6 pins you found are the ISP interace for that MCU.
Just use a multimeter in continuity test mode and check if the 6 pads are connected to the ISP pins of the ATMEGA.
The board's main MCU STM32 is more likely programmed through the SWD (serial wire debug) interface. That's a pin-reduced JTAG alternative. Just google for it.
Here are some details if you are interested in Atmels ISP:
http://www.atmel.com/images/doc0943.pdf
If the firmware supports it (or you write one that supports it) you should be able to use the ISP interface as a normal SPI interface which it basically is.
ISP is usually done through a simple serial interface like JTAG, SWD or in the AVR case SPI.
Best way to find out: Read the datasheet of your ATMEGA.
I want to build a microcontroller-based CAN node card that has interfaces like UART, SPI and I²C, to which connect different peripherals and interfaces, like say a EIA-485 counter or a SPI digital I/O expander. I'd like to define a profile for the card that's flexible enough to adapt to any possible configuration and include any device that can be connected to such node card. Since CANopen profiles seem to be pretty rigid, I researched CANopen virtual devices but that seems not the answer either.
Is there a standard for such functionality or I'm sailing unknown waters?
You are sailing unknown waters unless you consider a CANopen bootloader a possible solution. There is no existing device profile that fits your criteria. CANopen is remarkably flexible but arbitrary extensibility is beyond it.
You could export the registers of your microcontroller 1:1 through the object dictionary and issue interrupts through PDOs. It would certainly be a fun exercise if just a bit impractical.
From the CAN in Automation website:
CANopen generic I/O modules are standardized in the CiA 401 device
profile specification. The profile supports a granularity of 1-, 8-,
16-, and 32-bit for digital I/Os and a resolution of 1-, 2-, and
4-byte for analog I/Os.
However, it may be easier to implement a custom device, based on the general CiA 301 CANopen application layer and communication profile standard. You could implement a set of general purpose IOCTL functions using Manucturer objects (2000h to 5FFFh) and possibly use SDO Block Transfer to 'stream' data to specific OD objects representing connected device end points.
You will need to consider that, even with a bitrate of 1 Mbps at the physical layer, the CANopen protocol is never going to be able to keep up with a USB2 HS device when it comes to streaming data! Also bear in mind that if you use PDOs for 'real-time' exchange of OD values there will be a significant lag and that the time quantum for PDO exchange is in the order of 25 ms or greater.
The final consideration is what CANopen master are you going to use? If the product is to be commercially available then you will need to specify and document your EDS very carefully (maybe even providing an OPC or similar API).