On Apr 17, 2012, at 10:28 PM, Jim Brain wrote:
Not trying to pick a fight, but I will respectfully
disagree. I suspect we all have been working on a job, needed a specific tool we did not
possess, and decided to repurpose another tool wholly inappropriate for the task to
accomplish the goal. Why? Because the job needed done and we decided that the goal was
the job, not the perfect use of a tool. Sure, we could go buy the right tool, but we
didn't.
Well, yes. When all you've got is a hammer, you need to learn how
to make more things act like nails. I suppose I wasn't considering
situations where you're constrained by availability; I'm more
concerned by people who don't even think about what they're putting
down because that's "too much work".
Mind you, I cringe a bit when I see someone using a
MEGA32 instead of a 555 or a set of logic gates, but then I remember that the IC is not
their goal, the output or the thing being cycled/timed/on shotted, etc. is the goal.
Kudos to them for finding a way to get to the goal as quickly as possible. While I whine
about misuse of tooling, they are creating/innovation/learning.
True. All the clever 555 hacks in the world don't matter if your
product doesn't ship on time.
Usually, anyway.
I'll also admit the arduino bothered me, someone
who built their own parallel port AVR programmer, created projects from scratch with the
avr-gcc toolchain, installed and configured avrdude to do the programming, and wired up my
own AVR on perfboard. However, at some point, I started to smile that arduino had created
a huge market for AVR-compatible items, and it had raised the visibility of the AVR. I
was glad, because for the longest time, PIC sat on top of the hobby community, and
Parallax's BASIC Stamp and stuff like that reigned. As someone who compared the PIC
to the AVR 8 bit line and found the PIC lagging significantly in many areas except part
options and price, I was glad the better architecture found a chance to shine.
Absolutely agreed. The PIC can rot in hell (maybe that's an
overreaction, but I've been forced to use it by clients who were
"uncomfortable" because they didn't know about anything else).
I like the AVR for a lot of things, and I'm glad it's getting its
day; I'm also glad it's getting an overhaul with the XMEGA series,
though I wish the debug tools were more stable on OSX.
Curiously, it's terrible for writing a Forth interpreter (as I
suspect many Harvard architecture machines are), but I'm quite
sure the PIC would be a lot worse.
On 4/17/2012 7:42 PM, Toby Thain wrote:
I have a little Duemilanove here. I'm used to 'bare metal' PIC18 coding.
Since you probably know: what's the quickest route to that on the Arduino, given that
my host is OS X/PPC... I was a little disturbed by the "just press play" IDE.
Get an AVR programmer (AVR ISP Mk II is a good choice, lots of cheap clones if you're
not Win7 64 bit. Don't try a clone on Win7 64 bit, trust me, lots of pain and
frustration)
Grab a copy of WinAVR off the net.
get avrdude running and attach a programming port to the Arduino clone (pins are
described in the datasheet for the AVR on the board)
Feel free to ask folks like myself for help.
Well, he's using a Mac, so WinAVR isn't that helpful. I've
gotten the patched GCC toolchain up and running well enough to
program my XMEGA-based wireless sensor nodes, but I'm not so
thrilled with how well it works. It's probably better on non-
XMEGAs, but I'm not working with any of them right now.
Toby: the AVR Dragon is a nice $50 programmer from Atmel which
does the job admirably on most AVRs (especially now that they've
lifted the 32K limit for debugging). You'll need a Windows
machine to run their software to update its firmware to get the
latest fixes (like lifting that 32K limit), though. I'll be
glad to help if you need to get the toolchain running on OSX.
- Dave