Wednesday, October 15, 2008


PIC32 Printing > SDCard

As you see from the title, a lot of changes have been made since my last update. I purchased a PIC32 chip some time ago and have been itching to see what it can do.
The new chip runs so fast!
My first attempt at running a G-Code file just resulted in a loud one second buzz from the machine. It took me far longer to realise that what I had just seen was a few thousand lines of G-Code converted and run in about a second!

Most of the issues with porting the code from the PIC24 was to rescale all the timers and processes. Don't get me wrong, the PIC24 is am awesome bit of kit, it was managing to run the machine very well. The only issue I ever had with it was that it would not run a standard G code file straight from the disk without a small amount of segment pausing. I got round this by post processing the G code files to a binary format and this cured the problem.
With the PIC32 any hint of segment pausing went away, I can now take the standard G code exactly as produced by Enrique's tool suite, complete with all the comment lines and run seamless movements straight from the SD Card.

I have been asked what my connection is to the PC. The answer is : there is none. For the record my machine development has been done entirely without any direct connection to a computer. The only cable link has been via an ICD2 programmer when flashing the chip.

To run the machine, I switch on, then use the joystick buttons to scroll through the files on the SD Card, select the file to run with another button push. After file selection the machine drops into “manual mode” I am then able to position the tool using the joystick. When happy with the setup I push the button again and it switches into “Auto mode” to run the selected G code file.
Once in Auto, the machine can be flipped in and out of manual in case of emergency.

Its worth pointing out the small add on card used with the Explorer 16 development board. This card is all I have added to make the bot move, the circuit is very simple.
As you can see the chip is 100 pin, I am using a fraction of the resources and a small corner of the programme and data memory available, so plenty of room for development.
Quality of the printed parts has taken a step forward with the adoption of the new processor, I will take a few pictures in the next couple of days

Finally an apology, I have been very slow in blogging details of the machine, I did promise some time ago that I would post a circuit, unfortunately real life gets in the way of hobbies sometimes. When I do get time I like to play with the machine not sit about writing endless blogs about it! To make amends I have passed all the designs over to Bits-From-Bytes, Ian has been my mentor on both the PIC stuff and electrics. He has offered to take my unfinished circuit and sort it out with a view to having some boards made. This way it will actually get finished and to be honest he will do a better job of it. The intention is still to post the circuit independently from Bits-From-Bytes so anybody out there that feels like having a go can do so. In the mean time, anybody wanting the circuit as it is, just e-mail me, and I will send what I have, note though it is a design based on the 44 PIN PIC24 not the PIC32
Watch out for more news on the machine plus pictures of the latest output!

Cool stuff! Could you tell me a few additional things like, which compiler are you using, exactly which chip did you choose, how are you programming it and what clock rate are you running it at?
Thanks for the interest Forrest,I have been playing with two chips first the PIC32MX360F512L, this chip is the one in the photo and was the first chip to have the code ported over to it. The second chip is the PIC32MX460F512L, I have only just started with this chip, so far I have compiled the code and started loading the USB host software to put the G code onto a USB flash drive, hopefully in the next few weeks I can get the same function using a flash drive as we have at the moment using the SDCard.
If the USB code runs well I will standardise on the MX460 and have a software switch to change between SD or USB.

The MX360 is running at 72MHz, on the PIC32's equates to about 72MIPS.
The MX460 is running at 80MHz equating to about 80MIPS.

The development suite is standard free issue MPLAB 8.14(the latest version)I run the Free issue C32 compiler for the chips and use an ICD2 for debug and programming.
I am sure that Microchip have released a serial boot loader for the PIC32's but at this stage I have not downloaded it to see how it all works.
I hope this answers your questions.

If you are interested and fancy giving a hand with the development please feel free! I will do all I can to get you up and running.

I live in hope that at some stage the work I am doing with the PIC chips will be at least partially adopted by the core team as a viable alternative to the Atmel solution.
Hi Tofletcher,

I've always thought that the 'previous generation' PIC (16F648's) electronics gave a wrong impression of what can be achieved through PIC. With my company we've been using 18F4550 (w. on board USB) and 18F2620's in appliances. They're really powerful chips and they're just the low- to mid-range processors of microchip. It could be a performance improvement and cost saving to use PICs. Besides, I think there is a lot of PIC experienced folkes too.

I also want to start experimenting with microstepping using nanotec controllers. This could greatly enhance RepRap precision.
Nice to see somebody using modern technology with computing power appropriate to the job.
Do go for the microstepping its so much quieter and if the machine is anywhere near you this matters!
I have run 16th stepping since the start of the project and apart from the accuracy issue the machine runs smoother and very quiet compared to full or 1/2 stepping.
This comment has been removed by the author.
"I live in hope that at some stage the work I am doing with the PIC chips will be at least partially adopted by the core team as a viable alternative to the Atmel solution."

Although I'm on the core team and use Pic rather than ATMEL technology, I don't see Darwin moving away from ATMEL for the foreseeable future. There are a couple of reasons that I see that contribute to this situation.

1) There is a VERY strong bias towards Open Source (as opposed to ommercial or even free commercial like you are using)development systems that starts with Adrian and is shared by a large portion of the long-term core team. ATMEL fills that bill, Pic doesn't. The SDCC compiler that we were using in the old 16F628 days, not to put too fine a point on it, stank on ice.

2) The Arduino/Sanguino development path is being ramrodded by Zach, who is doing most of the electronics design work and, because he started and runs the Reprap foundation, which distributes PDBs and other components pretty much puts a lock on things. If Zach, enthusiasm for Arduino/Sanguino flags, however, plan on things changing rather quickly. It's happened before.

If, having read what I've just said here, you think that I am viscerally opposed to the Sanguino/Arduino development path you'd be seriously wrong. I approved of it initially because Arduino was a big, big improvement over the 16F628 system that we were using before. The compiler is solid and lots of people are using it, plus it's open source. That's all good.

OTOH, I thoroughly agree with Nop, who is also on the core team, that we really ought to design a controller harness from the ground up that uses really modern technology and to the Devil with the open source idea.

Zach is NOT a proper circuitry designer. Mind, he's very bright and has got VERY good at designing controller circuits in the few short years that he's been on the Reprap project. He's also got more energy than 4-5 ordinary people and is completely committed to advancing Reprap AS HE UNDERSTANDS IT. Therein lies the conundrum for folks like yourself and Nop.

Unless you can assemble a cadre to match his energy and commitment, your yearning that...

"I live in hope that at some stage the work I am doing with the PIC chips will be at least partially adopted by the core team as a viable alternative to the Atmel solution."

...ain't gonna happen.
Of course, the one real competitor for RRRF electronics & parts for RepRap is BitsFromBytes, so Ian's version could still become pretty popular.
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]