Project:Nanode/Applications: Difference between revisions

From London Hackspace Wiki

Project:Nanode/Applications (view source)

Revision as of 14:55, 21 September 2011

8 bytes removed ,  21 September 2011
m
Fix some "it's"/"its" confusion and other minor edits.
(New MAC address reading code)
m (Fix some "it's"/"its" confusion and other minor edits.)
Line 29: Line 29:
In short  - there are several ways to skin the cat called Nanode.
In short  - there are several ways to skin the cat called Nanode.


Note there are some slight differences,  the LED on Nanode is on Digital 6 rather than Digital 13 on Arduino and it lights when digital 6 is set LOW - so it's sense is inverted - more on why this is later.
Note there are some slight differences,  the LED on Nanode is on Digital 6 rather than Digital 13 on Arduino and it lights when digital 6 is set LOW - so its sense is inverted - more on why this is later.


Nanode uses an ethernet library which was written specifically to drive the ENC28J60 ethernet controller.
Nanode uses an ethernet library which was written specifically to drive the ENC28J60 ethernet controller.
Line 138: Line 138:
===EtherShield Library and Examples===
===EtherShield Library and Examples===


Once you have built your Nanode and got the red flashing LED which shows that all is well with the ATmega328 microcontroller and it's bootloader programme, it is now time to test the rest of the system, which includes the ENC28J60 ethernet controller and its interface through the magjack connector to the ethernet port.
Once you have built your Nanode and got the red flashing LED which shows that all is well with the ATmega328 microcontroller and its bootloader program, it is now time to test the rest of the system, which includes the ENC28J60 ethernet controller and its interface through the magjack connector to the ethernet port.


Conveniently, Andrew Lindsay, has provided some simple example to accompany his Ethershield Library. It is common practice amongst Arduino libraries to provide accompanying tried and tested code examples, which are loaded as part of the library folder.
Conveniently, Andrew Lindsay, has provided some simple example to accompany his Ethershield Library. It is common practice amongst Arduino libraries to provide accompanying tried and tested code examples, which are loaded as part of the library folder.
Line 213: Line 213:
54:55:58:12:34:56  is a made up MAC address - a throwback from the original Tuxgraphics code where 54:55:58: is ASCII for TUX
54:55:58:12:34:56  is a made up MAC address - a throwback from the original Tuxgraphics code where 54:55:58: is ASCII for TUX


Then we initialise the ENC28J60 IC, over it's SPI bus.  If this is successful we will get  
Then we initialise the ENC28J60 IC, over its SPI bus.  If this is successful we will get  


ENC28J60 version 7  (or some other non-zero version number)
ENC28J60 version 7  (or some other non-zero version number)
Line 343: Line 343:
Nanode comes with a version of the LED Blink program already loaded into the ATmega328 microcontroller, done along with the bootloader. When you power up your Nanode for the first time - if all is well, the red LED will begin flashing.
Nanode comes with a version of the LED Blink program already loaded into the ATmega328 microcontroller, done along with the bootloader. When you power up your Nanode for the first time - if all is well, the red LED will begin flashing.


The LED is driven by digital pin 6 - whereas on the Arduino it is pin 13. Another difference is that the sense of the LED is inverted, you need to make the digital output pin LOW in order to bring the LED on.  These changes are because the way in which Nanode handles it's local serial port - and this will be explained in a later section.
The LED is driven by digital pin 6 - whereas on the Arduino it is pin 13. Another difference is that the sense of the LED is inverted, you need to make the digital output pin LOW in order to bring the LED on.  These changes are because the way in which Nanode handles its local serial port - and this will be explained in a later section.


The LED was moved from 13, because pin 13 is in almost constant use by the SPI bus which talks to the ethernet controller.
The LED was moved from 13, because pin 13 is in almost constant use by the SPI bus which talks to the ethernet controller.
Line 407: Line 407:
For this to work - we need a system of bus arbitration, such that there is only one device talking on the bus at any time. In the Nanode, this bus control is done using a pair of tristate buffers, which are left over from the four in the 74HC125 device - where only two were used for the ethernet controller glue logic.
For this to work - we need a system of bus arbitration, such that there is only one device talking on the bus at any time. In the Nanode, this bus control is done using a pair of tristate buffers, which are left over from the four in the 74HC125 device - where only two were used for the ethernet controller glue logic.


