Difference between revisions of "Universal CAN Modules"

From Electriki
Jump to navigationJump to search
Line 1: Line 1:
 
__NOEDITSECTION__
 
__NOEDITSECTION__
 
== The universal CAN modules ==
 
== The universal CAN modules ==
Ever thought of an application that would be based on asynchronical transmission of short messages? Cool message prioritizing would also be handy? Just add cheap  
+
Ever thought of an application that would be based on asynchronical transmission of short messages? Cool message prioritizing would also be handy? Just add cheap data medium and long bus range with a possibility to add over 530.000.000 ECU nodes to it... Put some of extremely effective error managing ability to the jar as well.
 +
Mix it all together with a lot of other tiny incredients that only make the whole thingie spicier and here it is: [http://en.wikipedia.org/wiki/Controller_area_network The Controller Area Network].
  
data medium and long bus range with a possibility to add over 530.000.000 ECU nodes to it... Put some of extremely effective error managing ability to the jar as well.
+
Knowing all the strong sides of this praisefull technology, a lot of companies base their applications on CAN. The idea was to build universal CAN modules, which would let user either connect any digital device to already working CAN bus (and interfere with it) or build whole new standalone CAN based app as he wishes to. The CAN modules i present here are a bridge between CAN bus and any other digital interface that uses less than 13 data lines directly. Additional I/O expanders, external A/D converters, etc. can of course bring some more funcitonality to the device. But everything in its place...
 
 
Mix it all together with a lot of other tiny incredients that only make the whole thingie spicier and here it is: [http://en.wikipedia.org/wiki/Controller_area_network The
 
 
 
Controller Area Network].
 
 
 
Knowing all the strong sides of this praisefull technology, a lot of companies base their applications on CAN. The idea was to build universal CAN modules, which would  
 
 
 
let user either connect any digital device to already working CAN bus (and interfere with it) or build whole new standalone CAN based app as he wishes to. The CAN  
 
 
 
modules i present here are a bridge between CAN bus and any other digital interface that uses less than 13 data lines directly. Additional I/O expanders, external A/D  
 
 
 
converters, etc. can of course bring some more funcitonality to the device. But everything in its place...
 
  
 
== The hardware ==
 
== The hardware ==
I did the design while i was still studying so economics were the main criteria when thinking of the whole project. Microcontroller was a must. Internal CAN controller  
+
I did the design while i was still studying so economics were the main criteria when thinking of the whole project. Microcontroller was a must. Internal CAN controller would simplify the board. Also debugging interface couldn't be expensive. I browsed manufacturers' sampling offers and [http://www.st.com/mcu/ ST Electronics] had what i needed - the STR712 MCU for free for testing. It has (apart of already mentioned internal CAN controller) whole lot of hardware interfaces builtin (i.e. I2C, BSPI, USART, etc.) so the software part is way easier to manage. Talking of that - ST released it right with a free to use software library - really usable lib for a quickstart (includes all STR712's peripherials management functions coded in C). ARM core guaranties fast data processing for software implemented interfaces (yeah, trully universal modules must allow this as well). Did i already mention the cheapass debugging interface? Yes, DIY JTAG is a ~2EUR thingie here. So ok - the heart has been choosen.
 
 
would simplify the board. Also debugging interface couldn't be expensive. I browsed manufacturers' sampling offers and [http://www.st.com/mcu/ ST Electronics] had  
 
 
 
what i needed - the STR712 MCU for free for testing. It has (apart of already mentioned internal CAN controller) whole lot of hardware interfaces builtin (i.e. I2C, BSPI,  
 
 
 
USART, etc.) so the software part is way easier to manage. Talking of that - ST released it right with a free to use software library - really usable lib for a quickstart  
 
 
 
(includes all STR712's peripherials management functions coded in C). ARM core guaranties fast data processing for software implemented interfaces (yeah, trully  
 
 
 
universal modules must allow this as well). Did i already mention the cheapass debugging interface? Yes, DIY JTAG is a ~2EUR thingie here. So ok - the heart has been  
 
 
 
choosen.
 
  
 
== The prototype ==
 
== The prototype ==
It was my first ARM related project. Also first time i got in touch with CAN. Never used JTAG before. My C experience was less than a basic back then (gained to basic  
+
It was my first ARM related project. Also first time i got in touch with CAN. Never used JTAG before. My C experience was less than a basic back then (gained to basic level already in meantime!). So I decided to build a prototype.
 
+
It was just a simple two-boards set. TQFP64 (and TQFP-more)  to standard 2.54mm soldering grid board attached on top of other universal board via goldpins. The first board only contains MCU, RTC quartz, some caps underneith it and an IDC connector - directly soldered to few controller's I/O's. The latter board has JTAG interface (also IDC conector), PSU, few LED diodes, switches/buttons, potmeter, clock for MCU and CAN transceiver on it. All worked as a charm and i learned  
level already in meantime!). So I decided to build a prototype.
 
 
 
It was just a simple two-boards set. TQFP64 (and TQFP-more)  to standard 2.54mm soldering grid board attached on top of other universal board via goldpins. The  
 
 
 
first board only contains MCU, RTC quartz, some caps underneith it and an IDC connector - directly soldered to few controller's I/O's. The latter board has JTAG  
 
 
 
interface (also IDC conector), PSU, few LED diodes, switches/buttons, potmeter, clock for MCU and CAN transceiver on it. All worked as a charm and i learned  
 
 
 
 
something about what I was just stepping into (thank you JTAG!). Here are some pics of it:
 
something about what I was just stepping into (thank you JTAG!). Here are some pics of it:
 
<gallery widths=176px>
 
<gallery widths=176px>
Line 52: Line 21:
  
 
== The schematics and PCB ==
 
== The schematics and PCB ==
On first picture there's a block schematic of how the module should fit whole CAN application. Each module has PSU, JTAG interface, I/O's connector, clock generator  
+
On first picture there's a block schematic of how the module should fit whole CAN application. Each module has PSU, JTAG interface, I/O's connector, clock generator and CAN transceiver onboard. Latter pics contain idea schematics. Whole circuit is very simple - thanks to a lot of hardware interfaces controllers builtin STR712 chip by ST. It's basicaly just a basic setup to startup the MCU (clock generator, few capacitors and resistors). I added voltage regulators and rectifier-bridge on board, so that i can connect the module in different places (universality, remember?), not caring much about the available supply voltage level/type available in there (please read the bugs section regarding power supplying). I decided for twisted copper pair cable CAN medium (which is most common) so I've put Microchip's CAN transceiver MCP2551 in there as well. Remaining parts are: RTC quartz (see bugs section), voltage-present indicating LEDs, some other LED connected to I/O port for software signalization purposes and connectors. For JTAG i used standard (for the wiggler's clone i've been working with) IDC20m connector. Same was choosen for I/O interface. For power supplies and CAN physical interface i decided to go the screwed terminals way. That way it's (again) easier to fit the existing app's interfaces when connecting to one.
  
and CAN transceiver onboard. Latter pics contain idea schematics. Whole circuit is very simple - thanks to a lot of hardware interfaces controllers builtin STR712 chip by
+
Last image in here is the PCB layout. I wanted it to be as cheap as possible so first i wanted to do it myself. This is why i aimed one-layered board. I managed to fit it on 60x65mm. board with just three short-wires on back of it. I found the [http://prototypy.pl cheap PCB-house] later, so i decided to order nice looking proper PCBs from them. Ordered four boards, got six of them for like 3EUR / piece IIRC. Quality's very good IMHO, so it was good deal.  
 
 
ST. It's basicaly just a basic setup to startup the MCU (clock generator, few capacitors and resistors). I added voltage regulators and rectifier-bridge on board, so that i
 
 
 
can connect the module in different places (universality, remember?), not caring much about the available supply voltage level/type available in there (please read the
 
 
 
bugs section regarding power supplying). I decided for twisted copper pair cable CAN medium (which is most common) so I've put Microchip's CAN transceiver
 
 
 
MCP2551 in there as well. Remaining parts are: RTC quartz (see bugs section), voltage-present indicating LEDs, some other LED connected to I/O port for software
 
 
 
signalization purposes and connectors. For JTAG i used standard (for the wiggler's clone i've been working with) IDC20m connector. Same was choosen for I/O
 
 
 
interface. For power supplies and CAN physical interface i decided to go the screwed terminals way. That way it's (again) easier to fit the existing app's interfaces when
 
 
 
connecting to one.
 
 
 
Last image in here is the PCB layout. I wanted it to be as cheap as possible so first i wanted to do it myself. This is why i aimed one-layered board. I managed to fit it  
 
 
 
on 60x65mm. board with just three short-wires on back of it. I found the [http://prototypy.pl cheap PCB-house] later, so i decided to order nice looking proper PCBs  
 
 
 
from them. Ordered four boards, got six of them for like 3EUR / piece IIRC. Quality's very good IMHO, so it was good deal.  
 
 
<gallery widths=176px>
 
<gallery widths=176px>
 
Image:pitCANidea_bw.png
 
Image:pitCANidea_bw.png
Line 86: Line 35:
  
 
== The ready devices ==
 
== The ready devices ==
Here are some pics i took when i was still working on the demo application. Back then i used rotary encoder attached to one of modules to set LED blink rate on other  
+
Here are some pics i took when i was still working on the demo application. Back then i used rotary encoder attached to one of modules to set LED blink rate on other CAN node. Was quite fun to get to know it actualy works! Few shots present the montage details as well. Screwed terminals for CAN / supply voltage interfaces are accessed from bottom side of boards. Also notice the way i soldered IDC connectors - now I'd (at least try to) use the SMD ones. I also found the thru-hole capacitors way cheaper than those in SMD packages, so... You can see it by yourself. For final look please see the working application section. [link]
 
 
CAN node. Was quite fun to get to know it actualy works! Few shots present the montage details as well. Screwed terminals for CAN / supply voltage interfaces are  
 
 
 
accessed from bottom side of boards. Also notice the way i soldered IDC connectors - now I'd (at least try to) use the SMD ones. I also found the thru-hole capacitors  
 
 
 
way cheaper than those in SMD packages, so... You can see it by yourself. For final look please see the working application section. [link]
 
  
 
<gallery widths=176px>
 
<gallery widths=176px>
Line 105: Line 48:
  
 
== DEMO application ==
 
== DEMO application ==
The main reason why CAN was invented is to simplify car electric installation. I wanted the demo application to be somehow similar to this concept. What i came with is  
+
The main reason why CAN was invented is to simplify car electric installation. I wanted the demo application to be somehow similar to this concept. What i came with is a set of four modules connected to one CAN bus:
 
+
* LCD module - basicaly the main module of whole application. It not only diplays the current time and temperature but also the thermostate's set edge value and operation menu for user. This node also processes the data sent from all other nodes and makes decissions on how the data should be used like. LCD interface was implemented in software.
a set of four modules connected to one CAN bus:
+
* RTC module - sends current time frame (it's set by user via encoder and lcd modules; works by using the internal RTC of STR712) to be displayed on LCD. This module also makes use of onboard LED - it works as an thermostate-simulator: LED glowing indicates thermostate working. I've used ST's library to set up RTC.
* LCD module - basicaly the main module of whole application. It not only diplays the current time and temperature but also the thermostate's set edge value and  
+
* Encoder module - that allows user to interfere with whole application: i.e. setting current time and edge temperature for thermostate. Interface implemented in software: polling.
 
 
operation menu for user. This node also processes the data sent from all other nodes and makes decissions on how the data should be used like. LCD interface was  
 
 
 
implemented in software.
 
* RTC module - sends current time frame (it's set by user via encoder and lcd modules; works by using the internal RTC of STR712) to be displayed on LCD. This  
 
 
 
module also makes use of onboard LED - it works as an thermostate-simulator: LED glowing indicates thermostate working. I've used ST's library to set up RTC.
 
* Encoder module - that allows user to interfere with whole application: i.e. setting current time and edge temperature for thermostate. Interface implemented in  
 
 
 
software: polling.
 
 
* Sensor module - DS18B20 sensor has been attached to this node. 1-Wire interface - i wrote some simple lib for it.
 
* Sensor module - DS18B20 sensor has been attached to this node. 1-Wire interface - i wrote some simple lib for it.
  
Here are some pics. First one shows data flow between nodes diagram. Latter ones are the working app. Iscrewed modules onto plexi board - it looks quite fine if you  
+
Here are some pics. First one shows data flow between nodes diagram. Latter ones are the working app. Iscrewed modules onto plexi board - it looks quite fine if you ask me but have a look yourself. BTW I've also tested UART but i didn't take any pics of it working.  
 
 
ask me but have a look yourself. BTW I've also tested UART but i didn't take any pics of it working.  
 
 
<gallery widths=176px>
 
<gallery widths=176px>
 
Image:pitCANdiagram.png
 
Image:pitCANdiagram.png
Line 169: Line 100:
  
 
== JTAG interface ==
 
== JTAG interface ==
I don't even remember where i found the first schematic of it, but it is really usable and praiseworth thing. The JTAG. Programming IDEs support JTAGs so it's easy to  
+
I don't even remember where i found the first schematic of it, but it is really usable and praiseworth thing. The JTAG. Programming IDEs support JTAGs so it's easy to make it work (open source drivers ar there as well). It allows to upload code to MCU as well as it helps with debugging, especialy at the very beggining, when there's no UART around. Michai gave it a closer look once. [link]  
 
 
make it work (open source drivers ar there as well). It allows to upload code to MCU as well as it helps with debugging, especialy at the very beggining, when there's  
 
 
 
no UART around. Michai gave it a closer look once. [link]  
 
  
 
<gallery widths=176px>
 
<gallery widths=176px>
Line 185: Line 112:
 
Yes, board has some bugs i got to known of already:
 
Yes, board has some bugs i got to known of already:
 
* I 'forgot' to add capacitors between GND and both legs of RTC 36khz quartz, so internal RTC won't work without some soldering under module's PCB.
 
* I 'forgot' to add capacitors between GND and both legs of RTC 36khz quartz, so internal RTC won't work without some soldering under module's PCB.
* CAN transceiver requires %VDC power supply. STR712 requires 3.3VDC to work. There are luckily no problems with transmitting data between those two chips  
+
* CAN transceiver requires %VDC power supply. STR712 requires 3.3VDC to work. There are luckily no problems with transmitting data between those two chips (which i found out while testing the prototype) but board could be simplified (one voltage regulator less on board) if i choosed to switch to 5VDC MCU (yes, there are things like that). The way I did it may not be elegant nor smart but i already had the free-samples chips and i didn't want to throw them away.
 
+
* I had some problems with changing I/O P0's states while working on LCD module of my demo application. Problem was whole port didn't want to change its state on all 13 lines at once. I didn't sniff around too much - just changed the port's value with two instructions (half of lines at a time). Still not sure what caused it.  
(which i found out while testing the prototype) but board could be simplified (one voltage regulator less on board) if i choosed to switch to 5VDC MCU (yes, there are  
 
 
 
things like that). The way I did it may not be elegant nor smart but i already had the free-samples chips and i didn't want to throw them away.
 
* I had some problems with changing I/O P0's states while working on LCD module of my demo application. Problem was whole port didn't want to change its state on  
 
 
 
all 13 lines at once. I didn't sniff around too much - just changed the port's value with two instructions (half of lines at a time). Still not sure what caused it.  
 
  
  

Revision as of 14:05, 27 March 2010

The universal CAN modules

Ever thought of an application that would be based on asynchronical transmission of short messages? Cool message prioritizing would also be handy? Just add cheap data medium and long bus range with a possibility to add over 530.000.000 ECU nodes to it... Put some of extremely effective error managing ability to the jar as well. Mix it all together with a lot of other tiny incredients that only make the whole thingie spicier and here it is: The Controller Area Network.

Knowing all the strong sides of this praisefull technology, a lot of companies base their applications on CAN. The idea was to build universal CAN modules, which would let user either connect any digital device to already working CAN bus (and interfere with it) or build whole new standalone CAN based app as he wishes to. The CAN modules i present here are a bridge between CAN bus and any other digital interface that uses less than 13 data lines directly. Additional I/O expanders, external A/D converters, etc. can of course bring some more funcitonality to the device. But everything in its place...

The hardware

I did the design while i was still studying so economics were the main criteria when thinking of the whole project. Microcontroller was a must. Internal CAN controller would simplify the board. Also debugging interface couldn't be expensive. I browsed manufacturers' sampling offers and ST Electronics had what i needed - the STR712 MCU for free for testing. It has (apart of already mentioned internal CAN controller) whole lot of hardware interfaces builtin (i.e. I2C, BSPI, USART, etc.) so the software part is way easier to manage. Talking of that - ST released it right with a free to use software library - really usable lib for a quickstart (includes all STR712's peripherials management functions coded in C). ARM core guaranties fast data processing for software implemented interfaces (yeah, trully universal modules must allow this as well). Did i already mention the cheapass debugging interface? Yes, DIY JTAG is a ~2EUR thingie here. So ok - the heart has been choosen.

The prototype

It was my first ARM related project. Also first time i got in touch with CAN. Never used JTAG before. My C experience was less than a basic back then (gained to basic level already in meantime!). So I decided to build a prototype. It was just a simple two-boards set. TQFP64 (and TQFP-more) to standard 2.54mm soldering grid board attached on top of other universal board via goldpins. The first board only contains MCU, RTC quartz, some caps underneith it and an IDC connector - directly soldered to few controller's I/O's. The latter board has JTAG interface (also IDC conector), PSU, few LED diodes, switches/buttons, potmeter, clock for MCU and CAN transceiver on it. All worked as a charm and i learned something about what I was just stepping into (thank you JTAG!). Here are some pics of it:

The schematics and PCB

On first picture there's a block schematic of how the module should fit whole CAN application. Each module has PSU, JTAG interface, I/O's connector, clock generator and CAN transceiver onboard. Latter pics contain idea schematics. Whole circuit is very simple - thanks to a lot of hardware interfaces controllers builtin STR712 chip by ST. It's basicaly just a basic setup to startup the MCU (clock generator, few capacitors and resistors). I added voltage regulators and rectifier-bridge on board, so that i can connect the module in different places (universality, remember?), not caring much about the available supply voltage level/type available in there (please read the bugs section regarding power supplying). I decided for twisted copper pair cable CAN medium (which is most common) so I've put Microchip's CAN transceiver MCP2551 in there as well. Remaining parts are: RTC quartz (see bugs section), voltage-present indicating LEDs, some other LED connected to I/O port for software signalization purposes and connectors. For JTAG i used standard (for the wiggler's clone i've been working with) IDC20m connector. Same was choosen for I/O interface. For power supplies and CAN physical interface i decided to go the screwed terminals way. That way it's (again) easier to fit the existing app's interfaces when connecting to one.

Last image in here is the PCB layout. I wanted it to be as cheap as possible so first i wanted to do it myself. This is why i aimed one-layered board. I managed to fit it on 60x65mm. board with just three short-wires on back of it. I found the cheap PCB-house later, so i decided to order nice looking proper PCBs from them. Ordered four boards, got six of them for like 3EUR / piece IIRC. Quality's very good IMHO, so it was good deal.

The ready devices

Here are some pics i took when i was still working on the demo application. Back then i used rotary encoder attached to one of modules to set LED blink rate on other CAN node. Was quite fun to get to know it actualy works! Few shots present the montage details as well. Screwed terminals for CAN / supply voltage interfaces are accessed from bottom side of boards. Also notice the way i soldered IDC connectors - now I'd (at least try to) use the SMD ones. I also found the thru-hole capacitors way cheaper than those in SMD packages, so... You can see it by yourself. For final look please see the working application section. [link]

DEMO application

The main reason why CAN was invented is to simplify car electric installation. I wanted the demo application to be somehow similar to this concept. What i came with is a set of four modules connected to one CAN bus:

  • LCD module - basicaly the main module of whole application. It not only diplays the current time and temperature but also the thermostate's set edge value and operation menu for user. This node also processes the data sent from all other nodes and makes decissions on how the data should be used like. LCD interface was implemented in software.
  • RTC module - sends current time frame (it's set by user via encoder and lcd modules; works by using the internal RTC of STR712) to be displayed on LCD. This module also makes use of onboard LED - it works as an thermostate-simulator: LED glowing indicates thermostate working. I've used ST's library to set up RTC.
  • Encoder module - that allows user to interfere with whole application: i.e. setting current time and edge temperature for thermostate. Interface implemented in software: polling.
  • Sensor module - DS18B20 sensor has been attached to this node. 1-Wire interface - i wrote some simple lib for it.

Here are some pics. First one shows data flow between nodes diagram. Latter ones are the working app. Iscrewed modules onto plexi board - it looks quite fine if you ask me but have a look yourself. BTW I've also tested UART but i didn't take any pics of it working.


I once recorded this clip to present you my work. Michai detected a lot of russian english there... No need for futher comments on this one. Let it be so.

<youtube align="left">YzJDEWbhf6g</youtube>


















JTAG interface

I don't even remember where i found the first schematic of it, but it is really usable and praiseworth thing. The JTAG. Programming IDEs support JTAGs so it's easy to make it work (open source drivers ar there as well). It allows to upload code to MCU as well as it helps with debugging, especialy at the very beggining, when there's no UART around. Michai gave it a closer look once. [link]


Bugs

Yes, board has some bugs i got to known of already:

  • I 'forgot' to add capacitors between GND and both legs of RTC 36khz quartz, so internal RTC won't work without some soldering under module's PCB.
  • CAN transceiver requires %VDC power supply. STR712 requires 3.3VDC to work. There are luckily no problems with transmitting data between those two chips (which i found out while testing the prototype) but board could be simplified (one voltage regulator less on board) if i choosed to switch to 5VDC MCU (yes, there are things like that). The way I did it may not be elegant nor smart but i already had the free-samples chips and i didn't want to throw them away.
  • I had some problems with changing I/O P0's states while working on LCD module of my demo application. Problem was whole port didn't want to change its state on all 13 lines at once. I didn't sniff around too much - just changed the port's value with two instructions (half of lines at a time). Still not sure what caused it.


/Pit