• I've been working on jallib project, which aims to provide standard libraries to use with jalv2 compiler, with some other guys. Jallib is released under BSD and ZLIB licenses, and available on GoogleCode. A Google group is also available, this is where we discuss and debate about jalv2, jallib, etc...
  
• I've written some blog posts on jallib's blog
• I've migrated my SirBot's projects and javl2 libraries to jallib
• I've re-written an important of SirBot communication layer, now based on Twisted. This provides a extremely powerful base, without threads, easy to maintain
• I've played with Flex, Adobe's OpenSource RIA framework, and tried to prototype a Flash-based GUI for SirBot's monitoring widgets. Quite promising...

Two new boards are available from SirBot Modules. Both are using a new bus cable connector, and were designed using Eagle.

Many months (about six) have passed since the last Sirbot release, it's now time for a new one. Just need to finish the ChangeLog...

Weeks ago, while I was trying to interface my mainboard with a DC motor controller board, I had to dive into the i2c protocol. Serial com. couldn't make the deal, as I plan to connect several daughter boards, thus need to address them. Although RS485 was also possible, it implied a lot of changes, particularly on the PC side where I'd need an adaptor...

Anyway, just as blinking a LED, i2c is a must-have protocol. Several links helped me a lot, like this one explaining the whole theory, step-by-step, message-by-message. But the most helpful documentation still remains PIC 16F88 datasheet, and the Application Note AN734A which explains quite well how to implement an i2c slave as a state-machine. An interesting post is also explaining this very same App. note has a lot of bugs. I wouldn't say "a lot", still there's a little bug about clock stretching: CKP must be set to high when receiving a NACK. Anyway...

So, this time, this is about setting an i2c communication bus between two PIC 16F88, using Jal v2. The first thing to note is 16F88 implements SSP (Synchronous Serial Port), but not MSSP (Master Synchronous Serial Port). This means 16F88 can't be just configured to act as a i2c master, all of this must be done in software. Good news is jal v2 standard libraries come with an i2c module, which can handle all the i2c protocol subtleties, from a master point-of-view...

This jal v2 master implementation isn't based on interrupts: since it's the master which decides to take control of the bus, there's no need to react to external event... except when using Multi-Master i2c bus. To help this, 16F88 can be configured to generate interrupts on START/STOP bits (which defines when the bus is available or not). A Multi-Master i2c bus seems great but I didn't give a try, regarding all the debugging time it took me to set a "simple" 1-Master/1-Slave bus.

So, the master part is ok, now the slave part. This is where things are getting tough. Particularly without any oscilloscope or digital probe/analyzer. 16F88 can be configured as a hardware slave i2c. An IC address must be set, it must be the same as the one the master is using... This is what I've first thought, but it's not actually exactly true ! Actually, SSP must be configured so SSPADD contains a 8-bit address, that is, with the 8th bit setting read/write address type. Whereas in Jal, IC address is coded on 7-bits. This means, for instance:

That is, if the slave is declared to have 0x5C address, the master will have to talk to 0x2E as jalv2 is actually shifting 1-bit while building a write- or a read-address. As usual (and as everyone seems to report), i2c com. problems mainly come from address issues.

Setting a i2c bus is quite easy, from a hardware point of view. SDA and SCL pins must be connected on each side, on a bus using pull-up  resistors to +5V. Different values can be used, they're determining the stability and the bus speed. I've successfully tried 2.2K and 3.3K, these are standard values.

I've just build another board, using toner-transfert-system (TTS). Last try required lots of trials/errors, still leaving unanswered questions... This time, the first try was perfect. Here's my ultimate recipe:

Tired of using a PCB pen to build my boards... Too time-consuming, not really repeatable, dirty... So, I've tested this method and here some results and thoughts.

This method consists in printing circuit using a laser printer. The paper is then ironed on the copper side of a board. The toner is transferred: you have a nice circuit drawn on your board. Because the toner is composed by small plastic particles, it protects tracks while etching the board. Results: a amazing PCB board, easy, cheap, fast.

