Software Handshake Implementation

[dsabene]

Hello Everyone!

So I have posted about a project I am working on and I believe that I have come a long way. My current obstacle is LIN based programming. My company develops automotive switches that use multiple types of communication. Digital, Analog, LIN, CAN, etc. The tester that I am developing is intended to be able to test any type of switch that we connect to it.

I would like to focus on LIN for this topic. Formerly, we have used NI LIN cards for testing our LIN based switches. What I have done is created a LIN bus using an ATmega32M1 and LIN Transceiver using ATA6662C. This is intended to be the interface from the switch to the computer that will be running our LV test procedures. What I and having trouble with is the actually data acquisition, or "handshake," if you will, between the DUT and the computer. I would like to know what important functionality needs to be written. I am aware that the NI DAQ Cards are much more robust than the specific purposes that I need for my tester.

If there are any NI Application Engineers that have experience with automotive switch testing that are available please let me know!

Dennis

[GiantDeathRobot]

Hello Dennis,

I took a look at your previous thread about the overall application, and I was wondering if you could clarify where exactly you're having the trouble. The functionality of the LIN standard is defined in ISO standard ISO 17987 Part 1-7, and we have some information on it here: http://www.ni.com/white-paper/9733/en/ That standard is what is going to define the functionality that needs implementing. 

What we're really able to help you with is going to be where NI products are involved. Looking at the system diagram you posted in the other thread, that looks to be limited to what's happening on the Latte Panda. Once you get beyond that UART connection, you're working on things we don't have any special knowledge on. 

Also, since Jeff B. is a source of wisdom here in AE, I would like to ask his question of "Why do this?" again. I'm not saying this is a terrible idea, and I'm happy to help out with anything we can help out with, but I did want to point out there are some hidden costs you should consider:

1. Any time you are being paid to work on this goes into the cost of the device. You could be working on other projects rather than taking the time to learn four communication protocols and three programming languages. (If we assume this gets pushed on an intern and it takes them all summer, you're looking at ~$12k in development costs. I'm assuming you're a full time engineer, so let's double the man-hour expense: if you're working on this for three months, that's one $24,000 test machine right there.)
2. From personal experience, putting small quantities of custom boards into a box is expensive! Especially if you want it to be rugged enough to transport reliably. That could take up a lot of the $300 target.
3. What happens when this tester breaks? If this system goes down and production stops, who is going to fix it? (You?) And how much is that going to cost per hour until you can get production started again? (You raise a good point that our cards are more robust... they're also documented, tested, and fully supported by NI Applications Engineering.)

[dsabene]

William,

Thank you for the reply. At this point in the project the money is not an issue. We are done developing the hardware for the PCB. As we move to the software side of the project, there are only a few obstacles that we are having trouble facing. In truth we have many engineers that understand the programming that goes into these switches. The problem is that the company currently uses equipment such as NI PXI systems or other expensive interfacing systems. This is where the project hope to cut costs and it will. Salaries aside and with solid documentation, any engineer that may be eventually involved with this device in the future will be more than able to service it.

Where I am lacking is the knowledge of the EE that is involved (I'm an SE not EE). I understand what needs to happen from a software standpoint, but I am lacking in how the hardware is interacting with the software. I have looked over the reference you made and I am aware of the ISO standard. What would benefit me is if I knew what the DAQ cards were actually doing from a hardware perspective so that I may emulate that in my own device.

William or Jeff, if you could email me at dennis.sabene@marqswitch.com, I think that I could paint a better picture over the telephone.