Uploading firmware without Arduino

Posted on June 18, 2012 by sandy

EDIT! – Use XLoader instead of this – it’s just as good and works on more boards.

Hello, a few people have had problems getting their programs uploaded to their arduinos. ~~I haven’t. Not rubbing your faces in it, but if I can’t replicate it, I can’t fix it. I think it might be something to do with bootloaders, but who knows.~~

EDIT! Looks like it is to do with bootloaders – Matt’s adventures confirm that. I think it’s restricted to UNOs of a certain age. The only UNO I ever owned I blew up literally hours after getting it, so can’t test. And I don’t think this way of uploading will get around the issue – you might just have to reprogram your bootloader.

A second problem is that you need a couple of libraries installed, and not everybody want’s to harass themselves with that. So I’ve made a precompiled hex file that you can load onto your arduino to save you that hassle. You don’t even need to have arduino installed anymore.

What you need:

The hex file is here.
ARP-Uploader. This is the thing that uploads the hex. Get it from here.

And that’s it. Unzip and startup ARP-Uploader, load up your hex file that you downloaded.

Choose the COM port that your arduino is on, and m328p as the microcontroller.

Change the baud rate from 19200 to 57600 where I’ve highlighted in the pic.

Press upload!

I’d be interested in knowing if this helps anybody who is having sketch size issues too.

OK, this hex file is good for Arduino UNO, Duemilanove, or any ATMEGA328-based arduinos.

Polargraph Controller v1.1.7

Posted on June 10, 2012 by sandy

Hello everyone, an update this way comes!

Version 1.1.7 of the Polargraph Controller brings some significant fixes AND a couple of new features.

Density Preview Styles. This is a naive attempt to make the density preview look a bit like the square wave pixel drawing style. It uses diamond-shaped squares instead of round spots.

It also uses transparency to give a kind of preview of what happens when they overlap (more on overlapping next). I was a bit reluctant to add this mode, because it implies that the controller is able to give a preview of what the rendered drawing will look like, rather than simply giving a view of what detail has been captured. But even though it isn’t perfect, it might be useful. It is the new default, but adding controller.density.preview.style=0 to the config file will make it use circles instead.

Pixel scaling. A customer asked about this image that appears to use a pixel that is scaled AND has variable frequency. I said of course, there are no secrets in this project, anything I can do you can do. But then remembered that that drawing was the result of Tinkering, long ago, and there was no way to do this without more Tinkering though it is a good effect. It was essentially a way to get detail in without obliterating everything else on the page. Kind of worked.

So I’ve added a Scale Pixel function that will allow you to multiply the size of pixel that get’s drawn. A value of 1.0 means the pixel is the same size as the grid – just as it always has been.

A value less than 1.0 makes them smaller than the grid, values larger than 1.0 makes them larger than the grid. This was designed to be used with variable freq square wave, so your mileage may vary when using it with scaled pixels.

Crash Fixes! This is quite a good one, and worth having if you are working with big queues. This fixes the crash that often occurs when adding large numbers of pixels to an existing queue. The issue was a ConcurrentModificationException when attempting to read from the command queue to draw it on the screen and adding to the command queue at the same time. Not allowed to do that. There are thread-safe versions of the List I use, but they are slow in themselves, so all I did is catch the exception and ignore it and continue on. The issue is entirely limited to how accurate the command queue will look, on-screen, for a couple of milliseconds, so I am happy to behave badly with that one. HOWEVER, it is unlikely to come up again anyway, because…
Performance is improved with long queues. Previously it would write out all the entries in the queue, even if they weren’t on the page. Now, writing anything to the screen is pretty slow, so this has been made 500 times faster (literally) by not doing that unless there’s something to show. It was pretty lazy coding anyway.

Ok, that’s all folks, as usual, this code is available in the repository or in a couple of downloads.

If there’s any issues, please let me know.

Eclipse, Arduino 2560 and AVRDude – timeout

Posted on May 13, 2012 by sandy

I’m in the process of restructuring the polargraph firmware, and the first thing I’m doing is moving most of the functions out to a library that can be used by all polargraph firmwares (uno, mega etc). So that’s easy, you’d think. I’m a fairly naive c++ programmer so don’t be surprised that I’m trying to get it working in eclipse so as to have a decent overview of things, function names and whathaveyou. I find it useful when making cross-cutting changes.

So I came across Eclipse/Arduino tutorial page, which is really good, and got it working on a Duemilanove I have – beautiful! That said, I can quite see why the Arduino IDE is popular even though it lacks functions. Eclipse is the archetypal jack of all trades and master of none, and requires a load of configuration to even get started on things.

