V7 PIC LIN Components

[the_hun]

Greetings,

I would like to write a short plea for the return of PIC LIN support in Flowcode V7.

Before I get into the details though, I would like to admit that part of the reason I am posting today is because Flowcode has been such a great tool for me that I simply stopped coding in C for years and thus I have lost a lot of my peripheral software development skills.

In my work I do custom automotive projects and product development that requires me to wear many hats (from industrial design, electrical/mechanical engineering to firmware development) and thus I don't have the "luxury" of becoming fully proficient in programming advanced peripherals on the PIC. Initially, this presented a lot of challenges (mostly due to lack of time), but when I "discovered" Flowcode (back in the V4 days), suddenly I was able to drastically cut down on my software related work thanks to the convenience of using the ever expanding list of components. This allowed me to spend more time on other parts of the product development as well - which in turn helped me to complete my projects on time.

OK, back to the point:
About 8 months ago I laid down the ground work for a mixed CAN/LIN automotive project for a client as I felt comfortable about delivering the design on time based on the fact that Flowcode had both protocols supported via components.

After that I had some other work to finish while waiting for the customer to get ready with their requirements and thus I have not noticed that when I made the leap from V6 to V7, the LIN support had disappeared. (In my desperation I did search this forum about the topic and found the posts related to the challenges that the LIN component pair had faced, but could not find any solid information about if/when it would be supported again.)

Now, my client is ready with their wish list and thus I need to dive into the work... focusing on the CAN part of the project for now. However, within a month or so, I will need to start showing some progress on the LIN side as well - which will definitely going to be challenging without the LIN master and slave components.

A few details about the project:

Devices:
- PIC12F683 (and/or PIC12F615) coupled with an external MCP2021-500 LIN transceiver,
- PIC16F1829LIN

Usage:
There will be only basic messaging implemented (a handful of slave nodes reading switches and driving LED-s) with no auto addressing or other special diagnostics feature support.

If possible, please let me know if LIN will return anytime soon into V7 as this project will be my main bread winner this year... and perhaps for some time to come.

Thank you much in advance.

Kind regards,
Jonathan

[EtsDriver]

This bothers me as datasheet states that the LIN is included in Comms pack A... I'll double check this when i get to my computer if nobody else is faster...

[the_hun]

Thanks for the reply, EtsDriver,

I have checked again and could not find the LIN master/slave components anymore under 8-bit PIC-s. For sure they were there in Version 6, but I cannot see them anymore in V7.1.1. I am attaching the screen shot of my COMMs window. If you would please scroll through it and let me know if I had missed something.

Thanks again...

FC_V711_PIC_8_bit_COMMs.jpg

V7.1.1 COMMs window. MCU selected: PIC18F4685

(77.29 KiB) Downloaded 453 times

[Benj]

Hello,

The LIN components in v5 and v6 were very device dependent and clock speed dependent and also were not compatible with the latest LIN standard 2.1.

We may have another go at them for v7 however they were very seldom used and highly problematic due to the problems listed above hence the reason they were removed.

A better option would be for us to make a version based on the newer microcontrollers with upgraded hardware UARTs specifically designed for LIN comms rather then trying to bit bang the bus but again this is a lot of work for a component that is rarely used.

Here is the current versions re-packaged for v7, just drop them into your "Flowcode 7/components" directory.

LinMaster.fcpx

(10.09 KiB) Downloaded 334 times

LIN_Slave.fcpx

(12.34 KiB) Downloaded 329 times

Let me know how you get on.

[the_hun]

Hello Benj,

Thank you so much for the detailed explanation and for the components!

Sorry for the late reply, but for some reason I did not get a notification of this latest message and I was "happily" coding away 7 days a week for the last five months on the project. Luckily, the customer threw in some more items that took precedence so I was not yet cornered by the LIN issue yet, but now it is time to take the dust off of it and get going on the concept design.

For sure I'll try these and will let you know the outcome and will be happy to play guinea pig if needed.

