Show Posts
Pages: [1] 2 3 ... 7
1  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Spammers on: April 22, 2008, 07:26:11 am
I despise captchas, but that may be a necessary evil at this point.  It appears that a valid email address is required, so I guess that's a step in the right direction, but if the whole registration-confirmation-posting process can be easily automated, then I think you're going to have that problem.  A captcha would be a good stop-gap.  That or add a dynamically-generated challenge/answer ("what color is blue", "what is the sum of two plus three") that requires some human interaction.

How about integrating Akismet?  It's not just for wordpress.  If the user has less than 5 posts, run the posts through Akismet and moderate them if they smell funny.
2  Forum 2005-2010 (read only) / Bugs & Suggestions / Spammers on: April 22, 2008, 05:13:36 am
What is going on with the forums?  I woke up this morning to 15 "new thread" emails, 10 of which are obviously spam.  There doesn't appear to be a way to report a post or thread to an administrator.  Is someone aware of the problem?  I think this forum's on the verge of getting completely overrun with spammers.
3  Forum 2005-2010 (read only) / Syntax & Programs / Re: 8-bit LCD-library has became obsolete? on: February 20, 2008, 06:41:03 am
Good to hear you got it going. And it would be a help to others if you could update that code. Try sending an email saying what you want to do to:
Email sent!