But the MEGA? Not so much. I got stuck so went to see how the Arduino IDE does it, and pulled out the AVRDude command it was using (turn verbose output on for the uploading in preferences):

c:\Dev\arduino-1.0\hardware\tools\avr\bin>avrdude -CC:\Dev\arduino-1.0\hardware/
tools/avr/etc/avrdude.conf -v -v -v -v -patmega2560 -cstk500v2 -P\\.\COM55 -b115
200 -D -Uflash:w:C:\Users\sandy\AppData\Local\Temp\build4894098567197191708.tmp\
Blink.cpp.hex:i

That’s what it emits, but when I put that same text in at the command line, I am faced with

avrdude: stk500v2_ReceiveMessage(): timeout

Which is the same problem I was bumping into in Eclipse. Well.

The fix

Turns out using the arduino or stk500v2 programmer, the board doesn’t get reset before programming. I could get around this just by pressing the reset button and then uploading that same instant, mostly, but it’s not very clever. Then I came across a better solution at this page discussing the error in avrdude 5.10 (I’m using 5.11 that comes with the Arduino IDE so I guess it’s still an issue), and that solution is just to use the Wiring programmer instead of the Arduino programmer that works fine on the Duemilanove, or the stk500v2 programmer that the Arduino IDE uses.

That worked fine.

Homing

Posted on May 12, 2012 by sandy

Came across this brilliantly pragmatic solution to the homing problem.

And his site, and a useful forum post.

This comes as a lesson to me in the value of just getting it done vs trying to engineer the “best” way forward. I’ve worried and sketched and wondered about the best way to do automatic homing/calibration for ages, since this project started in fact. Never got around to doing it though, and it’s something that would take half an hour to test.

This is the opposite problem that manifested at the beginning of the project, and that problem was that I rushed in and just got stuff working without much thought to maintainability. Which did the job, but left the code in a pretty desperate state, from which it is yet to fully recover.

There must be a middle ground.

Software update: Skipping blank pixels, and faster comms

Posted on April 9, 2012 by sandy

In response to Kongorilla’s request for cleverer pixel skipping routines, I’ve just uploaded some new code.

Note, if you’re going to use the controller, you also need to update the firmware too.

v1.1.6 Controller binaries / Controller source code

Firmware source code for arduino with adafruit motorshield / for arduino with serial ITead motorshield / for arduino mega

1. Pixel skipping.

Skipped pixels are ones that are masked, or that are outside of the brightest/darkest thresholds. Normally skipped pixels are simply omitted from the command queue – they just aren’t transmitted, and this is fine for ones around the outside of an image. It does mean though, that skipped pixels that are in the centre of an image get drawn as blanks – a line through them as the pen trundles towards the next drawable pixel.

So this is changed now: The default behaviour is now to lift the pen while moving over skipped pixels. For one reason or another, it does mean that even skipped pixels get transmitted so it might take longer, but the pen will be up during that time. You can still go back to the old continuous-line way by choosing the other option in the dialog. I believe this still works as before.
This works best if you use it in conjunction with masking and reducing the brightest pixel threshold a bit to weed out the false positives that are not completely blank, but are nevertheless too bright to be expressed by the machine as anything other than a straight line.

2. Faster communication

With this release (v1.1.6) I have switched over to using a CRC-based system to verify the integrity of the command. Each command has a checksum appended to it when it’s transmitted, and when the machine receives it it recalculates the sum and if it matches what’s on the end then hurray, the command was not corrupted. If it doesn’t match, then it will signal to the controller to resend the last command. This is twice as fast as before, so that’s good. But it’s not compatible with the old way of doing it. Well, it might work, but it probably won’t.

How it used to work: Basically the controller used to send a command, then the machine would acknowledge it by sending it back, and the controller would check to see if it came back unchanged, and if it did then it’d conclude the message was properly transmitted and send a final execute command. It was fairly safe, but it was slow because there are three messages exchanged for every command.

I put it in as a response to some dropped pixels I was having back in the day, where every couple of hundred commands, one would get truncated or mangled for some reason.

I’m off on holiday for a few days from tomorrow, so if it all goes wrong, goes on fire or destroys your drawings, please wait until next weekend to be cross with me.

ITead motorshield in the wild

Posted on March 17, 2012 by sandy

Active forum member Woodpecker went looking for alternatives to the Adafruit motorshield, and came across this dual-stepper shield made by ITead Studios, and sold by Komputer.de in Germany. I got a couple, and they are very reasonably priced. These are pre-assembled, based on the A3967 driver chip – the same ones that Brian Schmalz uses in the EasyDriver boards. They can drive upto 750mA per motor, which is a bit more than the L293Ds in the Adafruit design (though that can be upgraded with SN754410 drivers for those that are as infatuated with adafruit as I am).

