1. Home
  2. Embedded Programming
  3. Faster LIN or simpler CAN or ...? PIC16 or Cypress FX2LP or ...?

Faster LIN or simpler CAN or ...? PIC16 or Cypress FX2LP or ...?

To support various modules inside a machine. The likely architecture is a front end PC talking USB 2.0 to a Cypress FX2LP in the machine. That then splits the control work out to various nodes (spinner, motor, shutter, laser, etc), connected by a bus.

a) CAN involves me in checking each message was received once and only once. There's not a lot of space in the Cypress for that sort of thing.

b) We could use LIN but it seems jolly slow. Would mean a nice simple processor in each node with a little programming and offering some flexibility.

c) We could use a modified form of I2C but that means no intelligence at each node (and no programming, which is quite a good thing, in some ways).

Can I do LIN master in the Cypress FX2 (8051 based with a couple of UART's)?

Is there a reasonably standard way for doing LIN slave? I'd prefer 8051 based (so I can go on using the Keil compiler) or PIC16 (which we have also used).

Any other thoughts (but not too innovative - this is a development project)?

tia,

Bill

Reply to
Bill Davy
Loading thread data ...

How about an SPI bus ? Some of the receivers, such as control pins can be as simple as a shiftregister '595.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

Just design your higher level protocol so it doesn't care if the same message is received multiple time. IE send motor speed absolutely not a speed increment. Set a relay state rather than a toggle etc. Then you can just forget anout the fact that a message can show up multiple times. There are times where you have to care (mostly when abusing CAN to send large amounts of data) but most control messages can be set up so that it doesn't matter.

It's been a while since I looked but doesn't LIN have the same possibility as CAN of receiving the same message multiple times?

Robert

Reply to
R Adsett

Look into the 80C51 9 Bit mode : that sits between CAN and LIN in speed, and is simpler than LIN to code, as you use the inbuilt HW support.

You can use CAN transceivers, on a 9 Bit UART datastream.

i2c has the poorest noise immunity.

LIN has high immunity, because it is large swing, and slow. LIN has very small payloads, and is really for the last-link usage.

CAN is multimaster, and has CRC included, whilst 9 Bit mode is single master, but can use much lower cost silicon.

80C51's with UARTS start well under $1, and in tiny packages, and support data rates higher than CAN.

-jg

Reply to
Jim Granville

Control stuff feom a PC and use of USB throughout? No Central CPU, just some Hubs. AT89C5131 is 8051 with USB

Run a Fast USART : TXD,RXD,SCLK (driven by master) over RS485. This is supported by AVRs and AT91 ARMs. You would need a resonator with each node, but the speed is higher. There are free GNU compilers /AVR Studio for the AVR. ARMs up to 32 kB (AT91SAM7S321) compilers are quite often free of charge (Code restriction

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

We use SPI bus quite a lot but the limiation that it assumed the data arrived to designation, more like datagram. It can be dangerous if there is fault within the SPI bus CAN bus includes protocol that verify the data and send response if damaged, more like telephone (ie you get feedback from other end). The other benefit that it use fewer line than SPI bus.

PIC is very popular, it used everywhere due to excellent technical support, training package, forum and lot of sample program they developed. It very cheap to setup as well. There are limitation in debugging, you cannot monitor local field variable (within C), only the global field variable.

Reply to
Riscy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.