I'm testing a mcu PIC in ide ccs, in loopback mode. But when I send a message, can see it in can-bus.
The datasheet says:
The Loopback mode is a silent mode, meaning no messages will be transmitted while in this state (including error flags or Acknowledge signals). The TXCAN pin will be in a recessive state.
at read the register CANSTAT, I see in bit 7-5(OPMODE) - 010b, which means the operation mode is correct, but the loopback not silent.
where am I wrong in this?
Related
Let's talk about Windows user program A, which uses sockets to communicate with the server.
Question a) In summary, when a packet arrives at the LAN card, is there a technique for the driver or kernel to automatically write the packet value to process A?
Actually, while analyzing the actual program A, program A was completely suspended or frozen through the Windows task manager or debugger.
After that, the server sent a packet and I checked the packet through Wireshark.
After that, while checking the memory value of process A through the debugger, the packet received from Wireshark was found in the data area of process A.
(Program A is not connected wiath Windows services or other processes at all, I checked all the parts and only the fundamental question a) remains.)
I used x64dbg, windbg and wireshark.
I am using a Zebra DS457 Scanner to read bar and qr codes via COM-Port (RS232). In my test evironment I used a MSI terminal with Win10 and it worked on the real COM-Port without any problems. But on other devices (Win10 and Win7) there are some issues that the software trigger does not come through and the read information do not get sent back to the computer. When I am using a USB to RS232 FTDI adapter I have no issues at all. But why? First I thought it is Win10 and the legacy support could be better, but the adapter is on all devices better and faster. How is this possible? Maybe a driver specific thing? I am using this adapter link to conrad.de.
An FTDI serial port will impose a minimum latency between the time a character arrives over the wire and when an application can see it, and between the time an application wants to send something and the time it goes over a wire. On older devices, these latencies were a minimum of 1ms each, but I think some newer high speed devices have reduced them to 125us. Further, data which arrives at just the wrong speed sometimes ends up with hundreds of milliseconds of additional latency, for reasons I don't quite understand.
On the other hand, an FTDI device can buffer 256 bytes of data from the wire, or 128 bytes of data from the USB port to be sent over the wire, and process RTS/CTS handshaking, without any software intervention--abilities which are lacking in the UART chips used by PC serial ports. If software gives 128 bytes to an FTDI device, it will start sending it until the remote device deasserts its handshake line, whereupon the FTDI device will stop sending as soon as the current byte is complete; it will then resume transmission as soon as the remote device reasserts handshake. If an FTDI device receives enough data over the wire that its UART would be in danger of overflowing, it will automatically deassert its handshake output without requiring any software intervention. The UART used in PC serial port, by contrast, requires a fast interrupt handler to control or respond to the handshake wires. If an interrupt handler maintains a 4096-byte buffer, it may deassert the handshake wire once that buffer is 75% full, but nothing would deassert the handshake wire if the buffer is less than 75% full and 17 bytes arrive over the wire in quick succession before the UART interrupt handler. Worse, if transmit buffering is enabled, and the PC has fed 16 bytes to the UART for transmission when the remote device deasserts its handshake line, those 16 bytes will be sent out whether or not the remote device is ready to receive them (and based upon the handshake wire, it very well might not be).
Thus, some applications can work much better with an FTDI UART, and some much better with an actual serial port.
I have connected a PiCAN2 board with raspberry pi running latest Jessie. When I try to send some CAN messages to my PC ( PC is connected via a USB to DB9 CAN interface to the PiCAN2 board) through this PiCAN2 using the can-utils, it runs into ERROR-PASSIVE state as soon as I bring the CAN interface up. But, when I enable loopback mode, I am able to send messages and receive them using two different terminal window on the raspberry pi itself. I enabled loopback mode using
sudo /sbin/ip link set can0 type can bitrate 500000 loopback on.
Can some one tell me more about the loopback mode? I want to make sure that my hardware setup for PiCAN2 is correct. Is it possible to confirm that my CAN board is configured correctly because I can send/receive messages using loopback mode?Or this doesn't necessarily mean that it is correct?
I also want to know why I get the ERROR PASSIVE mode - does it indicate that the PiCAN2 is not configured correctly OR does it mean that my USB to DB9 CAN interface has some problem? I am new to this area and any help would be nice. Thank you.
I'm going through the probe function of the following driver
/drivers/net/ethernet/smsc/smsc911x.c
Inside the probe function it has been commented that
/* Ensure interrupts are globally disabled before connecting ISR */
smsc911x_disable_irq_chip(dev);
retval = request_irq(dev->irq, smsc911x_irqhandler,
irq_flags | IRQF_SHARED, dev->name, dev);
But I don't see it is TRUE in case of every other device driver ,so why it is in case of this particular Network driver?
Why interrupts are globally disabled before connecting ISR?
The comment says that the interrupts are disabled globally; but as in the function call below, the interrupts are disabled only for the device smsc driver attaches to. This is normally done to avoid getting interrupts well before driver preparing itself for processing interrupts. Since this is for an Ethernet driver, interrupts are enabled most likely during interface up.
The code snip in question gets executed during module load which is well before the interface up.
I have written a custom PLB core for my design, and added interrupt functionality during custom core generation. Interrupt generation logic is designed in custom peripheral. For interrupt control, I added XPS interrupt controller (v2.01a) to the system and connected my custom core's interrupt ports to INTC via master bus. However, as I need to connect IRQ output of INTC to Interrupt input of Microblaze (v8.40), I cannot connect those two ports using Ports tab of System Assembly View, there is no connection option except external port and core's itself. I tried to do it manually on .MHS file, but still I cannot see IRQ and Interrupt ports connected in Graphical Design View. Besides, in Bus Interfaces tab of Assembly View, I can see INTERRUPT port of Microblaze but again, no change can be made.
Use AXI_INTC insteed of XPS_INTC and it should work.
There you will find two bus :
AXI BUS
INTERRUPT BUS.
You will be able to connect the interrupt bus to your MicroBlaze component