Yes, it is correct that LIN is not used as often as CAN, but in the automotive field that I am in, it is becoming quite popular when reading switches and such as its hardware implementation is much simpler (and thus costs less $$$) than CAN.

Thanks again! Really appreciate it,
Jonathan

[the_hun]

Quick side note about the lack of email notifications: ISP's spam filter suddenly reclassified all mail from this forum as bulk and thus they were going into a black hole. All fixed now...

[Jay Dee]

Just to throw my two cents in..
Sounds like my role is similar to Jonathan and as another engineer in automotive, LIN would be good.
My last potential LIN project was unfortunately LIN2.0 and could not get the device to work with the V6 component.
My typical PIC target of choice was/is the ECIO40P but I'm in the process of migrating a few projects to the newer ECIO dsPIC 16, and the good news is the UART does cater for LIN/J2602 protocol.
A LIN component is not something I'm expecting to see real or there being a big user base for it, but it would be a great addition if it does.
J.

[Benj]

Hi Guys,

Using a device with auto baud and Lin capabilities certainly makes my life easier. Out of interest are you looking at making a master or slave device, or both?

I've put it on the list to have a bit of an investigation to see if we can do a hardware UART implementation which includes the current LIN standard.

[Jay Dee]

For myself, I would typically be looking to read existing LIN devices, manipulate and send data back out on CAN. So a LIN Master component would be most helpful.
J.

[the_hun]

Great timing, Ben,

On my end, I will be developing both - master and slave devices. And I do I like the idea of passing as much of the processing over to hardware as possible as after looking at the customer's latest requirements I will definitely be leaning towards using more sophisticated PIC MCU-s that have more memory and more I/O.

Not going to as complex of a design as Jay's (mostly due to space restrictions - as in "must make everything as tiny as possible"), but definitely replacing my initial PIC12F series selection with the 16F1829LIN (that has the built-in MCP2021 transceiver) on the slave side and bumping up to an 18F4580 (with the built-in CAN module) on the master side. This will allow the master to be on the CAN bus as well. And who knows, this may open up the road for me to step out of the 8-bit PIC domain.

To get things rolling, I now have a Microchip demo set which includes:

• - A working master device with a pre-written demo code.

• - A couple of working slave devices (some 12F series PIC MCU-s with the MCP2021 and an LED which at least can receive an respond to a couple of messages).

• - A basic LIN analyzer tool that connects up to a PC to sniff around on the bus or to act as an active node.

Now, I am in the process of building up a test node using a PIC16F88 (as I have a few of them laying around and know this MCU quite well) and an MCP2021 transceiver, after which I'll put together a proto board with the 16F1829LIN and the 18F4580.

I have also started to "play around" with the Flowcode LIN components and already have a couple of questions that I would like to ask regarding the functions within the master:

• 1) After initializing the interface {using the Initialize() command} and loading the message contents {via SetData()}, my code is calling SendMessageWithData(). This function call takes three variables: Identifier, DataCount and Checksum. The DataCount looks pretty straight forward, but the other two I am not 100% sure about.
  
  • a) Identifier: will the entry here be just the "protected identifier" or do I need to add the two parity bits to it as well? For example, if I want to send out message ID 0x23, do I enter "0x23" here or do I add the "0x10" parity bit pair to it and enter "0xA3" instead?
  • b) Checksum: I see in the comments that this might be a flag that can be set to "0" for classic message structures or to be set to "1" for the enhanced checksum. Is this a correct assumption or do I actually need to calculate and enter my own checksum value here?
  2) I see that there is a debug function in this master, but not sure if it is something that was designed to be used by end users or by the Matrix team.

Well, this is all I have for today, but more will be coming up soon as I get my proto nodes online.

Thank you again for the support and have a great day to you,
Jonathan

[the_hun]

Oh and one more quick note that I forgot in my previous post:

