Uploading firmware without Arduino

Posted on by
1

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:

  1. The hex file is here.
  2. 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 by
11

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.

Fistful of polargraphs

Posted on by
2

The Polargraph factory (my living room) is in full swing today.  I had a bit of downtime when my 3d printer decided to start acting the goat, but I stripped down the heated print bed and rebuilt it, and it’s going gangbusters again.  I’m printing in ABS.  It doesn’t look that nice, but it’ll be better at taking the heat that these more powerful stepper drivers can pump into the motors.

I’m hoping to have this first handful of PolargraphSD kits on their way to their owners during next week, and at that point I’ll take a little stock to figure out how much they really cost all-in.  The boards themselves are really cheap, but they use all SMT (surface mount) components and I know a lot of folk are wary of that – so will probably offer an assembled shield as part of an upgraded vitamins kit.  I’m getting the hang of it.  Don’t know what all the fuss was about!

Also, doing lots of drawings.  These micro-stepping step-stick drivers are wonderfully civilised, so quiet and gentle.  I miss the L293D’s singing a little though.

Polarshield testing

Posted on by
Reply

A few things came out of my initial tests:

1.  The board, fully populated, is prone to resetting while handling with fingers.  Now this, obviously is pretty disasterous and indicates something operating very close to its reset threshold.  I’m using a transistor in the XBee circuit so that the board can be reset by the XBee – this should allow remote programming / firmware upload, and I _would_ like to have it.  When I take this transistor out, then the board is robust, and doesn’t reset itself.  I will have a closer look at this and hope it is a matter of tweaking component values either side of the transistor.  If not, then I am going to dispense with the transistor entirely.  It has dual footprints, so either a SMT or through-hole part can be mounted, and if you’re happy with the risk, you can solder them in yourself. If it isn’t there, then everything will still work ok, but you’ll need to plug in with a wire to do upload firmware.

2) The voltage divider that handles the SPI interface to the SD card didn’t work.  Seriously.  I can see now that it’s obvious that it won’t work (5v input, 10K resistor between output, and 10K resistor to ground.  I guess the circuit was shooting for 3.3v output?).  I went back to check the source of the circuit to see what was different about that … turns out that doesn’t work either, and never has. Fixed by adding links instead of resistors in half of the divider.

3) Orientation.  The screen mounts onto the top of the board, and orientates the board so that all the cables come out the bottom.  While this looks very neat in a sketchbook, or when hanging up, it is a pain to work with loose .. because there’s no bottom-edge to put it down on.

4) Screen orientation.  The screen can mount directly to the board if the board has female headers attached.  This makes it really neat and handlable but perversely makes the problem above (wires coming out the bottom – oof) more of a stinker.  A solution is to put male pin headers on the board, and have the screen mounted on a short piece of ribbon cable so it can be orientated separately.  Thoughts about this are very welcome as the board can’t easily have both male and female headers, and there’s no going back once they’re soldered.

Currently looking at shipping these initial kits first thing next week.  Four days late, tsk, sorry about that everyone.

PolargraphSD progress

Posted on by
Reply

Progress is good!  Four or five days behind where I was hoping to be, but on balance, good.

Got my polarshield circuit boards through at the end of last week, and extremely relieved (and frankly shocked) that there are no horrible errors on it.  I did forget to order some parts that I need to test the XBee side of things, but those’ll come shortly.

Soldered up the first one without any problems – first time I’ve done anything significant with surface mount stuff.  Slow, but not the big challenge I feared it might be.  A few things that I’d do differently next time round came up but I’ll do a proper hardware review another day.

The real message is: It works!

Now, lets get this software into shape…

 

Spectrum Arts

Posted on by
2

There’s a graffiti supplies shop in town, Spectrum Arts, run by this dude called Mark.  I approached him about putting a machine in his window – he’s got some covetable glass, and is a nice guy.

It’s been there for a while, but I’ve just got the kit to fit a big fat chalk pen in it.  I used this gondola that Stuart Childs designed which did the trick nicely.  Thanks to Stuart for this – very timely, and I think I got some great first results out of it too.  The slow speed of the vector drawing means that gravity can keep the tip supplied with ink.

Am hoping to formulate a sequence of drawings to go in the window, but would love to see something graffiti based, am thinking of a GML-aware system that can accept tags from all over the internet and mark them out on the glass.  For now, it’s just manually controlled, but it communicates using an XBee and has an SD card too, so that’s nice.

 

Eclipse, Arduino 2560 and AVRDude – timeout

Posted on by
4

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 by
3

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.

Polargraphs in the gallery

Posted on by
Reply

I got wind of this set of polargraph drawings in a recent show in Belfast.  Richard Forrest is the fellow behind them.

 

I like this exploration of the intrinsic nature of the digital, or quantised, sampled or rasterised forms – the pixelation is a big part of my own work, and I see it here too.  Richard revels a little more in the flaws of the machine, with some great effects, the distorted face is ace, but I like the abstract portraits the best.

I’m not clear if this last show is still on, but Richard tells me he has an upcoming show in Cork next month that will hopefully be featuring a live machine in situ.  I love to see a live machine.

 

PCBs ahead full steam

Posted on by
7

I’m getting the hang of Eagle, and the design for the first Polarshield is close to being complete.  Matt Venn is charitably helping me by gently pointing out the stupid stuff I’m doing.  Luckily for me, the board is electrically very simple, being an aggregation of other designs rather than something truly original.

The polarshield is be the key piece of the PolargraphSD machine.  It’s a shield with:

  • 2x Stepstick / Pololu A4988 sockets.
  • ITDB02 2×20 pin LCD touchscreen header w/ SD slot.
  • XBee socket.
  • 2x Servo motor connections
  • 4x Endstop connections

Connected to a MEGA, then you can use everything all at once, on-board.  If you don’t have stepsticks yet, then you can stack your existing Adafruit motorshield on the top, and it’ll work.  This includes the touch-screen that will allow fully untethered drawing, and potentially some really nice things eventually.

Connected to an UNO, you can use your old Adafruit shield, or upgrade to use stepsticks.  Using stepsticks frees up the SPI pins on your UNO, so it could, in theory, read an SD card too.  (SD reading isn’t likely to become part of the UNO build for the foreseeable future, but it could be hacked to do it for someone who is determined.)  You definitely can’t use the LCD screen though with the UNO.

The XBee port is accessible to both UNO and MEGA, so if nothing else, this can be used as an XBee breakout that will cooperate with a motorshield.

There are connectors for endstop sensors that will eventually provide for automatic calibration, but there’s no hardware to go with that quite yet.  I’m currently thinking of little magnets attached to the cords and some reed switches or hall effect sensors positioned just above the sprockets.  This needs to be built and thoroughly tested, but I don’t actually think there’s much to it.  It was never planned to be part of the PolargraphSD design, so I’m not rushing into it with only a couple of weeks to go.

The board is largely based on the RAMPS board that folk use in their Repraps, so there’s a handful of other pins broken out by default.  I have tried to be good and group pins together, and the board does have a slight general purpose quality to it for that reason.  Hopefully it should be open to extension without too much hacking.  Pics and plans soon.