How does a LIN bus slave device behave, if no master is connected?
In my research I noticed, that in LIN version 2.0 every message is initialized by a header frame which is sent by the master device.
For tests I powered a LIN slave device and did not connect any master to the bus. Then I measured the voltage on the LIN bus line with an oscilloscope. And I seems that the slave device is transmitting data.
How can this be explained?
Have you tried to decode the frames? Do they have the break period? sync byte? id? Possibly this is a master, not a slave.
That is not possible, i mean a slave cannot start the communication.
The master has to send first a Header:
- Sync Break Field (14 Tbit)
- Sync Field (0x55)
- ID field
...and when one slave in the bus detects that this request is for him, then replies, otherwise it ignores the received header.
SLAVE can not transmit data if it does not get ID published by the master. Master must say first ID x please reply, then slave will reply. Otherwise your slave may be designed to keep on answering without request causing collision.
Related
In a LIN simulated slave node, what is the difference between output and linUpdateResponse?
From output docs:
To reconfigure response data of LIN frame. In that case RTR selector has to be set to 0. The LIN hardware responds to the next request of the specified frame with the newly configured data.
So, I can reconfigure the output and next time (real?) hardware should talk I've successfully override it, right?
From linUpdateResponse docs:
Updates the response data of a specific LIN frame.
letting me set data length (dlc) and data content for a specific frame ID.
How are they different and are there examples available? I can't quite understand how to use the latter with the example provided.
For LIN slave nodes, there is not really a difference between output and linUpdateResponse.
Both modify the internal state of the (simulated) slave and change the frame that will be sent the next time the master asks for the frame.
As you have posted, when using output you have the set the RTR selector.
But apart from that, there is no difference.
I, personally, think that linUpdateResponse is more convenient to use.
In my current setup, I have a LIN Master and a LIN slave. The schedule table is unconditional, and never re-negotiated:
Master Frame
Slave Frame
Slave Frame
I'm using physical bus and simulated Master (physical Slave). My goal is to apply censorship to certain LIN frames, in real-time.
For instance, I know that a request from Master (maybe single or multi-frame) will trigger a specific Slave response. I would like to catch this response, say in a CAPL script, perform checks on the content and apply selective censorship to it, so that the frame received by the Master doesn't say what the Slave transmitted in the first place. When no Master request is sent, both Master and Slave keep sending empty frames to fulfill the schedule table.
I can easily "catch" the frame with a non-transparent CAPL, but I'm unsure of how I would re-transmit it.
According to the output() keyword documentation:
To reconfigure response data of LIN frame. In that case RTR selector has to be set to 0. The LIN hardware responds to the next request of the specified frame with the newly configured data.
I don't want to add a delay of one message in transmission. And given the following constraints, I have no idea of how to do this, or if it is even possible with the CAPL API in CANoe:
I cannot foresee when a Master Request is broadcasted;
I know that Slave will reply immediately with acknowledge;
After a time that I cannot foresee, Slave will send additional data that I want to censor;
The Slave reply has to be modified in place and re-transmitted;
The original Slave reply must never reach the Master.
Rejected pseudo-code:
on linFrame 0x01 // <-- slave frame
{
if( payload I'm looking for )
{
// edit payload content
}
output(this)
}
Especially since
The original Slave reply must never reach the Master.
you have to physically disconnect Master and Slave and put CANoe inbetween
You would need a network interface with (at least) two LIN channels - one connected to the master and one connected to the slave - and need CANoe be setup as a gateway between these two channels. I.e. acting as a Master towards the Slave and acting as a Slave towards the Master.
In your gateway implementation you can then do whatever you want with the messages exchanged between master and slave.
Doable but not that much fun.
when sensor manager sends the request to physical process using gate index for sensor device :
send(requestMsg, "toNodeContainerModule", corrPhyProcess[sensorIndex]);
will the physical process receive the request message regardless of the distance with node? or whether the physical process receives the msg or not will depend on the distance?
The physical process has a fixed value and it never changes.
The physical process will always get the message from any node.
Figure 1 of the Castalia manual shows that a physical process module is connected to all the nodes. So when a node sends an OMNeT message to that module, it will be received.
Of course, what will the physical process do with the message and what value it will return, it depends on the specific physical process you implement.
I have a computer (that use as server) and several board with Atmega microcontroller Something like:
The computer connect to board on UART & RS485 (with a USB to RS485 converter)(I have limitation that lead to I could not use ModBus). I want to broadcast a message from server over bus and fetch the ID from of each board (Board ID is 4 digit).
When the boards receive broadcast message and try to send their own ID and the server receive some fake ID and I think it related to Collisions problem when all boards want to send data in one time.
After I search about this problem found a way that put a constant in each board that save a special delay for send data and when board receive broadcast message send ID with that delay...in this way it work fine and I dont see the Collisions but have some problem:
May be the delay number of 2 board be same.
Good way for small count of board.
Extra process when want to install board on bus.
Anybody know with this problem and could help me how to solve this problem with better solution?
You are mentioning Modbus in your question although some of your other stated facts seem to deviate from there (like 4-digit device numbers, and Modbus only has 1-255). Also, Modbus does not support responses to broadcast messages. I thus doubt a bit you are actually using Modbus.
A scheme you could use (and that is classically used in MA networks) would be:
Once a broadcast is received, have the clients scan the bus for responses for a time frame based on its station ID. If your client can see one, have it wait a minimum bus time (the time a module needs to answer your broadcast message based on current bus timing + the round trip for the master acknowledging the broadcast answer) plus an additional time based on its module ID, then go back to (1)
If a client sees the bus unoccupied for the specified time, send back a broadcast answer.
Have the master acknowledge the broadcast response from this client with the shortest possible message.
If a client that has sent a broadcast response does not receive a proper ack, go back to (1)
This is not 100% secure and absolutely not according to the Modbus specification, but could work.
* is a transmission, - is a "wait"
**** (Bus master broadcast)
--------- station 100 waits 100ms
------------------ station 200 waits 200ms
**** Station 100 sends broadcast response
------------------ station 200 sees bus active and waits another 200ms
*** master acknowledges broadcast response of 100
------------------ station 200 sees bus active again and waits 200ms from last seen activity
**** Station 200 has seen bus quiet for 200ms and sends broadcast response
*** master acks brc response of 200
This can take quite a bit of time and needs the waiting times finely adjusted against the transmission time of broadcast responses and response acks, but can work, and actually is implemented that way in a lot of CSMA/CD networks.
It will probably take longer, but here is another way to do it. First, design your protocol so that each command contains (or an can contain) an ID, and boards only respond to commands for their ID. Then, on your host, you would iterate through each of the possible IDs and send a simple command to each of them. If you get a response, you know there is a board with that ID. If you don't get a response after some period of time, you know there is no board there.
I am working on a low latency application, sending udp packets from a master to a slave. The master acts as access point sending the data directly to the slave. Mostly it is working well but sometimes data is arriving late in the slave. In order to narrow down the possible sources of the delay I want to timestamp the packets when they are sent out in the master device.
To achieve that I need a hook where I can take a timestamp right after a packet is sent out.
According to http://www.xml.com/ldd/chapter/book/ch14.html#t7 there should be an interrupt after a packet is sent out but I can't really find where the tx interrupt is serviced.
This is the driver:
drivers/net/wireless/bcmdhd/dhd_linux.c
I call dhd_start_xmit(..) from another driver to send out my packet. dhd_start_xmit(..) calls dhd_sendpkt(..) and then dhd_bus_txdata(..) (in bcmdhd/dhdpcie.c) is called where the data is queued. Thats basically where I lose track of what happens after the queue is scheduled in dhd_bus_schedule_queue(..).
Question
Does someone know what happens right after a packet is physically sent out in this particular driver and maybe can point me to the piece of code.
Of course any other advice how to tackle the problem is also welcome.
Thanks
In case of any network hardware and network driver these steps happen:-
1.driver have a transmit descriptor which will be in format understandable by hardware.
2.driver fill the descriptor with the current transmitting packet and send it to hardware queue to transmit .
after successful transmission a interrupt is generated by hardware .
this interrupt called transmission completion function in driver , which will be free the memory of previous packet and reset many things including descriptor etc.
here in line no. 1829 , you can see packet has been freeing .
PKTFREE(dhd->osh, pkt, TRUE);
Thanks
The packet is freed in the function
static void BCMFASTPATH
dhd_prot_txstatus_process(dhd_pub_t *dhd, void * buf, uint16 msglen)
in the file dhd_msgbuf.c
with
PKTFREE(dhd->osh, pkt, TRUE);