Ben, please let me know if you have some other devices in mind as well as my schematic work for the slave products have not yet started and thus I can still modify the setup. The reason I am planning on using the 16F1829LIN is because I have to squeeze the circuit board into a small switch housing and thus having the MCP2021 "melted" into the MCU package have saved me some valuable real estate. On the other hand... this project is important enough where if I have to grow the board a bit to have a working LIN solution, then maybe that is what I will have to do.

FYI: I am using some digital I/O and A/D converters in these slaves nodes and update the related data around 20 - 50 times a second using a timer interrupt so besides the LIN, there are no other fancy, time critical processing that I need to be taken care of.

Thanks again,
Cheers...

[Benj]

Hello Jonathan,

1) After initializing the interface {using the Initialize() command} and loading the message contents {via SetData()}, my code is calling SendMessageWithData(). This function call takes three variables: Identifier, DataCount and Checksum. The DataCount looks pretty straight forward, but the other two I am not 100% sure about.

a) Identifier: will the entry here be just the "protected identifier" or do I need to add the two parity bits to it as well? For example, if I want to send out message ID 0x23, do I enter "0x23" here or do I add the "0x10" parity bit pair to it and enter "0xA3" instead?

b) Checksum: I see in the comments that this might be a flag that can be set to "0" for classic message structures or to be set to "1" for the enhanced checksum. Is this a correct assumption or do I actually need to calculate and enter my own checksum value here?

a) I believe this is just the protected identifier 0x23, the parity bits should be calculated for you.

b) No you don't need to calculate your own checksum the component will do this for you if you pass a 1 as the parameter.

2) I see that there is a debug function in this master, but not sure if it is something that was designed to be used by end users or by the Matrix team.

Hmm it looks like that might have been an internal test function. You can probably safely ignore it.

To get things rolling, I now have a Microchip demo set which includes:
- A working master device with a pre-written demo code.

Are you able to share the code, it might be interesting to see how Microchip are doing it. It's probably publicly available somewhere but Microchip's website can sometimes be a bit of a maze to navigate.

Ben, please let me know if you have some other devices in mind as well as my schematic work for the slave products have not yet started and thus I can still modify the setup. The reason I am planning on using the 16F1829LIN is because I have to squeeze the circuit board into a small switch housing and thus having the MCP2021 "melted" into the MCU package have saved me some valuable real estate. On the other hand... this project is important enough where if I have to grow the board a bit to have a working LIN solution, then maybe that is what I will have to do.

The 16F1829 has the standard auto baud register control bits so I don't see any reasons why it wouldn't work when we get around to re-writing the components to use the hardware UARTs.

[the_hun]

Hello Ben,

Thank you for the quick response.

All clear about the function calls.

OK, about the hardware:

• - Here is the link to the ambient lighting module slave node document - which probably is not so helpful for the actual Flowcode work here, but a great little piece to help folks get off the ground with LIN. I will be using this to test my initial master code as it is simple and easy to see the results on: http://ww1.microchip.com/downloads/en/D ... 51714a.pdf

• - This is the link to the app note that talks about the serial analyzer and the 16F-series demo board's LIN setup. For hardware, it uses the EUSART to drive the MCP2021 and for software, it employ's Microchip's LIN stack: http://ww1.microchip.com/downloads/en/a ... 02059b.pdf

• - And here is probably what you will be interested in most for the future component work. It is the description and the actual code (listed within the document) of their LIN stack: http://ww1.microchip.com/downloads/cn/A ... 00235a.pdf
  It is quite well written, but I am not sure how sophisticated it is as I am not an expert on LIN (which hopefully will change by the time I am done with this project).

And about the 1829LIN. Yes, I just looked at the datasheet some more and it is basically a 16F1829 with some I/O removed and an MCP2021 stuck in the package with the VBATT, VREG, LBUS and FAULT/TXE lines brought out to external pins and the rest of the device is connected via registers to the internal EUSART.
I will look through the datasheet with great detail and will work with you (when time comes) to see what settings may need to be altered with respect to a standard 16F1829 in order to have the bits flowing through the internal MCP2021 chip.

Take care and have a nice day to you,
Jonathan