There's one thing in CAN 2.0B specification which I'm not sure if I understand correctly.
In chapter 8 - Fault Confinement - there are following rules regarding modification of error counters:
Rule2: When a RECEIVER detects a 'dominant' bit as the first bit after sending an ERROR FLAG the RECEIVE ERROR COUNT will be increased by 8.
And
Rule6: Any node tolerates up to 7 consecutive 'dominant' bits after sending an ACTIVE ERROR FLAG, PASSIVE ERROR FLAG or OVERLOAD flag. After detecting the 14th consecutive 'dominant' bit 9in case of ACTIVE ERROR FLAG or an OVERLOAD FLAG) or after detecting the 8th consecutive 'dominant' bit following a PASSIVE ERROR FLAG, and after each sequence of additional eight consecutive 'dominant' bits every TRANSMITTER increases its TRANSMIT ERROR COUNT by 8 and every RECEIVER increases its RECEIVE ERROR COUNT by 8.
So does rule2 mean that if node A sends an error frame and after sending 6 dominant bits (error flag) it detects that next bit is dominant it should increase its RECEIVE ERROR COUNTER? I thought it's OK that there might be more than 6 dominant bits in error flag (6 to 12 to be precise)... Also, rule6 says " Any node tolerates up to 7 consecutive 'dominant' bits after (...) "
Rule6 also says about sequence of 8 consecutive dominant bits. But for what exactly is this rule applying? Only for such sequences which comes after initial transmission of an error frame?
Let's have an example:
Node A sends an error frame, other nodes start to send their own error frames.
Node A sends 6 bits of its error flag, then detects 7th dominant bit (increase counter? - rule2)
Then we have another 6 dominant bits and after the 14th dominant bit node A increase its error counter again (first part of rule6).
Then we have another 8 dominant bits - node A increases its error counter again (second part of rule6).
Am I correct? I'm so confused with these rules and I need to understand them thoroughly. Hope somebedy will help me :)
Related
enter image description hereI have a question. I am using CANoe Simulation tool.
I know when a Error frame occurs. I heard that Error Frame condition is Transmit Error Count Should be
greater than 127.But first of all, On Screen Capture, An error frame occurs even though it is less than
What is the reason? and, Transmit Error Count 7 means consecutive dominant value error?
I want to clarify that ECU can't receive HU_DATC_E_03 Message because of Error Frame.
Please Help me
enter image description here
You got it backwards: functioning CAN nodes are always allowed to send error frames. Until the counter reaches 127, the node is in "error active" mode. Which means that the node is allowed to actively send error frames.
Beyond 127 it goes "error passive". This means that it is no longer allowed to send error frames, because the node is considered broken and should not be allowed to disrupt bus traffic any longer. It may still listen to the bus but not actively participate.
I don't know this specific tool, but tx error count supposedly just means that the tx error counter has reached the value 7 - that is, there have been 7 failed attempts to send a frame, for whatever reason. It shouldn't have anything necessarily have anything to do with bit stuffing (and CAN bit stuffs after 5 data bits, not 6 as some other networks do).
If you have a sequence of bits in CAN data:
011111000001
There will need to be a stuffed 0 after the ones, and a stuffed 1 after the 0s. But I'm not sure where the 1 should go.
The standard seems ambiguous to me because sometimes it talks about "5 consecutive bits during normal operation", but sometimes it says "5 consecutive bits of data". Does a stuffing bit count as data?
i.e.
should it be:
01111100000011
Or
01111100000101
Bit stuffing only applies to the CAN frame until the ACK-bit. In the End-Of-Frame and Intermission fields, no bit stuffing is applied.
It does not matter what is transmitted.
It is simply "after 5 consecutive bits of the same value" one complementary bit is inserted.
The second of your examples is correct. 6 consecutive bits make the message invalid.
From the old Bosch CAN2.0B spec, chapter 5:
The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing.
Meaning everything from the start of the frame to the 15 bit CRC can have bit stuffing, but not the 1 bit CRC delimiter and the rest of the frame.
Whenever a transmitter detects five consecutive bits in the bit stream to be transmitted
This "bit stream" refers to all the fields mentioned in the previously quoted sentence.
...in the actual transmitted bit stream
The actual transmitted bit stream is the original data + appended stuffing bit(s).
Almost a month ago I started working on a digital communications project
which involves GNUradio.
And I am severely struggling to get past some errors or mismatches I am
encountering in GNUradio.
I am desperately in need of some expert help.
I made a DQPSK modulator and demodulator using just GNURADIO companion.(screenshots provided)
Gave a vector source with bits 0,1,0,1 and repeat on, on the input of
PSK modulator.
I also used an error rate block to calculate bit error rate.
(Vector source is on ref of error rate block and DQPSK demodulator output is on input).
I have connected wx gui scope to error rate block and constellation sink to PSK modulator.
Now almost everything that is appearing on the scopes is completely
wrong.
The bit error rate is 0.5, provided that I have added no noise (which is
max considering that we will recover 50 percent bits correctly just by
chance).
The scope connected at the PSK modulator output shows four constellation points
Even though I am transmitting only one symbol i.e (0,1).
What am I doing wrong?
Can someone please be kind enough to go through the screenshot and tell
me the mistake(s).
As Timothée Cocault said in his answer to your mail on the gnuradio-discuss#gnu.org mailing list:
Hi Haaris,
The documentation of the PSK Mod says : "The input is a byte stream
(unsigned char), treated as a series of packed symbols. Symbols are
grouped from MSB to LSB." You should add an "Unpacked to Packed block"
with 2 bits per chunk and MSB endianness before. Likewise, you should
add a "Pack K bits" block with K=2 after the PSK Demod.
Also, your assumption that you should have one point in the
constellation sink is wrong. You're using DQPSK so the (0, 1) symbol
will add 90 degrees to the phase, and you will cycle through the 4
points of your constellation.
And last, keep in mind that each block has a delay, and you can't
compare the input and output bits directly. Try to use a "Scope plot"
with 2 inputs, and add a delay block before the input bits to
synchronise the two.
Timothée.
I have read already lot of specs and code about UART, but I cannot find any indication on how to find by software interface if the transmit FIFO is full. There is an interrupt when the FIFO is empty. Then I can write at least N characters, where N is the fifo size. But when I have written these N characters, a number of them have already been sent. So I can in fact write more than N characters, but there is no FIFO full interrupt. The specs says that when the fifo is full indeed the TXREADY pin on the chip is inverted. Is there a way to find this by software ? The Line Status Register bit only says that the fifo is not empty, which does not mean it is full...
Anyone can help ? I want to write characters until the fifo is full...
Looks to me also that they neglected this, but most people get by with the thing as it is. The usual way to use it is to get an interrupt, fill the FIFO (normally very fast compared to serial data rate) and then return.
There is a situation where it seems to me that what you are asking for could be nice...if transmitting in a polling mode...you want to send 10 bytes, your polling shows the FIFO is not empty, so you have not way to know if you can send them all or not...either you wait there until it is empty, which sort of defeats the purpose of the FIFO, or you continue polling other stuff until you get back to checking for FIFO empty, and maybe that slows your overall transmission rate. Guess it is not a very usual way to operate, so nobody worries about it.
The 16550D datasheet says the following:
The transmitter holding register interrupt (02) occurs when the XMIT
FIFO is empty; it is cleared as soon as the transmitter holding
register is written to (1 to 16 characters may be written to the XMIT
FIFO while servicing this interrupt) or the IIR is read.
This means that when the Line Status Register register (port base + 5) indicates Transmitter Empty condition (in bit 5), the transmit FIFO is completely empty and you may write up to 16 bytes to the transmitter holding register (port base + 0). It is important not to write more than 16 bytes between occurrences of the transmitter empty bit being set.
If you don't need to write 16 bytes at the point when you received the IRQ (or saw the transmitter register empty bit set, if polling), you can either keep track of how many bytes you wrote since the last transmitter empty state, or, just defer writing further bytes until the next transmitter empty state.
I have a question about the A20 gate. I read an article about it saying that the mechanism exists to solve problems with address "wraparound" that appeared when newer CPUs got a 32-bit address bus instead of the older 20-bit bus.
It would seem to me that the correct way to handle the wraparound would be to turn off all of bits A20-A31, and not just A20.
Why is it sufficient to only turn off bit A20 to handle the problem?
The original problem had to do with x86 memory segmentation.
Memory would be accessed using segment:offset, where both segment and offset were 16-bit integers. The actual address was computed as segment*16+offset. On a 20-bit address bus, this would naturally get truncated to the lowest 20 bits.
This truncation could present a problem when the same code was run on an address bus wider than 20 bits, since instead of the wraparound, the program could access memory past the first megabyte. While not a problem per se, this could be a backwards compatibility issue.
To work around this issue, they introduced a way to force the A20 address line to zero, thereby forcing the wraparound.
Your question is: "Why just A20? What about A21-A31?"
Note that the highest location that could be addressed using the the 16-bit segment:offset scheme was 0xffff * 16 + 0xffff = 0x10ffef. This fits in 21 bits. Thus, the lines A21-A31 were always zero, and it was only A20 that needed to be controlled.