#pic18f

Well we’ve had a very busy week! We’ve received the components ahead of schedule. Cases are on schedule, and the PCBs we’re pretty sure are on schedule. Our design created some questions from the Elecrow engineers we had to address prior to them being sent to production.

We’ve been bashing our head against trying to create a good example for using SPI to communicate with the MicroSD card. We were initially simply resetting the card and checking the response, however upon trying to send more commands we would get all sorts of nonsense, everything from illegal response values to the card hanging up and today...we finally discovered the issue...

Usually when using an SPI interface, the master has exclusive control of the clock, the slave can only send data back to the master while the master is sending data to the slave and toggling the clock input. We had initially assumed that the XC8 library functions would operate similarily we were wrong!

With the XC8 SPI libraries, calling ReadSPI will generate clock cycles

Just check this snippet of code straight from the library...

unsigned char ReadSPI2( void ) {      unsigned char TempVar;      TempVar = SSP2BUF;       //Clear BF      PIR2bits.SSP2IF = 0;     //Clear interrupt flag      SSP2BUF = 0x00;          // initiate bus cycle      //while ( !SSP2STATbits.BF );                // wait until cycle complete      while(!PIR2bits.SSP2IF); //wait until cycle complete     return ( SSP2BUF );      // return with byte read }

...as you can clearly see it DOES in fact generate clock cycles on its own by writing a dummy byte out of the SPI channel. However this isn’t documented anywhere that we’ve been able to find, and is clearly something that would assail someone trying to use our devkit. With how we’ve learned to use SPI we would write something like:

Wrong Way: WriteSPI2(0xFF); res = ReadSPI2();

But with these libraries, that would actually write out 0xFF AND 0x00 before we read our result, potentially causing us to miss our response as we were expecting to receive it on the first write. The correct way, with MPLabX and XC8 is this

Right Way: res=ReadSPI2();

This is PICxie, a keychain-sized self-powered embedded systems development kit! It features a MicroSD card slot, IR receiver, and USB port on one side, and expansion ports for I2C and 3.3v on the back. It’s internally powered and rechargeable via USB. It comes preloaded with Microchips HID bootloader software, but has an exposed I2C header on the PCB for use with a PICkit2/PICkit3 if you take it out of the case.

The PCB measures only 77.22 square Cm, compare it to a Gumstix Computer-on-Module which measures 160 square Cm. But comes housed in a durable 1"x1″x1″ 3D printed cube. It has a PCB mounted microphone and speaker, as well as a 6-axis IMU, Altimeter, Barometer, and Temperature sensor. The module also has full RGB lighting for entertainment and indication.

Things PICxie can be used for:

Magnetic Field and Gravometric Field surveying

Model Rocket blackbox (Orientation tracking and Altitude logging)

Wireless Server when combined with an ESP8266

Position logging when combined with a GPS module

Autonomous vehicle and UAV controller (Robots anyone?)

and MOAR!

We used the alpha version of PICxie (Formally called TheBug) to do all of these things. We are currently beta testing PICxie, and we’re considering doing public beta testing. Just send an e-mail to [email protected] if you’re interested!

PICxie Provides Limitless Potential

Combining everything you could ever want into one small, self-powered, and portable package makes PICxie the last solution you'll ever need for embedded systems development. From environmental monitoring to robotics and beyond, PICxie pushes the limits as to what a development kit should be

Hi everyone, Michael Stone here, some of you MAY have noticed the sudden lack of “HEY BACK OUR KICKSTARTER!” tweets. That’s because on the weekend I run a lot of the social media stuff that I don’t have time to really do in the week. This weekend however I decided I’d put myself to a challenge:

“Take an idea, and make it a reality in no more than 48 hours”

Can I Build It? YES I CAN!

Now there are SOME limitations, I can’t 3D print anything, or get parts from digikey, within 48 hours. So that wasn’t part of the challenge. The main goal was to get a Bill-of-Materials, a set of Gerber files, and a set of STL files for a case.

I decided to take this challenge for a few reasons. Last week if you were watching my Twitter, you may have noticed we were offering to give you a alpha version of a small development module. While this failed to entice any backers to our cause, we actually got a lot of positive response about our PICxie, one person actually said he would back a Kickstarter for PICxie but not Muribot! 

We found that very humours, because PICxie Alpha was simply a disembodied Muribot brain :)

We actually got so much e-mail about it (over 230 e-mals and messages!)...that at the end of the day on friday we decided that if we could very quickly shift that into something resembling a real product we could totally Kickstart, we never got that sort of response with Muribot