Let us assume that all slaves are listening to the bus - in otherwords their Rx pin is electrically connected to the Transmit line of the Master device via the bus.  The master will address a slave by sending a packet of data which contains the (destination) address of that node. When a slave sees it's own address come up, it decodes the packet of data, which is usually a command allowing the slave to access the bus, and transmit its data back to the master.
Let us assume that all slaves are listening to the bus - in otherwords their Rx pin is electrically connected to the Transmit line of the Master device via the bus.  The master will address a slave by sending a packet of data which contains the (destination) address of that node. When a slave sees its own address come up, it decodes the packet of data, which is usually a command allowing the slave to access the bus, and transmit its data back to the master.


To do this, the slave must enable it's Transmit tristate buffer by lowering digital 6.  This allows the slave to send data to the bus, where the master, will receive it.  By lowering pin 6, the Red LED will also be turned on, and this gives a visual indication that that slave has been selected and that it is accessing the bus. This is the reason that the LED is on pin 6.
To do this, the slave must enable its Transmit tristate buffer by lowering digital 6.  This allows the slave to send data to the bus, where the master, will receive it.  By lowering pin 6, the Red LED will also be turned on, and this gives a visual indication that that slave has been selected and that it is accessing the bus. This is the reason that the LED is on pin 6.


The slave sends its data to the master and then releases the bus - by raising pin 6 and the LED will turn off.
The slave sends its data to the master and then releases the bus - by raising pin 6 and the LED will turn off.
Line 472: Line 472:
===RFM12 Wireless Module===
===RFM12 Wireless Module===


Wireless connectivity can be added to the Nanode using the [http://jeelabs.com/products/rfm12b-board Jeelabs RFM12B wireless board]. Schematic can be viewed [http://jeelabs.net/attachments/846/jlpcb-511.pdf here]. No need to solder in the 3.3V regulator or capacitors the board will gets it's 3.3V power from the Nanode.  
Wireless connectivity can be added to the Nanode using the [http://jeelabs.com/products/rfm12b-board Jeelabs RFM12B wireless board]. Schematic can be viewed [http://jeelabs.net/attachments/846/jlpcb-511.pdf here]. No need to solder in the 3.3V regulator or capacitors the board will gets its 3.3V power from the Nanode.  


For compatibility with the [http://OpenEnergyMonitor.org/emon/emontx emonTx] from OpenEnegyMonitor.org ensure the 433Mhz RFM12B module is used (this frequency can be used worldwide). JeeLabs use 868Mhz which can only be used in Europe.  
For compatibility with the [http://OpenEnergyMonitor.org/emon/emontx emonTx] from OpenEnegyMonitor.org ensure the 433Mhz RFM12B module is used (this frequency can be used worldwide). JeeLabs use 868Mhz which can only be used in Europe.  
Line 643: Line 643:
===Combining Bitlash and RESTduino to make a simple Scriptable Device===
===Combining Bitlash and RESTduino to make a simple Scriptable Device===


Bitlash is a simple interpreted script language which runs on Nanode or Arduino. It allows you to define new functions, store them to EEprom memory and to control the I/O port pins with a few simple commands typed over the serial port. It's a little reminiscent of the late 70's early 80's home-computers that from power-up ran an interpreted basic.  It's better than basic because it ties in with the Arduino libraries ad function calls, and you can mix your C code with Bitlash running in the background - it just seems such a cool idea as an interface to a simple microcontroller.
Bitlash is a simple interpreted script language which runs on Nanode or Arduino. It allows you to define new functions, store them to EEprom memory and to control the I/O port pins with a few simple commands typed over the serial port. It's a little reminiscent of the late 70's early 80's home-computers that from power-up ran an interpreted basic.  It's better than Basic because it ties in with the Arduino libraries and function calls, and you can mix your C code with Bitlash running in the background - it just seems such a cool idea as an interface to a simple microcontroller.


Bitlash has a Telnet example, so that you can Telnet into it remotely and edit scripts to control different things. Well you could - if our TCP/IP stack supported a Telnet Client.  Unfortunately it doesn't, so we have to find another way of getting our command line data up to the Nanode.
Bitlash has a Telnet example, so that you can Telnet into it remotely and edit scripts to control different things. Well you could - if our TCP/IP stack supported a Telnet Client.  Unfortunately it doesn't, so we have to find another way of getting our command line data up to the Nanode.
EdD
9

edits

Retrieved from ‘https://wiki.london.hackspace.org.uk/view/Special:MobileDiff/18097’