Datasheet

Schematic

The main feature of this shield is that the A3967s are serial steppers, which means they use fewer pins, and the shield happens to use pins 2 through 9 on the arduino. Which means that the magic pins 10, 11, 12 and 13 are free – and these are the pins that the SPI interface appears on in the Uno-sized boards. That opens up the possibilities of using a pre-assembled SD card reader with the Uno, which is interesting. Now I’d more-or-less given up on running an SD card with an Uno, because of the double-whammy of needing to rewire and because of the memory limitations.

HOWEVER, if this board removes one of those impediments, then the game is perhaps afoot again. I can conceive of a firmware that is very minimal – just responds to vector graphic commands only, and is optimised for standalone drawing. Is this worth having? I suppose I can’t know until I try it eh.

The other feature of the shield, is that all the spare analog pins are broken out to three-pin headers, and the motor connections themselves are exposed as four-pin headers AND screw terminals. So this could be used without the faintly comical terminal adapters that I’ve been making up so far.

The downside: There doesn’t seem to be a way to turn these off. The EasyDriver breaks all pins out so motors can be enabled / sleeped, but this shield appears not to. This is a bit of a blow, because it means the drivers and motors are energised as soon as the board has power applied, and it can’t be turned off programmatically.

The A3967 chip is also less tolerant of bad behaviour like unplugging the motors while it’s on – this is much more likely to damage the ICs than with the L293Ds, so be careful.

Oh and one other thing – these are HOT! Makes the whole arduino hot. I believe the IC will always be hot, and probably well within threshold, but I think heatsinks will be the order of the day again.

Anyway, I have released a new firmware that is built for the ITead shield. It is otherwise identical to the regular firmware, but dispenses with the AFMotor library. The servo pen lift is now also controlled from pin A0 (aka d14), which is the first three-pin header in the block on the motorshield. You can see that on the picture.

Chroma keying is back

Posted on February 25, 2012 by sandy

And you didn’t even notice it was gone. Tsk. I didn’t either.

So anyway, you can now choose a colour from the image (click choose mask colour and then click on the image) and any samples that have that exact same colour will be studiously ignored.

I first put this is for making duotone type effects in conjunction with the shade solid pixel type and a few different colours of pens.

Use PNGs instead of jpegs, because jpegs often have lots of artefacts in them that are not the exact colour you want. Also bear in mind that it is the underlying colour that is checked for a match with the mask colour, not the averaged out brightness that appears in the density preview. Oh, and the mask colour is saved to the properties file too, and can be checked by looking at the info screen (press i).

1.1.4 from the downloads section or the code repository.

Have a nice weekend!

State of the art tangle

Posted on February 17, 2012 by sandy

In case anyone’s interested, here’s my current brain.

It’s a DFRduino Mega (1280) (ebay) with an adafruit motorshield (oomlout) on top, and an adafruit micro sd breakout (also oomlout) on the side.

This is the jalopy currently running my standalone drawings. The circuit is shown a little better here:

Running commands off the SD card eliminates the pause in between commands completely, it’s brilliant. Currently no way to interrupt it once it’s started, but I plan to add a rudimentary physical interface, a pause/run button at least. Will will be testing various endstop / limit detectors at some point.

I also have a sanguino and a couple of stepstick drivers to test out this weekend. I think that hardware combo is likely to be the basis of future polargraph machines – the chip in the mega is awful expensive.

-EDIT – Firmware
I realised I didn’t mention anything about the firmware I’m using in the MEGA. It’s available from this branch of the repository. It broadcasts its version in it’s READY statement, saying READY_100 instead, and the controller will spot that and the new buttons will appear:

Signal store… This pops up a window that lets you input a filename that any new commands issued will go into instead of being executed. This will create a file on the sd card on the machine, and fill it command-by-command. This is still pretty slow. It puts the machine into store mode.
Signal play This signals the machine that it should go back into play mode, and start executing commands again, instead of storing them.
Exec from store… This pops up a window to input the name of a file that contains your commands and when you hit submit it starts executing all the commands from that file.

A better way to do it is to hit export queue and save your queue to the card directly using a usb card reader – same result, and much faster, then swap the card back into the machine once you’re done.

So I still need to use the controller.

I layout my artwork, then make sure I have an empty, paused queue before generating all my drawing commands.
Then plug my sd card into the pc so it appears as a drive. Now export queue to a text file on the sd card.
Take the card out and put it into the polargraph machine and reset it. It needs to be reset to initialise the card.
Connect the controller and start the queue.
Set home and move the gondola to the home point.
Queue->Exec from store and enter the name of the file I just saved onto the sd card.
The machine gets that message and starts drawing. Now I can just close the controller and turn the computer off if I want to.