Tom, you make a good point on the LCD controller.  It looks like a very handy little thing to have, and I may still end up going down that road (I'm not sure my current project is going to have enough pins to do what I need), but I'm trying to develop it with an eye towards cost (which is really freakin' hilarious if you know me!).  ;D
4  Forum 2005-2010 (read only) / Syntax & Programs / Re: 8-bit LCD-library has became obsolete? on: February 19, 2008, 08:05:51 pm
For the minimal ($8 + cost of LCD of your choice) cost, and the benefits... see below... I wonder why anyone would drive an LCD directly, instead of using the little LCD controller from, based on Peter Anderson's PIC.
The $9 (it went up?) is 180% of the cost of the LCD alone.  I picked up a couple off eBay for $5 each plus shipping ($14 total for two).  It seems excessive.  Handy, yes, but expensive.  I'm going to see what I can accomplish in 4-bit mode before jumping on that bandwagon.  I appreciate the link and recommendation, however! smiley
5  Forum 2005-2010 (read only) / Syntax & Programs / Re: 8-bit LCD-library has became obsolete? on: February 19, 2008, 08:02:30 pm
searching on LiquidCrystal.cpp:8: error: brings up this thread that covers a few ways to get this to compile

That did it.  Who do you have to talk to to get permission to edit that LCDLibrary page?  I could at least update the attached library and the documentation. smiley
6  Forum 2005-2010 (read only) / Interfacing / Re: LCD4Bit lib on: April 14, 2008, 05:54:11 am
I found a more configurable LCD library a little while ago.  Main page is here:

The pins are configurable via software, and it uses the R/S (or is it RW?) line instead of hard-coded delays, so it should be more efficient and faster.  I've only just started playing with it and I think I've got some wiring issues at the moment, but it's got promise.  
7  Forum 2005-2010 (read only) / Development / Re: #include paths for libraries on: October 01, 2010, 04:53:52 am
True, but complexity can be managed. smiley

Regardless of where the libraries are, the IDE knows about them. Regardless of how many search paths there are, they can always be specified with -I or -iquote and done once, versus having to add -I for every library included in the project.
8  Forum 2005-2010 (read only) / Development / #include paths for libraries on: September 30, 2010, 08:41:13 am
Sorry if this has already been answered elsewhere; I searched and Google'd without success.

The pattern for including a library's header file is
#include <LibraryName.h>
The Arduino IDE is smart enough to append
to the GCC command for every library included.  This works, but doesn't feel natural, and requires doing some fancier footwork when you want to build an Arduino sketch via a Makefile.

Instead, wouldn't it be better to pass
-iquote/path/to/user/libs -I/path/to/arduino/libs
and then include a library's header file like this?
#include "LibraryName/LibraryName.h"

It should still be very simple for newbies to grok, but would make the transition to a Makefile simpler.
9  Forum 2005-2010 (read only) / Development / Re: Compiling an SD/MMC and fat16 library on: November 04, 2009, 05:25:45 pm!%22&ie=UTF-8&oe=UTF-8

First hit. smiley
10  Forum 2005-2010 (read only) / Development / Re: Compiling an SD/MMC and fat16 library on: February 19, 2008, 09:11:07 am
Good stuff, strohhalm.   smiley  I'm hoping to implement a similar datalogger solution for a GPS and OBD2 (in-car diagnostics and stats).  It'll be a while before I can get my head around what you've done, but this looks like a great start.  
11  Forum 2005-2010 (read only) / Development / Re: Automobile Cruise Control Project on: February 01, 2008, 07:31:23 am
3 figure out the interface required to interface with my tachometer signal or a single spark plug impulse (manual transmission, so I definitely don't want a speedometer connection!)
4 write or obtain arduino software to recognize current frequency of tachometer impulses.
Bob, in the last couple of days I've been thinking about how to put together a robust datalogger for my car, capturing several engine parameters and interfacing with a GPS for position.  Applications include (aside from generally geeking out) post track-day performance analysis, possibly lap timing (depending on the resolution of the GPS) and general position logging so I can go back and find those roads I loved on my last random drive through the countryside.  Yesterday, I discovered the ELM323 OBD (ISO) to RS232 Interpreter.  If your car was built after 1996 (I think), it's got a standardized on-board diagnostics interface which will tell you things such as throttle position, engine speed, and vehicle speed.  It might save you some unnecessary hacking to pull back that data.  I've bookmarked some OBD2 links on

Good luck!
12  Forum 2005-2010 (read only) / Development / Re: Helping the Arduino build environment grow up on: February 26, 2008, 06:04:27 am
(I wonder what it sounds like when talking to a guy who speaks in parenthesis?)  ;D

You're absolutely right on the hardware issue.  I haven't examined that in detail, yet, but I think there are only two Makefile macros that would affect that: the target chip type, and the processor speed.  The Arduino IDE manages that with a single drop-down menu with a fairly small set of targets.  I figured I would just either have a recursive Makefile or a set of invocations of make that would generate a libarduino_$(TARGET).a file.  You'd still need to have a per-sketch Makefile, and it would be up to the individual developer to set their target architecture, but if Arduino shipped with the required libraries, it would make their lives a little easier.
13  Forum 2005-2010 (read only) / Development / Helping the Arduino build environment grow up on: February 25, 2008, 10:29:04 pm
Let me start this off by saying that I think the Arduino team has done a wonderful job lowering the bar to entry to microcontroller development for people with little to no software development experience.  The IDE is impressively simple, streamlined, and user friendly and is a great way to get your foot in the door.  As someone who's been doing software development for at least 10 years, now, however, I quickly became frustrated with my persistent muscle memory when editing text in the IDE and found myself longing for my beloved TextMate editor.  Within a day of receiving my Arduino board, I started trying to figure out how to use the Makefiles (a skill that I haven't used since '97 or so) and break up the rust on the parts of my brain that used to know how to program in C.  I started to dissect the Makefile today and realized that there's a ton of reuse that can be achieved by making the build environment a little more (de-facto) standards-oriented.  

To start with, I think that everything in hardware/cores/arduino could be packaged up into a single "libarduino.a" archive.  By doing that, the entire Arduino core can be linked in to each sketch without having to recompile HardwareSerial.cpp, pins_arduino.c, etc.  It would make the per-sketch build process simpler and faster, with fewer dependencies that probably won't change at all for most people.

Similarly, I think each of the libraries in hardware/libraries could benefit from having their own Makefile that generates their own libWhatever.a archive.  With a slight rejiggering of the Arduino conventions, we could either import libraries into a sketch by including, for example, "<EEPROM/EEPROM.h>", thus minimizing the pre-compilation processing that has to be done to the .pde files.

With these two small(ish) changes, I think it'd be possible to move between the Arduino IDE and command-line Makefiles without having to modify the sketch code as is necessary today.  It should be possible to link in the arduino core and EEPROM library with an appropriate -L flag and -larduino and -leeprom in the CFLAGS macro in the sketch's Makefile.  The way it stands today, it seems that you're either using the IDE or you're using Makefiles, but not both, since the .pde files need pre-compilation processing that exists only in the Java code.  Furthermore, as mentioned in one of the tutorials, it seems that there's a bug in the Arduino IDE code that prevents you from writing functions that take or return typdef'd types defined in a header file, since the function prototypes end up coming before the #include directive.

Is there sufficient interest to continue to pursue this publicly, or should I just keep tinkering with these for my own edification?  I think I'm going to have some code that others will have interest in, but I dread having to maintain a version for myself alongside a version for the IDE.

14  Forum 2005-2010 (read only) / Development / Re: LCD shield and/or LCD serial backpack on: February 22, 2008, 06:40:58 am
Update: The PCBs are on their way and will arrive on Monday.
Now to chase up the components.....
Sweet!  The more I build up my current project (an intervalometer for my camera), the more I realize I need some way to offload the LCD connections somewhere else.  I'm using every single pin and I still want to do things like toggle the backlight and add another button or two.  Ugh.  And I'm already using 4 bit mode, which is noticeably slower than 8 bit!
15  Forum 2005-2010 (read only) / Development / Re: LCD shield and/or LCD serial backpack on: February 20, 2008, 03:34:30 pm
Ok, so now that I'm thinking about it, is the ATmega168 going to be running the Arduino bootloader (and thus be reprogrammable by other Arduino users) or will it have its own "OS"?
Pages: [1] 2 3 ... 7