tag:blogger.com,1999:blog-48299243635542355282024-03-06T07:25:42.732+00:00Embedded AdventuresChanging the world...one microcontroller at a timeIan Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-4829924363554235528.post-35913394607795189542011-08-05T14:41:00.002+01:002011-08-05T14:43:57.035+01:00Aduino powered by PIC32<p>Finally! Arduino sure seems to be ruling the hobbyist embedded market and we're finally able to bring a compatible platform on the Microchip side of the fence. Not just that, these development platforms are based on the PIC32 microcontrollers, meaning that they have a true 32 bit core, and hence easily many, many times faster than your average Arduino board.</p><p>The ChipKit platform gives you all that's good about Arduino - hardware and software compatibility with "shields" (add-on boards) and the software libraries that make Arduino platforms easy to get started on - but with room to grow.</p><p><br /><a title="ChipKit" rel="lightbox" href="http://www.embeddedadventures.com/admin/images/uploaded_images/PLT_1005_600.jpg"><img style="display: block; margin-left: auto; margin-right: auto;" title="ChipKit Uno32 Platform" src="http://www.embeddedadventures.com/admin/images/uploaded_images/PLT_1005_250.jpg" alt="PLT-1005 ChipKit Uno32 Development Platform" width="250" /></a><br /></p><br /><p> </p><p>We'll be bringing you tutorials on how to use the platform and you'll be delighted to know that all the 3.3v Embedded Adventures modules will work with these platforms. It's very exciting to have a platform that will get you started easily into the wonderful world of embedded electronics - and one that it truly powerful, meaning you won't outgrow it in a hurry!</p><p><br />We're carrying the <a href="http://www.embeddedadventures.com/shopdetails/pid/111">Uno32</a> and <a href="http://www.embeddedadventures.com/shopdetails/pid/110">Max32</a> platforms and look forward to hearing about what you're doing at yours.<br /></p>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-20965999479938170972011-08-02T13:04:00.002+01:002011-08-02T13:06:20.893+01:00New alphanumeric LED display - DSP-0801<p>2 August 2011</p><hr /><p>It took six PCB revisions and countless tweaks until we were happy with it - but finally we're are delighted to present our latest product, the DSP-0801, an <a href="http://www.embeddedadventures.com/shopdetails/pid/112">8 digit 14 segment alphanumeric display</a>.</p><p><a title="DSP-0801" rel="lightbox" href="http://www.embeddedadventures.com/admin/images/uploaded_images/DSP_0801_600.jpg"><img style="display: block; margin-left: auto; margin-right: auto;" title="8 digit 14 segment alphanumeric display" src="http://www.embeddedadventures.com/admin/images/uploaded_images/DSP_0801_250.jpg" alt="DSP-0801 8 digit alpha display" width="250" /></a></p><p>Powered by a PIC18F14K50 with two CAT4016 chips running the displays, this display is designed to make it easy to interface to. You can talk to it over TTL serial at 115,200 bps, or via synchronous (clocked) serial, also allowing you to daisy chain modules together to create even bigger displays. Of course the firmware supplied does all this out of the box, but there's nothing stopping you replacing the firmware for your own nefarious purposes! It could, for example, talk directly to a <a href="http://www.embeddedadventures.com/shopdetails/pid/92">RTC / Temp sensor module</a>, to display time and temperature - add a <a href="http://www.embeddedadventures.com/shopdetails/pid/108">SoundOut module</a> to make it a talking clock, or use all those digits to show the <a href="http://www.embeddedadventures.com/shopdetails/pid/106">humidity</a> with 24 bit accuracy. There's a BoostBloader bootloader in built, or you can use the ICSP port to reprogram it with a <a href="http://www.embeddedadventures.com/shopdetails/pid/61">PicKit2</a>.</p><p>The possibilities are endless! Available in red, blue and yellow, and shipping now.</p>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com2tag:blogger.com,1999:blog-4829924363554235528.post-149086379793208322011-07-25T20:54:00.002+01:002011-07-25T20:56:35.008+01:0024 bit MS5611 barometric pressure sensor / barometer back in stock<p>25 July 2011</p><hr /><p>Our 24 bit <a href="http://www.embeddedadventures.com/shopdetails/pid/106">MS5611 based barometric pressure sensor / barometer</a> is back in stock.<br /></p><p><a title="24bit air pressure sensor" rel="lightbox" href="http://www.embeddedadventures.com/admin/images/uploaded_images/mod_1009_600.jpg"><img style="display: block; margin-left: auto; margin-right: auto;" title="24bit air pressure sensor" src="http://www.embeddedadventures.com/admin/images/uploaded_images/mod_1009_250.jpg" alt="MOD-1009 MS5611 Air Pressure Sensor" width="250" /></a></p><p>Thanks to everyone who has waited for backorders to be filled, we ran out of the last run very quickly! We really appreciate your patience.</p>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-24147020981815965822011-07-07T16:27:00.001+01:002011-07-07T16:29:07.738+01:00<p>Need a sound module for your embedded project that can drive a speaker directly, has bucket loads of memory, and can play back audio samples on command? Do we have a product for you! After much hunting and haggling and designing and testing, we present the <a href="http://www.embeddedadventures.com/shopdetails/pid/108">MOD-1007 SoundOut</a> audio module.</p><br /><br /><a title="SoundOut Audio Module" rel="lightbox" href="http://www.embeddedadventures.com/admin/images/uploaded_images/MOD_1007_600.jpg"><img style="display: block; margin-left: auto; margin-right: auto;" title="SoundOut Audio Module" src="http://www.embeddedadventures.com/admin/images/uploaded_images/MOD_1007_250.jpg" alt="MOD-1007 SoundOut Audio Module" width="250" /></a><br /></p><br /><p>Compatible with the SOMO-14D module (at least, it uses the same playback chip - the pinout is slightly different), this module allows you to start sample playback using press buttons or using a synchronous (clocked) serial connection to your microcontroller, using an easy protocol. Of course, the <a href="http://www.embeddedadventures.com/pages/p/Tutorials/id/29">PicPack</a> library already has sample code available if you need a hand. The module plays back .AD4 files, which can be created from .MP3 or .WAV files using a utility provided.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-14213236435335495712011-06-13T20:19:00.002+01:002011-06-13T20:22:39.509+01:00Power up!<p>Need 3.3V or 5V for your breadboard experiment or next project? The <a href="http://www.embeddedadventures.com/shopdetails/pid/107">MOD-1011</a> is just for you! Throw up to 30V at it and it'll give you a nice, regulated supply at up to 1A - we've used low ESR tantalum capacitors to ensure superior regulation to what you normally get with your average breadboard power supply.</p><br /><a title="Power Supply Module" rel="lightbox" href="http://www.embeddedadventures.com/admin/images/uploaded_images/mod_1011_600.jpg"><img style="display: block; margin-left: auto; margin-right: auto;" title="Power Supply Module" src="http://www.embeddedadventures.com/admin/images/uploaded_images/mod_1011_250.jpg" alt="MOD-1011 Power Supply Module" width="250" /></a>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-62885738685520958832010-06-10T13:17:00.003+01:002010-06-22T16:12:39.896+01:00New web site<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4YeNdwLhhL7CliblD1LLtxmwW13TRuPn8ViutSnEXWtMCfcxqLkymzs9DpDtw4iqbOTS-CTeP4feuRuZ44HUwTm-qjgMWn1AaUxwRNTG3fEYTsqvYgqKfb8mOZF4pAAGs02sJ3gXaR_U/s1600/EA_logo_72dpiRGB.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 74px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4YeNdwLhhL7CliblD1LLtxmwW13TRuPn8ViutSnEXWtMCfcxqLkymzs9DpDtw4iqbOTS-CTeP4feuRuZ44HUwTm-qjgMWn1AaUxwRNTG3fEYTsqvYgqKfb8mOZF4pAAGs02sJ3gXaR_U/s320/EA_logo_72dpiRGB.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5485615702042944978" /></a><div style="text-align: center;"><br /></div><div style="text-align: center;">Please pop over to our shiny new web site at</div><div style="text-align: center;"><a href="http://www.embeddedadventures.com">www.embeddedadventures.com</a></div><div style="text-align: center;"><a href="http://www.embeddedadventures.com"></a>Looking forward to seeing you soon!</div><div style="text-align: center;"><br /></div>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-73767595267264235002009-12-02T17:37:00.003+00:002009-12-02T17:41:57.845+00:00SOMO-14D audio module<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_9qMJEBqZEteqAR3u-7D-LibuDkHNZZp0VHi_qwR4TPyf8TtCS-cZSw6Ac0QopgeJF7O4C8_WVIlE8NAAEhayhnvgwm-UnjnhTWJQ0jsalRsUjjq9mJYO8_JbO1OqwP-ykymf2Ky8hVY/s1600-h/logic.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 156px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_9qMJEBqZEteqAR3u-7D-LibuDkHNZZp0VHi_qwR4TPyf8TtCS-cZSw6Ac0QopgeJF7O4C8_WVIlE8NAAEhayhnvgwm-UnjnhTWJQ0jsalRsUjjq9mJYO8_JbO1OqwP-ykymf2Ky8hVY/s320/logic.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5410694897261061650" /></a><br />The Somo 14D is a cute little module from 4D - plays audio files you put on a micro SD card. Aside from some difficulties with the brand of card you use, it kind of worked... but wouldn't play the files I requested.<br /><br />Now, bring in the Logic tool. Honestly, I can't believe I didn't buy this or something like this years ago.<br /><br />Turns out this module is very particular also about the timing of commands you send it. The clock pulses have to be 200us. And that's exactly what I had in my code:<br /><br /><pre><br />void somo_14d_send_data(uns16 data) {<br /> <br /> // Signal start<br /> clear_pin(somo_14d_clk_port, somo_14d_clk_pin);<br /> delay_ms(2); // tSTART = 2ms<br /> <br /> for (uns8 count = 0; count < 16; count++) {<br /> if (data.15) {<br /> set_pin(somo_14d_data_port, somo_14d_data_pin);<br /> } else {<br /> clear_pin(somo_14d_data_port, somo_14d_data_pin);<br /> }<br /> delay_us(1); // tDS = 1us<br /> set_pin(somo_14d_clk_port, somo_14d_clk_pin);<br /> delay_us(200); // tCH = 200us<br /> clear_pin(somo_14d_clk_port, somo_14d_clk_pin);<br /> delay_us(200); // tCL = 200us<br /> data = data << 1;<br /> }<br /> // Signal end<br /> set_pin(somo_14d_clk_port, somo_14d_clk_pin);<br /> delay_ms(2); // tSTOP = 2ms<br />}<br /></pre><br /><br />All looks perfectly okay, right?<br /><br />Now look at what Logic says. The pulse is actually about 100us. Half the...hang on. In my config.h I had the clock rate of the chip at 20Mhz when in fact it's running at 40Mhz. Ha! Once again, Logic to the rescue.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-12140389801518687782009-10-29T16:01:00.022+00:002009-10-29T16:35:23.455+00:00Smashing Pumpkins<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgacT2AmWqhHIlSMadPuLzdDLuzUf44L-J05wilfGLPJZ4tjvUniVhOxt_JuAZG0EOrPygpHBSBPrstIdmdRgyNVwVAkwSWPvVkZgZ7h0VgRMq4IZMJGJKf5lzOydPbgibzlQ4OG4zaCBQ/s1600-h/SMASH-16.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 207px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgacT2AmWqhHIlSMadPuLzdDLuzUf44L-J05wilfGLPJZ4tjvUniVhOxt_JuAZG0EOrPygpHBSBPrstIdmdRgyNVwVAkwSWPvVkZgZ7h0VgRMq4IZMJGJKf5lzOydPbgibzlQ4OG4zaCBQ/s320/SMASH-16.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5398056147483114882" /></a><br /><br /><br />Combine hobby electronics, photography and fruit and vegetables dropped from a second floor balcony, what do you get?<br /><br />My brother does fun stuff with cameras for a living - see <a href="http://www.seesawphoto.com.au">www.seesawphoto.com.au</a> - but we decided to combine his photography skills and equipment and some gear from Sparkfun and the PicPack library to see if we couldn't smash a few things up.<br /><br /><br /><br /><br /><br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_ig8VP31I8JfOOqDA9_VJWI0Dlyh3yNnD3Nr5fDuvme6a4oDj0FDbwwJ49hLuLSLNQKMVrkSjKULxIRGW4j0Lid4uHDs7r8uOmKo7x33dlNdGaMbNQvZWs3NBjGAiptuwVWN6sEsLdtc/s1600-h/SMASH-13.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 218px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_ig8VP31I8JfOOqDA9_VJWI0Dlyh3yNnD3Nr5fDuvme6a4oDj0FDbwwJ49hLuLSLNQKMVrkSjKULxIRGW4j0Lid4uHDs7r8uOmKo7x33dlNdGaMbNQvZWs3NBjGAiptuwVWN6sEsLdtc/s320/SMASH-13.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5398055858342442258" /></a><br /><br /><br />What could be more fun than smashing eggs, watermelons and pumpkins all in the name of a good photo?<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.sparkfun.com/commerce/images/products/PIC-MT-0_i_ma.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 188px; height: 188px;" src="http://www.sparkfun.com/commerce/images/products/PIC-MT-0_i_ma.jpg" border="0" alt="" /></a><br />The trick of course is to capture the image just at the right moment. We rigged up a <a href="http://www.sparkfun.com/commerce/product_info.php?products_id=8669">microphone</a> to a <a href="http://www.sparkfun.com/commerce/product_info.php?products_id=26">Pic demo board</a> (which rather nicely has buttons, an LCD display, and a relay to trigger the flash. We grabbed a wired connection to a camera-mounted flash - wired that to the relay output from the board and then used that to trigger Paul's top knotch professional studio flash gear. The microphone was wired to the analogue input and sampled as quickly as the Pic could manage it.<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxU0zIebWa3FECML1m8gvihXUVZ63EP0J6fcP6Vp4rRZXHvTOY206d73lqwuOPhr5p9UOCb-y_RSE3E208axcQAGpnEKMBRimtcUYGds7KuBCWWdla331cPuU041IDX2yW-OAnf_3Iw9s/s1600-h/SMASH-15.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 212px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxU0zIebWa3FECML1m8gvihXUVZ63EP0J6fcP6Vp4rRZXHvTOY206d73lqwuOPhr5p9UOCb-y_RSE3E208axcQAGpnEKMBRimtcUYGds7KuBCWWdla331cPuU041IDX2yW-OAnf_3Iw9s/s320/SMASH-15.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5398056009283928018" /></a><br />Knocking together the Pic application didn't take long with the library functions. The buttons allowed a configurable delay in milliseconds between hearing sound and triggering the flash, and sound sensitivity. Of course some experimentation was required here - more things to smash! In the end we built an audible delay in so that we had a chance to "arm" the system, then get out of the way before the pumpkins came down.<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrzgG8Un8_b6JfCihlnTKdxB5KzKpETDQe0FAcZO1DPmfVOwaKGs4PfkLT-ezwVE4pQWBo1azWi-tzXBp_APMotp2ENxS8kGpFJgZjfNjjeB6UuXLEgKGKSO-s6ngt19AgLVgpJnEG71A/s1600-h/SMASH-17.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 198px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrzgG8Un8_b6JfCihlnTKdxB5KzKpETDQe0FAcZO1DPmfVOwaKGs4PfkLT-ezwVE4pQWBo1azWi-tzXBp_APMotp2ENxS8kGpFJgZjfNjjeB6UuXLEgKGKSO-s6ngt19AgLVgpJnEG71A/s320/SMASH-17.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5398056249867212898" /></a><br /><br />I think you'll agree the photos are pretty fun. Source code will be published in the next drop of PicPack.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-5224831543817628862009-01-26T11:54:00.002+00:002009-01-26T12:02:28.534+00:00PicPack 2.0 releasedNow available... Including better USB documentation and a cracking USB serial (CDC) demo.<br /><br />You can download from the right hand side "download" window.<br /><br />You can also get PicPack from GitHub - updated regularly.<br /><br />Enjoy!Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com2tag:blogger.com,1999:blog-4829924363554235528.post-85837308123999544262009-01-26T10:46:00.002+00:002009-01-26T12:00:01.755+00:00USB Part 5 – Using the USB Serial libraryNow that we’ve explored some of the ins and outs of the PicPack USB library, it’s time to look at a more complex and probably more useful example. Up until now we’ve relied on using serial ports to act as our debug interface. It would be nice if we could use USB for this purpose entirely? This is where the Communication Device Class (CDC) comes in.<br /><br />The CDC covers many things, including the thing that we’re interested in, a connection to a modem-like device. In fact, we define our “modem” as so dumb it can’t even make calls on a phone line – which sounds pretty much like a serial port to me.<br /><br />If you want to get cracking, open up the usb_serial project in the demos\usb_serial directory. It’s all set for burning into a 18f4550 on a board like the TechToys USB demo board. If you burn the .hex file, then plug your device into a PC, it will ask for a driver file. Just point the install program at the picpack_cdc.inf file in the tools\usb_cdc_inf directory. For reasons best known to Microsoft, Windows requires this file, even though all it says is “this is a standard USB serial port”. Go figure. Linux doesn’t require any sort of driver information at all.<br /><br />Using the PicPack CDC routines is pretty easy. You can use them just like you’ve been using the pic_serial routines up til now.<br /><br />In your system setup routine, put:<br /><pre name="code" class="c:nocontrols:nogutter"><br />// Setup Communication Device Class routines<br />usb_cdc_setup();<br /><br />// Setup USB<br />usb_setup();<br /><br />// Turn on interrupts<br />turn_usb_ints_on();<br />turn_global_ints_on();<br /></pre><br />In your interrupt service routine you will need to include:<br /><pre name="code" class="c:nocontrols:nogutter"><br />usb_handle_isr(); <br /></pre><br />which handles both reception and transmission.<br /><br />In your main() routine, kick off USB negotiations using:<br /><pre name="code" class="c:nocontrols:nogutter"><br />usb_enable_module()<br /></pre><br />You can wait for the negotiations to finish using<br /><pre name="code" class="c:nocontrols:nogutter"><br />while (usb_configured == 0) {<br /> delay_ms(250);<br />}<br /></pre><br />We’ll use the callback that’s triggered when the configuration is complete to set the usb_configured variable:that we were checking in that last loop:<br /><pre name="code" class="c:nocontrols:nogutter"><br />void usb_device_configured_callback() {<br /> usb_configured = 1;<br />}<br /></pre><br />And that’s it. Once the link is up, you can use the usb_cdc_ routines like usb_cdc_putc just like their pic_serial equivalents. In fact, aside from these routines, you can see that the complete program looks remarkably similar to the pic_serial demo itself.<br /><br />You can #define USB_DEBUG and CDC_DEBUG in the config.h file if you’d like to get more detail on the USB process itself. This is handy if you want to understand how the CDC class code and the PicPack USB stack itself work.<br /><br />In the next tutorial we’ll delve a bit deeper into the CDC routines. The CDC is a more complex example than our previous USB joy mouse which sent data in only one direction, and didn’t make use of class control transfers and multiple endpoints.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-17192002756290968452009-01-12T11:59:00.004+00:002009-01-12T13:00:14.678+00:00USB part 4 – Inner workings of the PicPack USB stackThis tutorial covers the main USB functionality and how the library actually goes about setting up the pic to carry out USB transactions and transfers. You don’t need to understand exactly how all this happens, but it’s helpful to know what the functions do and how to use them. <br /><br />Our first point is to setup the USB sub-system. As is our convention with the PicPack library, naturally, you call the usb_setup routine:<br /><span style=";font-family:courier new;"><br /> void usb_setup() {<br /> usb_state = st_POWERED; <br /> </span><br />Our state is now powered, meaning that we have power applied over the USB bus. The next task is to initialise the hardware:<br /><span style=";font-family:courier new;"><br /> // init hardware<br /> clear_bit(ucfg, UTRDIS); // enable internal tranceiver<br /> </span><br />Most designs involving pics use the internal transceiver. You can connect the pic to an external piece of hardware, or connect it directly to the chip itself. Here we assume that you’re doing the direct connection. USB has (as of version 2.0) three speeds – low speed (around 1Mbps), full speed (around 12Mbs) and high speed (around 480Mbps). The pics that we’re playing with only operate in the low/full range, meaning that we have to select between low and full speed.<br /><span style=";font-family:courier new;"><br /> set_bit(ucfg, FSEN); // clear for low speed, set for high speed<br /> </span><br />In all the examples here, we select full speed. There’s no reason not to, really, and as it happens, selecting full speed gives us many more choices for clock frequency selection. More about that in a later tutorial.<br /><br />USB indicates its speed request by pull-ups on the data pins. The pic hardware can do this function for us (meaning we don’t need to include external pull-up resistors), providing we enable the on-chip pull-ups:<br /><span style=";font-family:courier new;"><br /> set_bit (ucfg, UPUEN); // enable on-chip pull-ups<br /> </span><br />The pic USB Serial Interface Engine (SIE) can double buffer transfers, meaning that one buffer is being used by the SIE while the other is available to the microcontroller. This means faster transfer at the cost of more complex code. In the initial PicPack library, we switch double buffering off, for the sake of simplicity:<br /><span style=";font-family:courier new;"><br /> clear_bit(ucfg, PPB1); // disable double buffering<br /> clear_bit(ucfg, PPB0); <br /></span><br />Finally, we set up end point 0 ready to receive and send control transfers:<br /><span style=";font-family:courier new;"><br /> set_bit(uep0, EPHSHK); // EP0 handshaking on<br /> set_bit(uep0, EPOUTEN); // EP0 OUT enable <br /> set_bit(uep0, EPINEN); // EP0 IN enable <br /> clear_bit(uep0, EPCONDIS); // EP0 control transfers on (and IN and OUT)<br /> </span><br />Here we enable handshaking (required for control transfers – and all endpoints type except isochronous), enable OUT (from host) and IN (to host) transfers, and enable control transfers on this endpoint.<br /><br />Due to a bug in the BoostC compiler that prevents compile time initialisation of structures that don’t point to char*, we need some run-time initialisation of this structure.<br /><span style=";font-family:courier new;"><br /> ep_out_bd_location[0] = &bd0out;<br /></span><br />This continues for all buffer descriptors for IN and OUT endpoints.<br /><br />In order to kick off interrupts for the USB module, in our main program we turn on interrupts from the USB module:<br /><span style=";font-family:courier new;"><br /> turn_usb_ints_on();<br /> turn_global_ints_on();<br /> </span><br />Finally, to actually start the USB module doing its things, we call usb_enable_module().<br /><span style=";font-family:courier new;"><br />void usb_enable_module() {<br /> uir = 0;<br /> set_bit(ucon, USBEN); // enable USB serial interface engine (SIE)<br /> usb_state = st_DEFAULT;<br />}<br /></span><br />Here we clear any previously triggered interrupts, enable the USB SIE module and set our state to Default.<br /><br />It’s at this point that all the fun starts. The SIE now attaches to the bus by pulling one of the data lines high, and negotiations begin.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-83581572290104886412009-01-09T13:26:00.002+00:002009-01-09T13:47:30.667+00:00USB Part 3 – Configuring the PicPack USB libraryAs a personal preference, I think that state machines are evil and should be avoided like the plague. Mostly this is because of my view the source code should show precisely what should happen. State machines are different, since they show what should happen under certain circumstances and they specifically hide the workings of the “machine” as a whole. It means that the understanding of how the whole system works is in fact “outside of the code”. You need to know something beyond what is written to comprehend what happens and why. This makes debugging these systems extremely difficult.<br /><br />Despite my misgivings, state machines are excellent at enabling us to create hardware cheaply since it doesn’t need to understand about what it is doing or why – it just needs to respond quickly. This is (unfortunately) the world we find ourselves in when we start playing with USB.<br /><br />Let’s have a look at how pic devices, in combination with the PicPack library handle the tangled web that is USB. Our first port of call is the config.h file, which is where the PicPack library finds all its configuration details – and the USB library is no exception. Let’s pull apart the USB section from the Joy Mouse demo. <br /><span style=";font-family:courier new;font-size:70%;"><br />#define USB_HIGHEST_EP 1</span><br />In order to configure the appropriate data structures, the library needs to know what the highest end point number will be. In this case, it’s endpoint 1.<br /><span style=";font-family:courier new;font-size:70%;"><br />// #define USB_SELF_POWERED<br />#define USB_BUS_POWERED</span><br />Is the device powered from the USB supply? Select your option here. This changes what the pic reports upstream when queried.<br /><span style=";font-family:courier new;font-size:70%;"><br />#define USB_EP0_OUT_SIZE 8<br />#define USB_EP0_OUT_ADDR 0x0500<br />#define USB_EP0_IN_SIZE 8<br />#define USB_EP0_IN_ADDR 0x0508<br /> #define USB_EP1_IN_SIZE 8<br />#define USB_EP1_IN_ADDR 0x0510<br /></span><br />Here it starts to get a little more complex. Each endpoint for IN and OUT transactions has its own buffer. For each endpoint IN and endpoint OUT you need to decide how big transactions can be, and where the buffer will be located. You’ll need to check out the datasheet for your particular pic. In the case of the 18f4550, 0x0500 is a good place to start all the buffers. You can see they run sequentially from there. Eight bytes is just plenty for a mouse. Since we have only an IN endpoint 1 (no OUT), we only declare the IN.<br /><span style=";font-family:courier new;font-size:70%;"><br />//#define USB_CALLBACK_ON_SOF<br />// if you define it, you'll need to include this routine in your code:<br />// void usb_SOF_callback(uns16 frame) {<br />// }</span><br />Each 1ms, the USB starts a new “frame”. If you want a nice clean 1ms wake up call without having to use timers, define USB_CALLBACK_ON_SOF and create a function called usb_SOF_callback in your code.<br /><span style=";font-family:courier new;font-size:70%;"><br />//#define USB_CALLBACK_ON_DEVICE_CONFIGURED<br />// if you define it, you'll need to include this routine in your code:<br />// void usb_device_configured_callback() {<br />// }<br /></span><br />USB has a state called “configured”. It means that the host has chosen a particular configuration (usually it has a choice of just one) and the PicPack library has set up the endpoints ready for action. If you’d like to get notified when this state occurs, define USB_CALLBACK_ON_DEVICE_CONFIGURED in your code and declare usb_device_configured_callback() in your code.<br /><span style=";font-family:courier new;font-size:70%;"><br />#define USB_CALLBACK_ON_CLASS_CTRL<br />// if you define it, you'll need to include these routines in your code:<br />//void usb_handle_class_ctrl_read_callback(); <br />//void usb_handle_class_ctrl_write_callback(uns8 *data, uns16 count);<br />//void usb_handle_class_request_callback(setup_data_packet sdp);<br /></span><br />A number of different types of devices are defined by the USB standard. These are known as class compliant devices. Just to keep things fun, USB handles some transactions for class devices over endpoint 0 using control transfers. While the Joy Mouse demo does indeed handle class control transfers, it doesn’t do a lot with them. For a more complex example, including how to send data back to the host after it has made a request using a control transfer and assuming class ownership of the control transfer, see the serial (CDC) PicPack demo which we’ll cover in the next tutorial.<br /><br />If your device needs to handle class control transfers, then define USB_CALLBACK_ON_CLASS_CTRL and declare the appropriate functions. Note that usb_handle_class_request_callback will be called when a class request has been received and needs action; usb_handle_class_ctrl_read_callback will be called when a transaction sending data to the host (IN) has completed, and usb_handle_class_ctrl_write_callback will be called when a transaction receiving data from the host has occurred.<br /><span style=";font-family:courier new;font-size:70%;"><br />//#define USB_EP_DATA_CALLBACK<br />// if you define it, you'll need to include these routines in your code:<br />//void usb_ep_data_out_callback(uns8 end_point, uns8 *buffer_location, uns16 byte_count);<br />//void usb_ep_data_in_callback(uns8 end_point, uns16 byte_count);<br /></span><br />To handle data transactions that occur over endpoints other than endpoint 0, that is, non-control transfers, define USB_EP_DATA_CALLBACK. When a successful data transaction has occurred that received data from the host (OUT), usb_ep_data_out_callback will be called. You’ll be told the endpoint number, where the buffer is and how many bytes were transferred. Note that the endpoint will not be re-primed (armed) until you return from this function. When a successful data transaction has occurred that sent data to the host (IN), usb_ep_data_in_callback will be called. The Joy Mouse demo doesn’t use either of these functions.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-78648513969980170482008-12-12T12:41:00.002+00:002008-12-12T12:42:24.066+00:00See Saw PhotoA quick note to let people know that if you need the best photographers in Brisbane Australia, go straight to <a href="http://www.seesawphoto.com.au">See Saw Photo</a> - run by my brother and his wife. Their portfolio is amazing, and if you appreciate good photos, it's worth a look just for that.<br /><br />A new USB tutorial coming soon!Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-21407950928663619082008-08-05T10:08:00.003+01:002008-08-05T10:16:37.895+01:00USB Part 2 - The Joy MouseIn this example, I’m going to show the use of the library with the TechToys USB experimenter’s board. This is a great board to try these sorts of experiments with – it has an SD card slot to play with mass storage class devices (along with understanding the SD card protocol) and a 5 way joystick, supporting up, down, left, right and select. This allows us to simulate a mouse with our joystick. Since the mouse is part of the USB specification that Windows supports without (third party) drivers, this is a nice way to get our feet wet with USB without having to do any hard work on the Windows side. You could also prototype this circuit using a 18f4550 pic on a breadboard with a few switches if you preferred.<br /><br />Let’s look firstly at the way we handle delivering the descriptors to the host. Pull up the usb_joy_mouse demo and have a look in the usb_config_mouse.c file. Here’s where all the mouse specific stuff sits to hide it away from the main program.<pre class='code'><br />void usb_get_descriptor_callback(uns8 descriptor_type,<br /> uns8 descriptor_num,<br /> uns8 **rtn_descriptor_ptr,<br /> uns16 *rtn_descriptor_size) {</pre>You have to supply a usb_get_descriptor_callback function in your program. The PicPack library will call it when it has received a request for a particular descriptor. Your job is to return a pointer to where to find the descriptor, and how big the descriptor is.<br /><br />The standard descriptors are defined in pic_usb.h. Here’s the device descriptor:<pre class='code'><br />typedef struct _device_descriptor {<br /> uns8 length,<br /> descriptor_type;<br /> uns16 usb_version; // BCD<br /> uns8 device_class,<br /> device_subclass,<br /> device_protocol;<br /> uns8 max_packet_size_ep0;<br /> uns16 vendor_id,<br /> product_id,<br /> device_release; // BCD<br /> uns8 manufacturer_string_id,<br /> product_string_id,<br /> serial_string_id,<br /> num_configurations;<br />} device_descriptor;</pre>Now, the descriptors really are just a chunk of bytes, so you don’t need to use proper C structs like this to hold them. You could happily use a string of bytes and return a pointer to that along with the length. The reason we use C structs here is that you are much less likely to make a mistake getting things working. Once you have things working, feel free to replace the C structs with data structures that take less space or are based in ROM (with appropriate changes to the library). As always, my motto is get things working, then get them working smaller/faster. Did you know you can hang Windows by plugging in a device with a dodgy descriptor in it? I didn’t, until I started this USB work. Believe me, it’s a frustrating exercise! Who would have thought that Windows would be so easily duped? So, in these examples, we always use the structs to ensure we have everything right in the descriptors<br /><br />Now, back in usb_config_mouse.c, we define our device descriptor like this:<pre class='code'><br />device_descriptor my_device_descriptor = {<br /> sizeof(my_device_descriptor), // 18 bytes long<br /> dt_DEVICE, // DEVICE 01h<br /> 0x0110, // usb version 1.10<br /> 0, // class<br /> 0, // subclass<br /> 0, // protocol<br /> 8, // max packet size for end point 0<br /> 0x04d8, // Microchip's vendor<br /> 0x000C, // Microchip's product<br /> 0x0200, // version 2.0 of the product<br /> 1, // string 1 for manufacturer<br /> 2, // string 2 for product<br /> 0, // string 3 for serial number<br /> 1 // number of configurations<br />};</pre>In our get descriptor callback function, here’s where we return this data:<pre class='code'><br />void usb_get_descriptor_callback(uns8 descriptor_type, uns8 descriptor_num,<br /> uns8 **rtn_descriptor_ptr, uns16 *rtn_descriptor_size) {<br /> uns8 *descriptor_ptr;<br /> uns16 descriptor_size;<br /> descriptor_ptr = (uns8 *) 0; // this means we didn't find it<br /> switch (descriptor_type) {<br /> case dt_DEVICE:<br /> serial_print_str(" Device ");<br /> descriptor_ptr = (uns8 *)&amp;my_device_descriptor;<br /> descriptor_size = sizeof(my_device_descriptor);<br /> break;<br /></pre>Notice that we use temporary variables for the descriptor pointer and its size. It’s only at the end of the function that we copy these into the rtn_descriptor_ptr and rtn_descriptor_size. This saves instructions since the pic instruction set doesn’t make it particularly easy to deal with double-dereferenced data.<br /><br />Have a look through the rest of the function. You can see how we return descriptors for the device, but also notice how when the host requests the configuration descriptor, it actually gets sent the configuration descriptor, the endpoint descriptors along with any class descriptors as well! The function also returns string descriptors, which are used to identify the device in nice plain language. Note that the string descriptors are in Unicode – a 16 bit value for each character. Luckily for us, in English, all you need to do is at a \0 null to each character. To be fair, almost all USB devices have only English string descriptors.<br /><br />Once enumeration has finished, it is simply a matter of sending data when we want to indicate that the mouse has moved or a button has been pressed. The trick with all USB transfers is that you need to put the data into a buffer before it is requested. In this case, it is not so much of a problem since the pic will NAK any request for data when the endpoint has not been “primed” (or “armed” – all data loaded into the buffer and the pic USB engine informed that it now has control of the buffer).<br /><br />The host will ask for data at the interval specified in the descriptors. This does mean that there’s a time gap between when we want to send data and when it actually gets requested. This is the side-effect of a system where the host controls all the transfers. This latency is not going to be noticed for mice or keyboards, but can make a difference for time-critical transfers like MIDI data or even serial data. You can send a bunch of data really quickly – but only so often.<br /><br />In any case, getting back to the joy mouse, notice that we<pre class='code'><br />clear_bit(intcon2, RBPU);<br /></pre>which turns on the weak pull-up resistors for port B inputs, which we then make inputs by:<pre class='code'><br />make_input(JOY_PORT, UP_PIN);<br />make_input(JOY_PORT, DOWN_PIN);<br />make_input(JOY_PORT, LEFT_PIN);<br />make_input(JOY_PORT, RIGHT_PIN);<br />make_input(JOY_PORT, CENTER_PIN);<br /></pre>and kick off the whole USB excitement by:<pre class='code'><br /> usb_setup();<br /></pre>Nothing will happen from a USB perspective until we enable the USB module:<pre class='code'><br />usb_enable_module();</pre>This routine allows you to “soft-insert” the device. It can be plugged in, powered and running, but only when you enable the USB serial interface module, will the USB side of things kick into life.<br /><br />When there has actually been some joystick movement or the select button pressed or released, this data is sent to the PC using the usb_send_data routine:<pre class='code'>usb_send_data(1, (uns8 *)&amp;buffer, 3, /*first*/ 0); // ep 1</pre><br />The first parameter is the endpoint number. In this case, we’re sending data from endpoint 1. We also pass a pointer to the buffer, the size of the buffer, and a helper to indicate whether this transfer is the first one. This is important since USB uses two alternating packet types (DATA0 and DATA1) when sending data so that it knows if one was lost. The PicPack library sets up endpoints so that you normally don’t need to know if you’re sending the first packet or not (the data packet type is set to the DATA1 one on initialisation, so that before the first packet is sent, it is toggled to become DATA0. However, there may be occasions that you need to force the packet data type back to DATA0, in which case, pass 1 for the last parameter.<br /><br />The JoyMouse implements everything USB-wise that is absolutely required, and nothing that isn’t. You can plug a JoyMouse into both Windows and Linux and it will work perfectly fine. In the next tutorial, we’ll dig a little deeper into the PicPack usb library.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-81136431536360428592008-07-28T10:10:00.001+01:002008-07-28T10:10:59.556+01:00USB part 1 - IntroductionThe USB consortium claims that there are about 2 billion USB devices in the world. I think they’re wrong. I think it’s easily ten times that. It is truly one of the few universal success stories for interconnection between devices and computers.<br /><br />When you have a look at the USB specification however, and its implementation for particular devices, you don’t have to read too much to realise that the specification has an extremely confusing nomenclature and even the standard “class” definitions work in different ways to each other. The other practical aspect that makes USB work difficult is that because everything happens in real time and we’re utilising fundamentally slow devices. So in order to make things happen quickly, everything is set up in advance, and then we’re told about the result after the fact. For example, we don’t get a request for some data, then make a call somehow to make that data available to the host. In fact, what happens is that we make the data available in advance of the host requesting it, and we find out afterwards that it grabbed it.<br /><br />This means that USB debugging is a pretty tricky business. I don’t mean to dissuade you from having a go – the examples in the PicPack library work should make it pretty easy for you to get up and going pretty quickly, especially if all you need is some sort of serial connection. A lot of work has gone into the USB portion of the PicPack library to get things working and make it easy for you to incorporate USB functionality into your products.<br /><br />But first, we need to understand a little about USB.<br /><br />I’m not going to go into a full explanation here – there’s tonnes of information on the web and if you’re even vaguely serious about the topic, grab yourself a copy of Jan Axelson’s USB Complete book. It’s one of the best computer books I’ve ever bought. What I am going to do here is to cover the basics so you have enough information to work with.<br /><br />First of all, the way that the USB system works entails the PC (or host) making requests, and the devices giving responses. Even when devices have something they need to send to the host, the host has to ask for it first. In this way, all the devices can share a common bus – they only speak when spoken to.<br /><br />If you’re familiar at all with TCP/IP you’ll know that a device has an IP address (eg 192.168.1.3) and address are allocated (like DCHP) to each device. Given that a PC and its devices is a closed system, addresses start at 1 and go up to 127. This is the device number.<br /><br />In TCP/IP, and each address is broken up into a number of “ports”. In USB land, this concept of ports is called “endpoints”, Endpoint 0 is a special endpoint; its purpose is (generally) to exchange information about the device itself. Other endpoints have purposes based on the device functionality. An endpoint can receive data from the host (called an OUT endpoint) or send data to the host (called an IN endpoint). These “in” and “out” definitions are named from the perspective of the host.<br /><br />Endpoint 0 is a bidirectional pipe and must exist for every USB device. There can be up to 16 endpoints, but generally only a couple beyond endpoint 0 are ever actually used.<br /><br />The USB system, like many systems that are designed by committee, covers many possibilities that are not often used in real life. Each device can have a number of different “configurations” of which the host can chose which one to use. While the information supplied as part of the configuration is important, I can’t think of many devices that have multiple configurations (a mobile phone may well use this if it can be a mass storage device or a modem depending on what is requested).<br /><br />A given configuration can have a number of “interfaces”. In the USB serial port emulator for example, there is an interface that handles the control of the port itself (ie, baud rate, stop bits etc) and an interface for the actual exchange of RS-232 data. Each of these interfaces are associated with one or more of the endpoints available.<br /><br />In summary – a device has (usually) one configuration, which has at least one interface, which has associated with it one or more endpoints.<br /><br />When a USB device is first plugged in, the host and the device go through a process known as “enumeration”. This is how the host finds out about the capabilities of the device and loads whatever drivers are required; the device can also find out how the host wants to handle things. Enumeration takes place using what are called “control transfers”. These are the most complex aspect of anything to do with USB programming. Thankfully, the PicPack library handles the difficult parts of this for you.<br /><br />Enumeration involves the delivery to the host of data structures that describe what a device is and how it works. These structures are called “descriptors”. You’ll find descriptors for the device as a whole, the configuration(s), interfaces and the end points themselves. Depending on the particular device, there are often extra descriptors that are specific to a particular class of device (eg, a serial port emulation, or a human interface device).<br /><br />Like most of the PicPack components, pic_usb does the hard work of handling the common cases, leaving you to implement the logic that makes your device different from everything else. In the next tutorial, we’ll look at how the library works.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-12719929683909120282008-07-22T09:47:00.002+01:002008-07-22T09:49:21.715+01:00New PicPack - with USB support - RC1I've made available the first release candidate for the new version of the <span class="blsp-spelling-error" id="SPELLING_ERROR_0">PicPack</span> library. It has support for <span class="blsp-spelling-error" id="SPELLING_ERROR_1">USB</span> pics, including examples of a mouse and a <span class="blsp-spelling-error" id="SPELLING_ERROR_2">USB</span> serial port.<br /><br />It needs some tidying up, documenting and no doubt, bug fixes, but I wanted to make it available to the adventurous to have a play with and give me some feedback - much appreciated guys.<br /><br />Enjoy.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-1313939588749273652008-06-15T16:01:00.006+01:002008-12-09T08:54:30.760+00:00New toys - Maplin Mobile Power Pack<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzVL0JKeFxSc3FhNk5P1IBs_MtYyL9FZ0glnunNtNNI2IgD6DNDJGbq-V7-D9o22dLocfkE4PlK5_b43EzJEa3ZN97dM-WB6nHhMmL8BQSqkHc4pUvBOfXxx7AA6Z5fhajuIfYxFO3cIo/s1600-h/pack1.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 155px; height: 199px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzVL0JKeFxSc3FhNk5P1IBs_MtYyL9FZ0glnunNtNNI2IgD6DNDJGbq-V7-D9o22dLocfkE4PlK5_b43EzJEa3ZN97dM-WB6nHhMmL8BQSqkHc4pUvBOfXxx7AA6Z5fhajuIfYxFO3cIo/s320/pack1.jpg" alt="" id="BLOGGER_PHOTO_ID_5212124603629928978" border="0" /></a><br />I found a neat device in Maplin the other day. It's meant to be a power pack for recharging things like your phone or your iPod. It's very slim and has a mini-B USB plug which is used for charging the pack and also as an outlet to charge your phone etc. The specifications say that it's 2000mAh, which given the output is 5v, is not bad at all.<br /><br /><br />But was it really giving 2000mAh at 5V? Well, there's only one way to find out...<br /><br /><br />Aha! It's 2000mAh at 3.7v.... Just as I thought. Then there's a boost circuit to bump it up to 5v. So, I make it at ab<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_OyZkzwWBgi8S5_YOi52Ro2reWk8h9KMtusS4iZBnpQS2hkp6EpK-Ix6D8xDnnKDpjAp6-BoGS7XZnr8_xfrWrmZENE-G1vZUpUe5LaacqYBK4s_w1qZOXFcZENqJyhFOmbVfduKtZY8/s1600-h/IMGP4822.JPG"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 283px; height: 187px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_OyZkzwWBgi8S5_YOi52Ro2reWk8h9KMtusS4iZBnpQS2hkp6EpK-Ix6D8xDnnKDpjAp6-BoGS7XZnr8_xfrWrmZENE-G1vZUpUe5LaacqYBK4s_w1qZOXFcZENqJyhFOmbVfduKtZY8/s320/IMGP4822.JPG" alt="" id="BLOGGER_PHOTO_ID_5212124917180557858" border="0" /></a>out 1480mAh at 5v (actually it would be somewhat less due to it not being 100% efficient). Still, that's not a bad little power pack.<br /><br />It also comes with a very small mains charger - which also has a mini-B USB connector on it.<br /><br />They're on sale at the moment for £9.99, which is pretty good for a mains 5V supply, and 5V battery source. I bought three, since I knew that their real purpose in life was not in fact to recharge iPods, but really....to power prototyping boards!<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXfYSEwWzvHaP_0mKdecXCuUwvM-bUUfLz-eQiW-gOohwpnCi1RFF6AKuPN4-hhn3oPCZp-2U5b_GjagkfRMK22SMWNl8XNJt_c4_eB0C4YmoGOWrkmcubItNO6drxCX-z-dYsHRCVH40/s1600-h/IMGP4823.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXfYSEwWzvHaP_0mKdecXCuUwvM-bUUfLz-eQiW-gOohwpnCi1RFF6AKuPN4-hhn3oPCZp-2U5b_GjagkfRMK22SMWNl8XNJt_c4_eB0C4YmoGOWrkmcubItNO6drxCX-z-dYsHRCVH40/s400/IMGP4823.JPG" alt="" id="BLOGGER_PHOTO_ID_5212126777647092610" border="0" /></a>See Maplin's website for the <a href="http://www.maplin.co.uk/Search.aspx?criteria=n62fx&source=15&SD=Y">N62FX</a>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-69040172827630400572008-05-19T14:24:00.013+01:002008-05-21T13:47:44.199+01:0018. All meshed up – Part 4 – Working in codeFinally, we’ll have a look at how the packet routines are called. The best place to start is the pic_packet.h file, where we find the definitions of the config parameters and status messages. Pull up the packet demo project and open the pic_packet.h file. Here are the things we need to set in our config.h:<br /><span style=";font-family:courier new;font-size:100%;" ><br />// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br /><br />// pic_packet defines<br /><br />// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br /><br /></span><br />You’ll need as big a transmit queue as possible, but this really depends on how many close nodes you’ll have in the mesh:<br /><span style=";font-family:courier new;font-size:100%;" ><br />#define PKT_TX_QUEUE_SIZE 5<br /></span><br />The “Seen List”, is surprisingly, a list of all the packets that we have seen (that are destined for us). The smaller the seen list, the more likely that we’ll think that a packet is new when it’s not, that is, the smaller the seen list, the more likely we’ll see duplicate packets.<br /><span style=";font-family:courier new;font-size:100%;" ><br />#define PKT_SEEN_LIST_SIZE 5<br /></span><br />Send Max Tries is the number of times a node will try and send a packet to the destination. The first time is always a direct send, after that, all other tries are routed sends. Of course, higher retry counts mean the packet spends more time taking up space in the TX queue as well.<br /><span style=";font-family:courier new;font-size:100%;" ><br />#define PKT_SEND_MAX_TRIES 4<br /></span><br />As we’ll see later, the tick time for packet fun should be about 0.25ms. In the packet example we set a resend delay of 10,000 ticks – or about 2.5 seconds. In real life, this is way too large, but for demo purposes, it allows us to understand how the packet network works. You should set this delay based on the speed of transmission and the possible number of hops in your mesh to the destination node. Remember, even in ideal conditions you need to transmit the packet through three intermediaries to the destination, then the destination node needs to send a packet back in the same way. It should be as small as possible, of course, but the best value will be found by experimentation.<br /><span style=";font-family:courier new;font-size:100%;" ><br />#define PKT_RESEND_TICK_DELAY 10000<br /></span><br />The payload is the data that actually makes it to the other end. This delivery system is designed to handle small messages – not large data transfers. 8 bytes might not sound like a lot, but for controlling lights, sending temperature readings, time and date and status checks, it’s really plenty. It’s a stack bigger than what X10 can move around. You can, of course make this as large as your given transceiver can cope with. The protocol we’ll layer on top of the packet network, however, expects a payload size of at least 8.<br /><span style=";font-family:courier new;font-size:100;" ><br />#define PKT_PAYLOAD_SIZE 8<br /></span><br />There are a couple of callbacks that are not enabled in this demo, but can be defined when you want your code to control a little more of what goes on. You can get a call back when a send fails:<br /><span style=";font-family:courier new;font-size:100%;" ><br />// Define if you want to get a callback on send failure<br />// #define PKT_CALLBACK_ON_SEND_FAILED<br />// if you define it, you'll need to include this routine in your code:<br />// void pkt_send_failed_callback(uns16 dest_addr, uns16 pkt_id) {<br />// }<br /></span><br />Or when a send succeeds:<br /><span style=";font-family:courier new;font-size:100%;" ><br />// Define if you want to get a callback on send success<br />// #define PKT_CALLBACK_ON_SEND_SUCCEEDED<br />// if you define it, you'll need to include this routine in your code:<br />// void pkt_send_succeeded_callback(uns16 dest_addr, uns16 pkt_id) {<br />// }<br /></span><br />The packet delivery system expects at this stage to be running on a Nordic nRF2401A or a nRF24L01 chip. You can mix these interchangeably on the same network, but a given node can of course use only use one or the other. Define one of them here:<br /><span style=";font-family:courier new;font-size:100%;" ><br />// define one or other of these:<br />#define PKT_USE_2401A<br />//#define PKT_USE_24L01<br /></span><br />And lastly, define the level of debug you want. Note that more debug means more serial_print_str statements, which means much larger code size.<br /><span style=";font-family:courier new;font-size:100%;" ><br />// define if you want debug<br />//#define PKT_DEBUG<br /> // define if you want high amounts of debug<br />//#define PKT_DEBUG_HIGH<br /></span><br />I’m assuming here that you also have #defines in the config.h file for the RF chipset – this has been covered in a previous tutorial.<br /><br />Unlike other PicPack libraries we’ve used before, there’s no “setup” routine for the packet library. The setup routine normally gets the ports and pins set up correctly as inputs or outputs, ready for communication with the outside world. This library talks to the world via the RF library, so it doesn’t need to set up any ports and pins itself. It does have an “init” routine though, which is used in a library to get any internal data set to the right values and initialise communication with a device so that it’s ready for use.<br /><span style=";font-family:courier new;font-size:100%;" ><br />pkt_init(my_addr, last_pkt);<br /></span><br />pkt_init gets the packet delivery system ready for use. It stores the address given as the local node’s address, and also stores the last pkt ID. All the transmit and last seen queues are cleared and everything is set ready for packet reception or delivery.<br /><br />So what happens when a chunk of RF data actually arrives? Well, assuming we’re using a SparkFun Terminal Development Node (TDN), you’ll remember that we tied the DR1 line to the PortB, pin 0.<br /><span style=";font-family:courier new;font-size:100%;" ><br />set_bit(intcon, INTE); // Enable interrupts on rb0<br /></span><br />The default for the port B, pin 0 interrupt is that it is triggered on a rising edge, that is, when the input signal goes from low to high. Perfect for us, so no changes are required here.<br /><br />In the packet demo, a routine called configure_pkt() does the work of getting the packet delivery system in order, ready for us.<br /><br /><span style=";font-family:courier new;font-size:100%;" ><br />void configure_pkt() {<br />uns16 my_addr;<br />uns16 last_pkt;<br /> my_addr = eeprom_read(EE_MY_ADDR_H);<br /> my_addr <<= 8;<br /> my_addr |= eeprom_read(EE_MY_ADDR_L);<br /> last_pkt = eeprom_read(EE_MY_LAST_PKT_ID_H);<br /> last_pkt <<= 8;<br /> last_pkt |= eeprom_read(EE_MY_LAST_PKT_ID_L);<br /> serial_print_str("My addr: ");<br /> serial_print_int_hex_16bit(my_addr);<br /> serial_print_nl();<br /> serial_print_str("Last pkt: ");<br /> serial_print_int_hex_16bit(last_pkt);<br /> serial_print_nl();<br /> pkt_init(my_addr, last_pkt);<br />}<br /></span><br />Essentially, this just pulls the address and last packet ID sent from the eeprom and calls pkt_init. It also prints out the local address and last packet ID – not essential, but very, very handy! Okay, so the packet system is all ready for use, let’s see what happens when the nRF2401A lets us know that a packet has arrived. It does this by taking the IRQ line high, which results in the INT (Port B, pin 0) being triggered. Here’s the interrupt routine:<br /><span style=";font-family:courier new;font-size:100%;" ><br />void interrupt( void ) {<br /> timer_handle_0_isr();<br /> if ( test_bit(intcon, INTF) ) {<br /> if (pkt_receive_level < MAX_PACKET_QUEUE) { // if we're not already processing a receive<br /> if (pkt_receive_level == 0) {<br /> pic_rf_receive(rf_rx_buffer, PKT_PACKET_SIZE);<br /> } else {<br /> pic_rf_receive(rf_rx_buffer2, PKT_PACKET_SIZE);<br /> }<br /> pkt_receive_level++;<br /> } else {<br /> dropped_packet++;<br /> } <br /> clear_bit( intcon, INTF);<br /> } // pkt available interrupt<br /> serial_handle_tx_isr();<br /> serial_handle_rx_isr();<br /> }<br /></span><br />The PKT_FLAG_RESEND is used to indicate that you want the system to resend the packet if it doesn’t get through, up to the maximum number of tries you’ve set in your config.h file. This is the usual case. In normal circumstances, it’s only acknowledgements that get sent using PKT_FLAG_NO_RESEND – and these are taken care of automatically.<br /><br />That’s it! Not much code required to build your own meshed packet network. Next exciting episode, we’ll look at how we can put an application layer on top of this system for the purpose of delivering actual data across the network. We’ll turn a SparkFun TDN into a remote temperature sensor and display the temperature on the base station on an LCD screen.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-7999319403603134602008-05-16T12:53:00.003+01:002008-05-16T13:22:06.432+01:00PicPack 1.2 releasedPicPack 1.2 has been released! You'll need this version for the complete packet tutorial.<br /><br />Many thanks to Peter Lawson in sunny South Australia who helped tirelessly getting the BoostBloader running on a new class of Pic chips. With his help, the BoostBloader now supports 16f88, 16f876a, 16f877a, 18f252, 18f452, 18f2620, and 18f4520. It should be quite easy to add other pics as well, I'll write a tutorial about doing that shortly.<br /><br />Enjoy!<br /><br /><br /><br /><span style="font-weight: bold;font-family:courier new;" >Version 1.2</span><br /><span style="font-weight: bold;font-family:courier new;" >-----------</span><br /><br /><span style="font-family:courier new;">16 May 2008</span><br /><br /><span style="font-weight: bold;font-family:courier new;" >pic_pack_lib</span><br /><br /><span style="font-family:courier new;">ds1631.c<br /><br />Rewrote to use i2c base library</span><br /><span style="font-family:courier new;"><br />packet.c\.h<br /><br />General update, documentation, a few logic errors fixed,</span><span style="font-family:courier new;"> new callbacks, functions better named</span><br /><span style="font-family:courier new;"><br />pic_serial.c\.h<br /><br />Added 16bit hex print routine<br /><br /></span><span style="font-family:courier new;">Pic_utils.c\.h<br />Added support for 18f452 for turn_analog_inputs_off()</span><br /><span style="font-family:courier new;"><br />protocol.h<br /><br />Tidied up, moved to bit positions to indicate capabilities,</span><br /><span style="font-family:courier new;"> expanded relay and dimmer options </span><br /><br /><span style="font-weight: bold;font-family:courier new;" >demos</span><br /><br /><span style="font-family:courier new;">packet<br /><br />All new meshed packet demo, based on SparkFun Terminal Development</span><br /><span style="font-family:courier new;"> Node (TDN), but will work on your breadboard of course as well. See tutorial </span><span style="font-family:courier new;">on the website</span><br /><br /><span style="font-weight: bold;font-family:courier new;" >Boostbloader/Screamer</span><br /><br /><span style="font-family:courier new;">Support for pics that have a write chunk smaller than 16 bytes (older 18f types)<br /><br /></span>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com1tag:blogger.com,1999:blog-4829924363554235528.post-82298662781012674542008-05-16T09:49:00.006+01:002008-12-09T08:54:31.140+00:0017. All meshed up – Part 3 – Packet chatting<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCqgXmlSXe-Fnidneo6J6aIlRnOMV2MIPc49pFflHjvdjcu0qPy1PW8i3N4RoEPD7pSpS9vN15iAz97twH3bXN1CexSAgOLm7JdnltooBgXWELG4ebY5zi3bDzOeUnLFUk6vJaTnlwz70/s1600-h/tdn.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCqgXmlSXe-Fnidneo6J6aIlRnOMV2MIPc49pFflHjvdjcu0qPy1PW8i3N4RoEPD7pSpS9vN15iAz97twH3bXN1CexSAgOLm7JdnltooBgXWELG4ebY5zi3bDzOeUnLFUk6vJaTnlwz70/s320/tdn.jpg" alt="" id="BLOGGER_PHOTO_ID_5202811217380910434" border="0" /></a>Enough theory. Let’s get our delivery network on the road. Rather than look at the code in this episode (boring), let’s jump straight in and get our nodes chatting. Time enough to see how the code works later.<br /><br />The packet demo is designed to run on the Sparkfun Terminal Development Nodes (TDNs), which are a very handy piece of gear for testing this all out. They have an RS232 connection on one end, a socket for the nRF2401a / nRF24L01 module on the other and a 16f88 in the middle plus a few leds, which help us know a little of what’s going on. Of course you can run this demo on a breadboard with an nRF module or if you’re feeling adventurous, write some code to support a different RF module all together. There are a bunch out there, do send your code in to include in the library if you get something working. I’m pretty interested in seeing some of the CC2500-based modules going, which are similar in nature to the Nordic ones (but are cheaper and have carrier detection – hooray!) or the modules from the fabulous Futurlec (even cheaper, carrier detection but fascinatingly obscure datasheets – fun!).<br /><br />For the purpose of this experiment, however, I’ll assume you’ve got a couple of SparkFun TDN (Terminal Development Node) and Nordic modules and a couple of serial ports (USB to serial converters will work fine) or a couple of computers with a serial port each.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoZtzRik3I1hdN0WXMziQO2S1_yV5ghyDZmF2wjatVmOK0WUvn_67buXXFTkxrml-w5Zf33g3z_-YN-R1ildQUPSU4ysO54zWxXwnQT_-B_7lTCwgCDPAwRWUWk26RVYqZz7HlpxQz8M8/s1600-h/square_pad.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoZtzRik3I1hdN0WXMziQO2S1_yV5ghyDZmF2wjatVmOK0WUvn_67buXXFTkxrml-w5Zf33g3z_-YN-R1ildQUPSU4ysO54zWxXwnQT_-B_7lTCwgCDPAwRWUWk26RVYqZz7HlpxQz8M8/s320/square_pad.jpg" alt="" id="BLOGGER_PHOTO_ID_5202810478646535506" border="0" /></a>The first step, naturally, is to get Boostbloader downloaded onto the 16f88 on each TDN. You’ll need the little mini adapter from SparkFun in order to reach their mini-ICSP connector. See the 5 holes together in the middle of the board? That's the ICSP "socket". Make sure you work out which way round the connector goes – pin 1 is designated by the square pad. The datasheet shows how this is connected, but it’s a pain having to check the datasheet every time you want to use the ICSP connector. Remember: 1 is square.<br /><br />Once this is done and you’ve confirmed the Boostbloader is doing its thing by downloading a flashing-led test app of your choice (a see the PicPack demo directory if you’re feeling unadventurous), it’s time to look at the packet demo and how it works. Download the “packet” demo into the 16f88 and get ready for some wireless magic.<br /><br />The 256 bytes of EEPROM in the 16f88 is a great place for a small amount of persistent data. In this example we use it for storing the address of the node, and the ID of the last packet sent.<br /><br />In the mini terminal mode, there are several commands that we’ll use to control the node. The first is the “w” command, which allows you to set EEPROM bytes at runtime. The first two digits specify the memory location and the third and fourth digits specify the value you want to set it to. “w0523”, for example, sets EEPROM location 0x05 to the value of 0x23 (all values in hex). In our case, we want to set the address of the node and the last sent packet ID like this: <pre class="code"><br />w0000<enter><br />w0101<enter><br />w02ff<enter><br />w03ff<enter></enter></enter></enter></enter></pre>You only need to do this once. The first two memory locations (00 and 01) store the local address; in this case we’re storing a 16 bit value of 0x0001. The third and fourth EEPROM memory locations hold the ID of the last packet we sent. In a more complete example later on, we’ll see how we update this with the last packet ID over time. For the moment, setting it to 0xffff as we do here is fine. This means the first packet this node sends will have an ID of 0x0000, so this is great for understanding what’s going on.<br /><br />Set your other node to an address of something else other than 0x0001 (I suggest 0x0002), and also set its last sent packet ID to 0xffff.<br /><br />Right, so now you have two nodes up and running and ready to communicate. One is set to address 0x0001 and the other is set to 0x0002. You can check that these addresses are stored correctly by resetting the TDN (by pressing the reset button) and seeing the serial terminal program come up with something like:<pre class="code"><br />My addr: 01<br />Last pkt: 65535<br /> Pkt demo<br /><17:10:36><br /></pre>Now it’s time to send a payload from one to the other. Here we’ll send a dummy payload that in future we’ll use to query the temperature on another node. Don’t worry about what’s in the payload for the moment, we’re more interested in seeing a packet make it’s way to the destination and get an acknowledgement back. Go to the terminal connected to your 0x0001 node and type:<pre class="code"><br />s02<enter></pre>This sets the “send to” (destination) address to 0x0002. This demo is slightly slack by only allowing 8 bit address entry, but I’m sure this won’t bother you with only two nodes right now. This setting of the send address needs to be done whenever you boot.<br /><br />Now, let’s send a packet. Type:<pre class="code"><br />x<enter></pre>This should send a packet to the specified destination address (0x0002). Since we only have two nodes right now and hopefully they’re quite close, you should find that node 0x0002 responds pretty much immediately. This is what you should see on the node 0x0001 terminal:<pre class="code"><br />>s02<br />S: 2<br />>x<br />>Send...<Snd good to 0002 id 0000> RX:5</pre>And here’s what you should see on the node 0x0002 terminal:<pre class="code"><br /> <<s: 01p: 06 01 FF FF FF FF BF FF >> RX:3 </pre>So what’s the deal about these numbers? The demo prints out the return values from the functions that get called. We won’t worry about the functions themselves and what they do right now, but we will look at these values, since they reveal the inner workings of the system. Have a look at pic_packet.h for the #define definitions.<br /><br />RX:3 - A value of ‘3’ on reception means “PKT_STATUS_PKT_IS_FOR_ME”. It’s a real packet and we haven’t seen it before. We can happily act on this packet. In this demo our “acting” on this packet just involves printing it out to see what we’ve got. You can see the packet was sent from a source address of 01, and had a payload of 06 01 FF FF FF FF BF FF.<br /><br />RX: 5 - A value of ‘5’ on reception means “PKT_STATUS_PKT_IS_FACK_FOR_ME”. It means we’ve received an acknowledgement and found that it is for a packet we’ve sent. That is, we have successfully confirmed delivery of a packet. Woohoo! We’ve just sent our first packet.<br /><br />If everything is correct and there are no transmission problems, these are pretty much the only values that you’re going to see with a two-node mesh. Not much of a mesh, really. However, we can simulate what happens in the mesh to help us understand how it works in this simple case. Do note that in this example, the delay between retries has been set deliberately, excruciatingly large so that you can clearly see what’s going on.<br /><br />Set the sending (destination) address of the 0x0001 node to a node that you know is not on your network (eg, 0x0003) by typing:<pre class="code"><br />s03<enter></pre>Now from the 0x0001 node try and send a packet to node addressed 0x0003 by typing:<pre class="code"><br />x<enter></pre>Now, remember from our previous tutorial that we will first try and send to node 0x0003 directly (a “direct send”). You’ll see that node 0x0002 reports a status of PKT_STATUS_DIRECT_SEND (6). This means that it has received the packet, but will not rebroadcast it since the originating node tried to send it directly (no routing).<br /><br />Since the first packet never got to its destination (an acknowledgement was not received), the node will try to send it again. On the next try however, our node 0x0001 will try and route the packet via anyone that’s listening (a “routed send”). In this simple case, we know that node 0x0002 is listening. Node 0x0002 should respond with PKT_STATUS_NEED_TO_REBROADCAST (9). So 0x0002 rebroadcasts to try and get it to 0x0003 (of course, it doesn’t know that 0x0003 doesn’t exist on our little network).<br /><br />Now here’s where it gets a bit tricky, but once you’ve got your head around this, you’ll be well on your way to understanding how this all works.<br /><br />To recap up to this point:<br /><br />0x0001 has tried to send directly to 0x0003<br />0x0002 saw it and printed PKT_STATUS_DIRECT_SEND (6) showing that it decided to ignore the packet (it saw that it’s a direct send not destined for itself)<br />…in time…<br />0x0001 tried again, this time routing via anyone that’s listening (not a direct send)<br />0x0002 saw it and responded PKT_STATUS_NEED_TO_REBROADCAST (9), and rebroadcast the packet out to anyone listening (hopefully it can reach 0x0003, or at least someone closer to 0x0003)<br /><br />Now at this point, 0x0001 should receive this rebroadcast. But it’s the one that sent the packet in the first place! So it should respond with PKT_STATUS_I_AM_SENDER (2) and ignore the packet.<br /><br />Finally, 0x0001 will give up, printing out <pre class="code"><br /><Send failed to 0003 id 0001></pre>to show that we’ve had a failed send.<br /><br />This confirms that 0x0002 has tried to pass the packet on deeper into the mesh, and also confirmed that 0x0001 is happily ignoring this bounce-back. Of course since our imaginary 0x0003 never received the packet, our originating node will try once more. Our plucky little node 0x0002 tries again to forward on into the mesh, but alas, the packet never makes it. If you have no friends, they’re not going to answer, not matter how many times you call.<br /><br />Clear this is all complete overkill for two nodes (although you do get retries and acknowledged delivery for free). Once you get three or more nodes where some nodes can’t see all the others, I hope you’ll see how powerful this can be for delivering short messages. Next time we’ll have a look at the calls into this library and how they work, finishing our series on the provided packet delivery system works – then later we’ll also cover some implementations of the system, in the first instance delivering temperature data from different nodes.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com2tag:blogger.com,1999:blog-4829924363554235528.post-19370340994904900572008-05-13T16:52:00.003+01:002008-05-21T13:47:11.615+01:0016. All meshed up - Part 2 - Packet network basicsNow we’ve worked out how to get a chunk of data from one place to another without any wires, it’s time to look at how the PicPack packet network actually works. In the next enthralling instalment we’ll get the actual packet network up and running in code.<br /><br />Okay, so here’s the problem I was trying to solve. How do you get a message to a device on the other side of the house, reliably? The distance (with brick walls) is going to be too great for a given, cheap, RF transceiver to reach, but we’re pretty much guaranteed to have devices in between the two – so could we use those as relays? It would be pretty nice not to have to configure the network (ie, direct exactly how the network gets messages from one place to another) - since the network may change and configuration of little hardware devices is difficult from the other side of the planet.<br /><br />So what I wanted was effectively a meshed packet network. But there’s a catch. We want to do this as cheaply as possible, not using devices with large chunks of memory, but on something like a 16f88 – 4k instructions, 384 bytes of RAM. Could it be done?<br /><br />The trick here is working out a way to discover network routes automatically in small amounts of code. My first thought was a method by which nodes could ask their neighbours if they knew about the node we wanted to talk to. And then if they didn’t know, they could ask their neighbours. Once we had the route, we could store it. Great, so now we’re storing a routing table. And how long do we store it before we throw it out and have to rediscover again when something has changed? Timewise, by the time we’ve asked all our neighbours to ask their neigbours about the node I want to send to, collected the responses, sorted them, then sent the message, well, this is all getting complicated and memory intensive, along with the next ice age having kicked off.<br /><br />Well, it’s all about tradeoffs, as we know from other tutorials. So here’s our strategy. If our destination node is within range, we’ll send it directly. It then sends an acknowledgement so we know it arrived safely. If it’s not within range, we get everyone that can hear us to broadcast the message. Hopefully, it will be in range of them, and we’ll get an acknowledgement back. In fact, we’ll allow up to three “hops” of rebroadcasts before giving up.<br /><br />This does mean we’re going to have a lot of traffic bouncing around at times. We minimise this by the three hop rule and also by checking to see we haven’t seen this packet recently (if we have, just ignore it). It will also mean that a packet may find its way by several means to the destination address. We cope with this by sending an acknowledge back for the first one, and then acting on the packet. If another copy of the same packet arrives – we realise that the packet has already been received and don’t act on the packet, but we do send another acknowledge back, since this one may have come a second time because the originator didn’t get our first acknowledge.<br /><br />It all sounds a little complex, but in use you just set your local address and start sending out packets. It’s a good project to show how the various parts of the PicPack we’ve seen so far come together. And despite all this complexity, we have a meshed packet RF network in 3k of code. Not bad. That leaves you with at least another 1k of code to actually do something with those packets.<br /><br />Next time we'll have a look at the code that gets the packet network up and running.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-31760691150118380432008-05-06T11:31:00.007+01:002008-12-09T08:54:31.368+00:0015. All meshed up - Part 1 - RF commsI mean, really. Who doesn’t want to create their own wireless, meshed packet delivery network? This stuff is just, like, cool.<br /><br />This project all began when my elderly but still energetic parents rebuilt their house and decided in a moment of weakness to allow me to design the lighting and control systems. So naturally I had all the light switches installed as X10 controllers and all the lights themselves connected via X10 lamp dimmers. Then a bunch of X10 PIR sensors send movement information to the house controller PC via a third party receiver. Then as you walk through the house the lights come on when you’re in the room and the controller PC also knows which lights are on.<br /><br />So it goes in theory. In practice, every now and then an X10 lamp dimmer dies which is a total pain – they’re mounted in the wall cavities after all. Sometimes the modules forget their settings, and the X10 protocol doesn’t actually make it all the way through the house, despite adding an expensive module that’s meant to relay and amplify the signals. And with me living in London and them in Australia, it’s all a little difficult when it goes wrong. Still, it’s cool being able to control their lights from the other side of the planet.<br /><br />My plan was to replace the unreliable X10 controllers and lamp dimmers with RF modules. Of course you could never guarantee that the modules could talk to each other directly, my parents have internal brick walls that really wreak havoc with anything wireless. So the network would need to be resilient to this type of problem.<br /><br />And as soon as you start creating something like this, you start to see lots of ways it could be used. Temperature and humidity sensors, real time clock information, movement sensors… you name it!<br /><br />I did look at Zigbee of course, and that’s great in theory, but the most popular modules require a star network with controllers and don’t actually do proper meshing. Besides, I thought it would be fun to design my own.<br /><br />I started out with the Sparkfun nrf2041a modules and a couple of their Serial Development Node (version 1). These are designed to work together and the SDNs provide translation of signals to RS232, a 16f88 pic on board and spot to plug a 2401a module straight into. Perfect!<br /><br />The first chunk of work was to get the actual Nordic transceiver nrf2401a chips working and chatting away to each other. Let’s look at that first, and then in the next article, look at how the packet delivery network works.<br /><br />The PicPack library supports both the nRF2401A and the nRFL01 chips, seamlessly and simultaneously on the same network. We’ll have a look at the 2401a here. Open up the packet_demo project.<br /><br />Naturally the first thing you need to define the ports and pins used to communicate with the 2401a in your config.h file:<pre class="code"><br />// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br />// pic_rf include<br />// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br />// For SFE_TDN_V1 board<br />#define rf_ce_port PORTA<br />#define rf_ce_pin 6<br />#define rf_dr1_port PORTA<br />#define rf_dr1_pin 3<br />#define rf_cs_port PORTA<br />#define rf_cs_pin 0<br />#define rf_data_port PORTA<br />#define rf_data_pin 2<br />#define rf_clk1_port PORTA<br />#define rf_clk1_pin 1</pre><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZKR8uuzoYzeO1aRBr1MGEHsKLBFqOIiWTFvWK3wRyX1w7YDG1sZL5Eo7jBVNNyJ8YK9ehL2fRzB3JovaewczV3yqQvaHZ2rpOAtFRbN9AYNaK6s1tWULZDshwEIzfWEmoDPcxdaC2XzY/s1600-h/link.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZKR8uuzoYzeO1aRBr1MGEHsKLBFqOIiWTFvWK3wRyX1w7YDG1sZL5Eo7jBVNNyJ8YK9ehL2fRzB3JovaewczV3yqQvaHZ2rpOAtFRbN9AYNaK6s1tWULZDshwEIzfWEmoDPcxdaC2XzY/s320/link.jpg" alt="" id="BLOGGER_PHOTO_ID_5202809585293337922" border="0" /></a>These are the ports and pins used by the SparkFun Terminal Development Node modules. There is, however, a catch. In their ultimate wisdom, the SparkFun guys (bless ‘em) wired the DR1 output from the 2401a to port a, pin 3. The DR1 “Data Ready 1” output goes high when a packet has been received. Now, this doesn’t seem like much of an issues, except that we’d really like to interrupt whatever the pic is doing at the time when a packet arrives. All this polling to find out what’s going on stuff is just silly. So you’ll need to wire the porta pin 3 to port b pin 0. It’s easy, you just need to install a “link” in the alternative connector on the board. You can see from the picture that it's the second and fourth holes on the second row back that need linking.<br /><br />So, the first thing you need to do, as usual, is run the setup routine that’s part of the library to set the ports and pins to be the right inputs or outputs:<pre class="code"><br />pic_rf_setup();<br /></pre>Then, as usual, you’ll need to actually initialise the hardware itself for use. The trickiest part about using the 2401a is that it pretty much sits there like a dead duck until you get the configuration right, and then it springs into life. Until then, you really have no idea what you’ve got wrong. PicPack provides two routines for configuring your 2401a. We’ll look at the more verbose one first. You need to setup the rf_config struct with all the settings you care about – then pass a pointer to it to the pic_rf_init() routine. Let’s work through the config.<pre class="code"><br />rf_config my_config;<br /></pre>The Nordic transceivers can receive on two (or more) channels at once. We don’t care about this for our purposes, so we set the payload size (or width, in bits) to zero.<pre class="code"><br />rf_config my_config;<br /></pre>For our primary channel, we do care – it has to be the same size as (in this case) our packet size.<pre class="code"><br />my_config.payload_width_ch1 = PKT_PACKET_SIZE * 8;<br /></pre>Here we fill in the address for channel 2, although it’s actually not important want you do or don’t do with these values:<pre class="code"><br />my_config.address_ch2[0] = 0xf0;<br />my_config.address_ch2[1] = 0xf0;<br />my_config.address_ch2[2] = 0xf0;<br />my_config.address_ch2[3] = 0xf0;<br />my_config.address_ch2[4] = 0xf0;<br /></pre>When it comes to the channel 1 address, we do care. Here’s the default address for Nordic chips, and in this case, we’re using address 0xE7E7E7. We specify two more bytes than we need just for completeness.<pre class="code"><br />my_config.address_ch1[0] = 0b11100111; // addr starts here<br />my_config.address_ch1[1] = 0b11100111;<br />my_config.address_ch1[2] = 0b11100111;<br />my_config.address_ch1[3] = 0b11100111; // only used three but fill<br />my_config.address_ch1[4] = 0b11100111; // ...for the fun of it<br /></pre>In order to tell the chip we’re using 3 byte addresses, we set the address_width to 24 (8*3).<pre class="code"><br />my_config.address_width = 24; // (6 bits valid)<br /></pre><br />We want to have a 16 bit CRC check on the packet. This is how the chip tells a real packet from noise in the air. At 1 Mbps you’d be amazed how often noise turns out to give correct CRC values with 8 bit CRCs. 16 bit CRC is much better, but is still not 100%. That’s why the PicPack library has its own check byte as well.<pre class="code"><br />set_bit(my_config.options, OP_LONG_CRC);<br /></pre>Now we enable having a CRC as part of the transmission:<pre class="code"><br />set_bit(my_config.options, OP_ENABLE_CRC);<br /></pre>Turn off the second channel:<pre class="code"><br />clear_bit(my_config.options, OP_ENABLE_CH2);<br /></pre>Shockburst is the name Nordic gives for clocking your packet in to the chip and then sending it out on-air at the correct bit rate in one go.<pre class="code"><br />set_bit(my_config.options, OP_ENABLE_SHOCKBURST);<br /></pre>You can turn this bit off to enable 250kbps rate, which does give slightly longer range. 1 Mbps gives you less chance of packet collisions, which is why I recommend it (as well as giving compatibility with the nrf24L01 chip).<pre class="code"><br />set_bit(my_config.options, OP_ENABLE_1_MBPS);<br /></pre>On the SparkFun boards, they’re wired up with a 16Mhz crystal, which is why we choose that option here:<pre class="code"><br />// (3 bits valid) -> 16Mhz<br />my_config.crystal = 0b011;<br /></pre>You have two bits (4 levels) of output power:<pre class="code"><br />// (2 bits valid) 11 -> max power!<br />my_config.output_power = 0b11;<br /></pre>We can choose any of a gazillion channels, and the Nordic chip can hop around then quite quickly. Still, at this stage of the library, we pick one at the start and leave it at that. I thought it would be good to look at a frequency hopping algorithm, but this does get hard when you have a meshed network. Fine when it’s one on one, but when there’s three or more units, how does everyone keep in sync? If you have any ideas, I’d love to hear them. In the mean time:<pre class="code"><br />my_config.channel = 2; // (7 bits valid)<br /></pre>Last but not least, we put the chip into the receive mode:<pre class="code"><br />set_bit(my_config.options, OP_ENABLE_RECEIVE);<br /></pre>And then with a little flourish, call the routine that takes this information and passed it to the 2401a to get it initialised.<pre class="code"><br />pic_rf_init(&my_config);<br /></pre>As you can imagine, this programmatic way of telling the Nordic chip what to do is easy to understand and gives you the ability to change things at run time. You’ll also realise that this does take a chunk of code (and hence flash) to do all this. If all you want to do is set the config right at the start and not change it after that (other than the channel) then you can use the quick method:<pre class="code"><br />pic_rf_quick_init("\x00\xa8\xf0\xf0\xf0\xf0\xf0<br /> \xe7\xe7\xe7\xe7\xe7\x63\x6f\x05",<br /> 2, 1);<br /></pre>This does exactly what the previous chunk of code did. The ‘2’ parameter is the channel number, and ‘1’ turns the receiver on. To generate this config string, use the nrf2401a_config.pl script in the tools directory. You don’t need to know anything about perl (other than having it installed somewhere!) – just edit the file and run it to get it to spit out the config string.<br /><br />So how do you go about sending data across the link? Well, here’s how the packet routines do it:<pre class="code"><br />void pkt_send_packet(rf_packet *packet) {<br /> // +3 for RF address (fixed)<br />uns8 tx_buffer[PKT_PACKET_SIZE + 3];<br />uns8 count;<br />tx_buffer[0] = 0b11100111; // address<br />tx_buffer[1] = 0b11100111; // address<br />tx_buffer[2] = 0b11100111; // address<br />for (count = 0; count < PKT_PACKET_SIZE; count++) {<br /> tx_buffer[count+3] = packet->a[count];<br />}<br />pic_rf_transmit(tx_buffer, PKT_PACKET_SIZE + 3);<br />}<br /></pre>You can see it’s as simple as whacking the destination address on the start. In the case of the packet network, we’re assuming everyone’s on the same address. Of course, you could use these routines to direct your data to a particular node directly using this addressing.<br /><br />Receiving data is only slightly more complicated. Since we’ve wired up the DR1 line to the port B, pin 0, it means that we can use an interrupt to detect when the nRF2401a wants to tell us something. This is much better than having to poll for data all the time. The 16f88 has two ways of detecting interrupts, but the one we want is when port B, pin 0 goes high. It’s set up like this:<pre class="code"><br />make_input(PORTB, 0);<br />set_bit(intcon, INTE);<br /></pre>You’ll need to turn interrupts on as well:<pre class="code"><br />turn_global_ints_on();<br /></pre>In your interrupt() routine you can use something like this:<pre class="code"><br />if ( test_bit(intcon, INTF) ) {<br />pic_rf_receive(rf_rx_buffer, MY_BUFFER_SIZE);<br />clear_bit( intcon, INTF);<br />}<br /></pre>Notice how you test for the interrupt flag being set, respond if necessary, and then clear the flag.<br /><br />That’s all there is to it. Next tutorial we’ll start looking at how to create a packet network on top of the RF communication we’ve set up here.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com3tag:blogger.com,1999:blog-4829924363554235528.post-52520344951518451082008-04-29T12:33:00.005+01:002008-05-19T15:59:43.990+01:0014. Of Ports and Pins and SFRsUp until now, I’ve conveniently skipped over how the PicPack libray handles the read-before-write problem on low to mid range pics, or even what this issue is really all about. It provides a simple solution to a complicated problem, but it bears explaining since you’ll learn how these devices work under the covers. <br /><br />On Microchip micocontrollers, like many similar devices, allow you to make a given pin either an input, or an output. And you can change this programmatically at runtime as well – handy talking to some devices over a bi-directional data line. There’s some circuitry that can detect if there’s a high or low value present on a pin and also what’s known as a data latch attached to the same pins. The data latch is an output device that holds the value you give it until you change it.<br /><br />The problem with Microchip pic devices prior to the 18f range is two fold – firstly that the output latch isn’t readable and secondly that all outputs are done at the port (not pin) level. What this means is that when you just want to change one output pin in a port from one value to another, the chip doesn’t know what the current values on the other pins are. Say you’ve set pin 1 to high previously, and now you want to change pin 2 to a high as well. It doesn’t have any record of what the previous value of pin 1 was set to (remember, the data latch isn’t readable) and all outputs to the latch happen at a port level (so it has to write values to all the pins in a port at once). The way the chip gets around this is called “read before write”. It reads the value on all the pins in the port (that is, the actual value present on the physical pins of the pin), then changes the pin you’re interested in, and then writes the whole port back again.<br /><br />So, in our example, it should read a high value on pin 1 (since this is what the latch is outputting), change the value on pin 2 to high and write them both (and the other pins in the port of course) back to the latch, resulting in pin 1 and pin 2 set to high values.<br /><br />That all sounds fair enough. It’s clearly a bit of a pain, but surely the output of the latch is the same as what you told it to output, so what’s the problem? Well, in theory that’s perfectly true – but in practice, it doesn’t work like that. Imagine that as part of your circuit you have a capacitor connected between your output pin and ground. The reason why you’d do this isn’t important right now. You can imagine that when you set that pin high, it’s going to take some actual real life time to get to the point of actually reading at a high level. Maybe just microseconds, but still, some time. Now imagine if you set this pin high then, very quickly, set another pin high. Your capacitor laden pin is going to be read and the chip may decide that in fact that pin is low at the moment since the capacitor hasn’t charged to the high level.<br /><br />Eek! That means that the pin is going to get written back as a low! Disaster! In fact, it doesn’t just happen if you have something capacitor-like attached to the pin, it can happen even with a set of leds and resistors. What to do?<br /><br />The answer is to simulate the readable latch that we don’t have. The PicPack library provides a “shadow” port that it writes changes to before copying it to the whole port. Of course this results in slightly more code – instead of a one instruction bit-set you end up with three. As I’ve learnt with microcontrollers, everything is a compromise. Presumably Microchip saved some money by not having a readable latch in these devices, but it costs you an extra couple of instructions to guarantee the value on an individual pin. The 18f devices (and onwards) have a readable and writable data latch that makes this problem redundant, but without needing to make any chances, the PicPack library makes your code transparently portable between these devices even though 16f devices don’t have a readable data latch.<br /><br />At the end of the day you can use the PicPack routines without having to worry about what’s happening under the covers – and this makes your code more portable and readable as well. It’s worth explaining how PicPack achieves this without taking too many instructions, and even without having to tell it how many ports your device has.<br /><br />Open up the include file for the chip you’re working on at the moment. This example uses the 16f88, which for me, is located at c:\Program Files\SourceBoost\include\pic16f88.h.<br /><br />Pics have a memory space for RAM which includes clumps of “magic” memory locations that do things when you read to them or write to them. These locations are called Special Function Registers or SFRs. You write to a port, for example, by writing a value to a SFR that results in the port being changed. <br /><br />BoostC include files define the address of these SFRs, and then define a variable that is located at that address. That means that when you set that variable, you are writing data to that memory address – which means writing data to the SFR which causes the chip to do something.<br /><br />I’m being long-winded about this because it is actually quite confusing until you get your head around it.<br /><br />Have a look at the include file. You’ll find the definition of our port locations:<pre class="'code'">#define PORTA 0x0005<br />#define PORTB 0x0006<br /></pre>Notice that the PORTA and PORTB are in capitals. Later on, you’ll see in the same include file:<pre class='code'>volatile char porta @PORTA;<br />volatile char portb @PORTB;</pre>So, here we define two global variables, porta and portb that happen to reside at the right place that if you read or write to the variable, you end up reading or write the similarly named SFR. Do you see how the variables use lower case letters, but the actual address is in capitals? Thankfully SourceBoost provide these pre-made include files for just about every pic out there. They’re choice of capital vs lower case is somewhat in contrast to other pic compilers, and sometimes the variable names and address locations aren’t even the same as what is in the data sheet for the same pic, just by way of warning. As I’ve said, portability is relative these days, even if we’re all talking C.<br /><br />Now, all the “bits” of the SFRs are defined in here as well – so you can, for example, set the timer 0 interrupt enable bit of the intcon SFR by using:<pre class='code'>intcon.TMR0IE = 1;</pre>This is bit setting notation is handy for single pins, but I prefer the more portable macro that SourceBoost provides:<pre class='code'>set_bit(intcon, TMR0IE);</pre>It results in the same code generated, but it means you could port to a different compiler (or microcontroller vendor if need be) more easily.<br /><br />Now, you can see here we’re setting bit 5 of the intcon variable (actually memory location 0x000b). This is all okay, since SFRs beyond ports don’t have real-life outputs and hence don’t suffer from the read-before-write problem.<br /><br />In order to make sure we generate as little code as possible, PicPack sets up an array at the same location as the port and tris SFRs in the pic_utils.h file:<pre class='code'>volatile uns8 port_array[NUMBER_PORTS] @PORTA;<br />volatile uns8 tris_array[NUMBER_PORTS] @TRISA;</pre>The tris SFRs are used to set whether a pin is an input (1) or an output (0). “Tris” comes from the (copyrighted) word tri-state, since a pin can be an output at high, an output at low, or an input (and high impedance). You’ll see shortly that you don’t even need to worry about this tris malarkey either with the pic_utils library.<br /><br />These declarations don’t use any memory up – they just make it handy when we’re moving things around. We also declare the shadow array:<br /><pre class='code'>extern uns8 port_shadow[NUMBER_PORTS];</pre><br />The NUMBER_PORTS define has already been calculated for you, earlier in pic_utils.h. The actual useful functions are defined like this:<pre class='code'>#define set_pin(port, pin) \<br /> set_bit(port_shadow[port - PORTA], pin); \<br /> port_array[port - PORTA] = port_shadow[port - PORTA];</pre>So our set_pin routine just works out which shadow location it needs to change, then copies the whole byte to the port at the right location. Through a great deal of experimentation, I’ve found that this results in the smallest amount of generated code. Even though it looks like we have lots of calculations to do, if we’re using known ports and pins then the compiler does what’s called “constant folding” and all the calculations are done as the code is compiled, not at run time.<br /><br />So, to set bit 5 of porta, you need to:<pre class='code'>set_pin(PORTA, 5);</pre>Note that this is set_pin, and not set_bit, which is the generic macro for manipulating any byte. Set_pin and its friends are only for actions on ports.<br /><br />This is why you’ll see these sort of #defines that you provide in your config.h:<pre class='code'>#define i2c_scl_port PORTC<br />#define i2c_sda_port PORTC<br />#define i2c_scl_pin 3<br />#define i2c_sda_pin 4</pre>You can see the PORTC in capitals here. Once you’ve defined it, you can use i2c_scl_port and i2c_scl_pin and it’s much more readable form the code what you’re talking about. In addition, if you decide to move where the hardware’s connected to, all you need to is update it in one place in the config.h.<br /><br />The routines that are provided are:<pre class='code'>set_pin(port_sfr_addr, pin)<br />clear_pin(port_sfr_addr, pin)<br />toggle_pin(port_sfr-addr, pin)</pre>These work exactly as you’d expect, all buffered and safe from read-before-write problems. There are a couple of other handy functions as well:<pre class='code'>test_pin(port_sfr_addr, pin)</pre>returns the value of the pin (given it’s an input) allowing you to use the same naming convention for your input ports as well as outputs, eg:<pre class='code'>set_pin(PORTA, 1);<br />if (test_pin(PORTA, 2) {<br /> // do something<br />}</pre>You can also change a pin to a given value, eg,<pre class='code'>change_pin(port_sfr_addr, pin, value)</pre>like:<pre class='code'>#define MY_VALUE 1<br /> change_pin(PORTA, 2, MY_VALUE);</pre>Now, because of the way code is generated for pics, when you’re using constants for the pin and port values, these #defines give you nice, simple code. When you’re using variables, however, it does end up with more code. At that point, you’re generally better off using these set of functions:<pre class='code'>set_pin_var(port_sfr_addr, pin)<br />clear_pin_var(port_sfr_addr, pin)<br />toggle_pin_var(port_sfr_addr, pin)<br />change_pin_var(port_sfr_addr, pin, value)</pre>These functions actually use subroutines instead of inline code, but will result in less code overall if you want to do things like:<pre class='code'>uns8 my_pin;<br /> my_pin = 5;<br />set_pin_var(PORTA, my_pin);</pre>It’s a subtle difference, and it other environments, (eg programming for PCs) you wouldn’t even bother make the distinction. When every byte counts though, it’s worth making the effort. Of course, this uses another stack level – so you may wish to swap code size for stack level and use the set_pin version nevertheless.<br /><br />As a general note, I’m pretty sure none of the PicPack library actually uses the set_pin_var family of functions. You’ll probably find that you generally know what pin you need to change well in advance – ie, at compile time.<br /><br />Finally, these routines also make it easy (and beautifully clear in your code) to make pins either inputs or outputs:<pre class='code'>make_input(port_sfr_addr, pin)<br />make_output(port_sfr_addr, pin)</pre><br />Again, this allows you to do things like this:<br /><pre class='code'>make_output(PORTA, 3);<br />set_pin(PORTA, 3);</pre>Notice how you don’t even need to know anything about tris bits and it is quite obvious what’s meant to be going on.<br /><br />By way of summary, for the imaginary rt373 device, define your ports and pins in your config.h like this:<pre class='code'>#define tr373_data_port PORTB<br />#define tr373_data_pin 1<br />#define tr373_clk_port PORTB<br />#define tr373_clk_pin 1</pre>And then you can do things like this:<pre class='code'>#include “pic_utils.h”<br /> // setup ports and pins<br />make_input(tr373_data_port, tr373_data_pin);<br />make_output(tr373_clk_port, tr373_clk_pin);<br /> // clock in the first value<br />clear_pin(tr373_clk_port, tr373_clk_pin);<br />set_pin(tr373_clk_port, tr373_clk_pin);<br />my_value = test_pin(tr373_data_port, tr373_data_pin);</pre>…and so on. Easy! Note that while the PicPack library currently doesn’t do anything differently for PIC18 devices, the routines are perfectly portable between the devices without any code or even config changes.Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com2tag:blogger.com,1999:blog-4829924363554235528.post-67300578674213166652008-04-28T09:20:00.001+01:002008-04-28T09:23:48.451+01:00PicPack 1.1 releasedThe latest version of the PicPack is now released.<br /><br />This includes more documentation on units, packet demo (tutorial coming soon) and fixes for boostbloader.<br /><br />Note the function in the packet demo that allows you to press "download" on screamer to update your software without having to hardware-reset the pic. Very neat!Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0tag:blogger.com,1999:blog-4829924363554235528.post-84274027283563072492008-04-22T13:54:00.004+01:002008-04-22T13:59:14.298+01:0013. It's about timeFollowing on from our discussions on getting the temperature via i2c, we’ll look at talking to a real time clock chip such as the ds1307. It’s a little more complicated than just getting the temperature – but mostly because there’s just more data available. The way we interact with the chip is very similar.<br /><br />Now, you might ask why we need a separate chip to look after the time. Why can’t we do it all on our pic with our nifty timer routines? Well, we could. In fact, you can even drive one of the timers from an external crystal designed for handling real time clock type problems. There are, however, some good reasons to keep it all separate.<br /><br />The first is that the DS1307 has support for battery backup – from a 3v CR2032 or similar, which will run it for 10 years or more. That’s effectively lifetime of the device. So when the device as a whole is powered off, the time will still be current. The other neat aspect is that the DS1307 has a bunch of non volatile RAM slots left over (56 byte to be exact) which we can use for our own nefarious purposes. You could use a pic that has no EEPROM (these are generally a lot cheaper) and store your info in the DS1307. Neat!<br /><br />In any case, it’s a good example of another external device we can talk to over the i2c buss. You could connect a DS1307 and an LN75 on the same buss and talk to them both using only two wires.<br /><br />Open up the ds1307 demo project. You’ll notice that in our configure_system routine we have:<br /><br /><pre class="code"><br />rtc_setup();<br /></pre><br />This in turn calls i2c_setup() to configure port and pins as inputs or outputs as appropriate, ready for communication.<br /><br />In request_time() we do some simple requests:<br /><br /><pre class="code"><br />minutes = rtc_get_minutes();<br />hours = rtc_get_hours();<br />seconds = rtc_get_seconds();<br /></pre><br />And print out the result. All pretty easy so far.<br /><br />It gets a little more tricky in process_rx() which allows us to enter commands like:<br /><br />sm23 <enter> <enter><br /><br />over a serial connection, to set the minutes to 23. The same goes for hours and seconds, using<br /><br />sh12 <enter><enter><br />and<br />ss04 <enter><enter><br /><br />If you have a look at ds1307.c, you’ll notice that most of the routines are simply wrappers around the i2c routines. Some add a little bit of value, by masking out bits, but even then, they’re mostly one liners. This brings us to the challenge of programming such limited devices – you’ve really got a choice between stack size and code size. If you use a sub routine only once – then it’s probably worth turning it into a #define or using the inline keyword. That means the code it uses gets placed in the actual location it’s used, and you save a stack position. In 16f88 devices, there are only 8 places in the stack. If you use interrupts then you’ll use 1 when an interrupt is called, even before you call any subroutines. So you need to make sure the stack never exceeds the interrupt level + main program level. If you do exceed this, on the 16f88 it will happily wrap the stack around and you’ll have lost the first stack position. In reality, this normally results in generally strange behaviour. If your program is using interrupts, and sometimes crashes, prints out strange repetitive things to the serial port or seems to jump back to the boostbloader, then you’ve probably got a stack overflow.<br /><br />You can check to see if this is possible by looking at the BoostC output. It will print out a quiet little warning that you’ve exceeded the maximum stack level if everything happens at once (remember, BoostC knows about the whole program structure at the start, but it can’t know if the interrupt happens at the deepest main program stack position). I keep getting caught in this – strange behaviour, start putting serial_print_str in to find out exactly where it crashes (strange, those routines have worked for ages) - only to discover that there’s a potential stack overflow lurking around.<br /><br />Sourceboost provides some very handy tools for find out what to do here. If you press the Code button on the tool bar and open out the pane that the code shows in, you can see the entire call tree of the program. This feature is worth the price of Sourceboost alone – you can easily see which tree branches are the longest and start to do something about them.<br /><br />The Function Info pane shows more information about each subroutine so you can see which ones are chomping up flash memory and RAM. My only wish here is in a future version that the #Global line will be expandable. I’d love to see where the global variables that are taking up RAM are coming from. The assembly tab then gives you a fantastic rundown of what assembly BoostC has come up with for your routines – and gives you the chance to optimise this. Often you have to be quite crafty to reduce your flash and RAM footprint. Sometimes its just tonnes of serial_print_str statements.<br /><br />So, if you find that the ds1631 demo is too big for your chosen pic, the easiest way to trim it down is to take out or simplify some of the serial_print_str statements. The main program “help” printout would be a good place to start.<br /></enter></enter></enter></enter></enter></enter>Ian Harrishttp://www.blogger.com/profile/15487144968961769398noreply@blogger.com0