That's theory...

Originally, this method seems to be first used by Thomas P. Gootee. While it exists commercial and expensive paper doing this (Press'n Peel for instance), he observed he could get the same results using some glossy photo paper, used for inkjet printers. The kind of paper is the key factor. And the iron temperature too. And also the ironing time. And the way you peel off the paper. And how you prepare you board. And also how you soak your paper. Lots of parameters, few data...

I'm not comfortable using glossy paper for inkjet on a laser printer. It can stick on the fuser and ruins the printer. Some people mention this. Others pretends to nice results using normal, standard paper. Some also have amazing results using mailing label backing paper, or glossy photo paper for laser printer. For now, I have tried standard paper, label paper and glossy photo paper for laser printer (see following results, except for label paper: I didn't even managed to print on it...).

Everyone seems to report it. The board has to be clean. Very clean. Some are saying it's important to prepare it using sand paper (or the like) so the toner has something to grip to. I'm always following those advices: clean the board with soap, use very thin sand paper, clean it again with soap, then clean it again with window cleaner to help drying it. It's ready.

About my iron, it's an old one. It doesn't heat a lot. I tend to iron a lot of time, while I'm not sure it's a good idea. I think it depends on how the toner has been fixed onto the paper.

While I was trying to build a new SirBot Mainboard, I took several pictures to report what I've done, what failed and what has been quite a success...

So, what to say ? Using standard paper won't produce good results ? For sure, at least for me. A glossy photo paper for laser printer is the minimum required. This is also a very first result. I needed a lot of attempts and I'm not even sure this is all repeatable. Probably the tricky ironing step needs for experiments. For now, I need to solder components on my new "half-professional looking" PCB...

Eagle is a great tool to design PCB board. I've used it to design my new mainboard. In its non-profit version, you can build board with two layers (bottom, top). But I only have single sided copper boards. So I used to deactivate, declare as forbidden the top layer. Often, Eagle can't create 100% routes, so I manually creates vias and straps (straps are wires, not tracks, maybe not the correct english word). Quite annoying, time consuming...

 

Following is a simple tutorial to let Eagle build its own vias and straps to reduce manual actions. This is a two steps approach

I've been struggle (I mean fighting against the whole universe's darkness) for three month trying to drive DC motors with a PIC 16F88. I know it would be tough, but I didn't know it would be so hard... Because this is about driving high currents (from ~500mA to 1A), and not just logic states as before. This SirBot ticket is a nice summary of what I've faced.




Of course, there's a lot of people doing this, but it appears experience cannot be shared as easily as for other projects. I mean it seems that there's a lot with the environment. Starting with the motor itself, which could definitively pertub the power supply, thus the PIC itself. Or the chip used to drive the DC motors: using L293D or its equivalent (but more powerful) SN754410 is not the same, and does not have the same impacts, particularly on the way the logic and the power supply are separated... And if anyhow you manage to get your motor rotating the way you want, as soon as you put it on load, you'll discover the whole thing isn't powerful enough...




Anyway, I couldn't mention here all the problems I've faced. For now, I have a quite nice configuration (after burning/killing no more than 4 PIC), using SN754410 (far better than L293D, less noisy, ...) driving my RC tank's DC motors. Driving both motors makes SN754410 hot, about 85/90°C) which activates its thermal shutdown, thus turning off the whole... But that's without heat sink DIP. If it persists, I'll surely need to pick up my recently received LMD18200 or use the driving motor part of the RC tank's original board... Whatever the result will be, for the time I've spent on it, I'll make a new nice page on SirBot Modules, showing my "DC motor controller board"... And I hope you'll mention my new BlueSMiRF bluetooth serial modem from SparkFun, which helped me a lot setting I2C communication both mainboard's and DC motor controller board's PIC. I need another entry... :)