Remember that the machine still needs power, and depending on how you have your machine set up, part of it might be being powered by USB. So if you turn the pc off, it might lose that power. It might not! Because you might have a powered hub or something. But If you have a power supply that plugs into your arduino board rather than your motorshield you will be ok to remove the usb entirely.

This works great for vector graphics where there’s thousands of little lines. Not such an issue for bitmap stuff, but still might be useful for bigger things.

Resizing vectors, saving config.

Posted on February 15, 2012 by sandy

It’s like that film, with those flying dudes.

Ok, two exciting new functions in the latest controller release (v1.1.3).

Vector scaling and moving. Loaded SVGs can now be moved and resized using the same kind of controls as bitmaps, one to move, one to resize, so that’s nice and easy. Still no way to “select” a particular area beyond changing the page size, and that’s not really what page size is for, so I need to do something about that.
There is a slightly related issue about what happens to the lines that go off the edge of the page. At the moment, if a path goes off the edge of the page and then comes back onto it then there’s a slightly unpredictable line between the exit and the reentry point. That’s marked for fixing.
Another slightly related issue is that the machine will only draw a line segment if both ends are on the page. This is ok for drawings that have lots of little lines, but if there is a long line that only a tiny bit hangs off the page, then the whole line will be missing. Fixing that kind of issue is a little more than I was hoping to get into, but it’s a bit of a stinker so I probably will.
Multiple config files. The main config file is now called default.properties.txt. This is intended to be used as an empty “untitled” document that will always be automatically loaded when the controller starts. But when you start laying out your images and making modifications, you can now “save as” a new config file, that can be worked with from that point, and be reloaded at a later date.
I haven’t had a very thorough test of this stuff, and I know that something a little odd happens when you change mmPerRev or stepsPerRev. I still think it’s easiest to modify those settings by changing them directly in the txt file.

A word about testing and releasing.

When I’m putting in new features, or fixing issues, I do try to do some testing, but it’s often fairly rudimentary. For issues like the multiple config files (above), while I know there are some things in it that don’t quite work, I’m still releasing that, because it doesn’t change the old behaviour. You can still use the app like you always could. If it required you to change lots of things, then I’d be a bit circumspect about letting it out.

For something like moving and resizing vectors, this is such a useful thing that it’s better that it’s out there and not working properly than it’s not available at all, at least, that’s my reasoning. (And I think it is working properly, anyway!) It might not be very proper development practice, in fact I know it isn’t, but I think the elite band of folk who choose to use this software would prefer to have something you can muddle through with rather than something that’s absolutely perfect but can’t do anything. At least that’s what I’m looking for, ha!

As ever, new precompiled version available from the code downloads page and the source available from the head of the controller trunk.

Safer vectors

Posted on February 5, 2012 by sandy

Have just been working on making vector drawing a bit safer, thanks to prompting from Matt. Still no resize or zoom, but this drawing with 14,000 commands has just finished successfully.

This SVG was one that used to send the machine into a mad spinning fit, off searching for a coordinate it could never reach. Well, now the machine will only attempt to draw to points that it believes fall within its own machine space, and it superstitiously avoids any 0 coordinate. There are a couple of changes to the embedded (server, firmware, whatever you like to call it) software to support that, and there is a slightly new acceleration behaviour for C17 (draw straight line) commands. This essentially turns off acceleration for C17. Because the line is chopped into such small pieces with C17, it doesn’t work anyway, so doing without makes for a much faster line, at the expense of noise, maybe a bit of wobble. It’s a slightly harsher process.

Ok, so those are the updates to the machine code, not completely essential, but it can be found, as usual in the repository.

The controller has a couple of minor changes to support vector drawing, mainly that only vertices that fall on the page are sent to be drawn. I know it makes sense to have the select area tool able to select the lines to draw, but that’s all a bit tied up with bitmaps and regenerating the density maps to do that easily at the moment. In future though, definitely, along with svg resizing and moving.

The controller now has a separate window to select the pixel rendering options, and choose which corner you want the drawing to start from.

The other change in the controller is that it now supports the new Arduino MEGA firmware, and the few new features that are available in that (namely saving to / drawing from SD cards). It recognises what kind of board you have plugged in because the mega version broadcasts its nature in its READY shoutout. Shouldn’t make any difference to anyone because standard behaviour is the same. I’ve noticed an oddity with the way the control panel wraps when it detects the machine has changed to a different type, but nothing problematic.

Available from the repo, or the downloads section, v1.1.2.

Polargraph

drawing by robot

Category Archives: software