Not a single e-mail about Muribot...maybe we should have Kickstarted PICxie instead!!!

I still haven't been able to catch my friend on a free day to make the kickstarter video, so in the meantime I've been working on anything I can make progress on. I don't NEED the funding to do some things, but I do need it to help with prototyping. Unlike a lot of my solo funded projects, this one is not just for my own amusement, and I'm trying to create something that will open robotics up to the widest possible audience.

The bootloader code is coming along nicely. The microprocessor portion is done, it's simply responsible for checking if the PC is connected and if so reading data from the PC. The PC is responsible for much more, it's responsible for making sure that the users code won't poke around where it isn't supposed too. To do that we basically disassemble the code and check to make sure that particular opcode doesn't do anything that would touch the bootloader code.

Disassembly is very interesting, take the following opcodes, they usually appear in hexadecimal format

158A 2F9B

Each opcode is 2 bytes long, which means that the first opcode is 15 and 8A and the second is 2F and 9B. The first byte is called the high byte, and the second the low byte. We actually need to split these in half again, ending with:

1, 5, 8, and A 2, F, 9, and B

By looking at the datasheet for the microcontroller, we can see that the commands are divided into 4 categories:

0 - General Commands (22) - these commands include addwf, subwf, return and nop; and ones that affect the F register 1 - Bitset and Bittest commands (4) - these commands set and test individual bits 2 - Call and Goto 3 - W Commands - These commands affect the W register

From each of the first half bits, we can see the first command is a Bcf, Bsf, Btfsc, or Btfss; and the second is a Call or Goto! Awesome! What next? Checking the datasheet again, you'll notice that for each of the commands, the second half-byte is specific, this is how we identify which of the commands is the one we want

The first one is 5, well the half bytes only come out to 0, 4, 8, and C so which one is the right one? The answer is to round down to the closest number, in this case 4. That means we have a BSF command, which is exactly right. The next command, the half bytes come out to 0 and 8, applying the round-down rule we can see that this is a GOTO command, which is also correct!

The complete dissassembly is:

BSF 0x10, 0x03 GOTO 0x79B

I got approval from Kickstarter.com! As soon as I upload some videos I should be able to start getting funding for V2.0 which will include some much needed design changes:

The main microprocessor will communicate over I2C with a microprocessor dedicated to controlling the motors. This ensures we get the most responsive motor control possible, while leaving plenty of processing time for the main microprocessor

The main microprocessor will now use a 40Mhz crystal oscillator. Coupled with delegating the motor control, this will leave a lot more processing time available to the user

Upgraded sensor number from 3 IR sensors to 8.

USB Connectivity so a PICKit2 is no longer a necessary requirement.

Removal of PCB ground and power planes to make soldering easier

For the main microprocessor, I am switching from the PIC18F2620, to the PIC18F2550. The pin-out is different enough that the PCB will have to be redesigned around it, but the USB functionality is needed. The motor processor is a PIC16F1825, this one was chosen for the fact is has just enough pins for the job, has I2C built in (like the 18F), and runs at a speedy 32Mhz with the internal oscillator.

On the 18F, We have lots of digital I/O ports left over that I don't know what to do with yet, in the previous design, they were used to control the H-Bridge. I can't find a chip with a smaller pinout that still has USB functionality, so I guess I'll have to figure out something.

I've started a design blog for my group. We are Mid-Ohio Area Robotics, a group founded this year in central Ohio for electronics and robotics enthusiasts. This year we also created our first robot, the M.I.N.I. Mouse

This robot was created to be a direct competitor to the K-Team series of robots. Our end goal with this series is to create a robot as sophisticated as the K-Junior or Khelpera, but vastly cheaper and more available to the people. This particular robot costs $650 dollars, compared to the $1,000 for the K-Junior and $2,750 for the Khelpera.

MINIMouse v1.0 Featuers:

3x IR Sensors, 3" to 3' range. 1x CMUCam3 (Not Pictured) 1x Rate Gyro 2x Wheel Encoders 1-2Hrs of Battery Life PIC18F Based Microprocessor .5-3 M/s speed (Quite fast!)

If you are interested in buying one of these robots: Kit - $650 - Everything needed to build you're very own MINIMouse Robot. Solder Iron and PIC Programmer Needed. Assembled - $750 - A completely fully functional MINIMouse Robot. PICKIt2 Programmer is included.