Show Posts
Pages: [1]
1  Development / Suggestions for the Arduino Project / Re: Mini-Shield form factor? on: September 06, 2012, 03:16:02 pm
Take a look at www.gravitech.us
They have a whole line of shields for Nano's.
Maybe adapt them to use with Promini?
Sweet - this is indeed what I was looking for.  Now I have to persuade 'em to make a CAN shield.

Quote
At the same time, a promini is not much more than a surface mount breakout board.
I'd just as soon put the chip on a custom board with other needed components, get a set of PCBs from iteadstudio (or whomever) for $10 and then not have to deal with all the headers & stuff.
Ahh yes, but you're a better man than me - I can't solder to save my life (and I've botched a number of expensive components trying  smiley-cry ).  I note that you've got 25 years experience in hardware - I have about the same in software.  My business partner tends to run screaming from the room if I pick up a soldering iron...

Plug and Play was made for folks like me - which is why the gravitech link is so good.  Thanks.

One day, I'll get someone to teach me how to solder properly - I definitely want to learn.  Just always running out of time...

Thanks again!
2  Development / Suggestions for the Arduino Project / Mini-Shield form factor? on: September 06, 2012, 11:23:34 am
Hi,

Perhaps the following suggestion already exists?

Would it be beneficial to come up with a "mini-shield" form factor?  I'm thinking of something that would piggyback on the pro-mini series(#0).  Quite often the real estate needed for the components for a shield don't take up much space and could "easily"(#1) fit in a much smaller footprint.  An adapter board could be made so that a mini-shield could be attached to a regular Arduino shield form factor.

I see a few possible benefits:
1) Small is beautiful - folks came up with Arduino Pro-Mini for a reason.  Same reasons apply for peripheral hardware as well
2) Make it standard and make it modular so as to encourage shield makers to adopt it.  Maybe any shield that can be made in that size would be the standard - and then using adapters for bigger boards.  Although, I'm sure that'll create an outcry in the event it makes new users buy an adapter board.  But maybe it would be a wash in the long run?  Smaller boards are (slightly) cheaper to produce.  You could have many "mini-shields" and only need one "mini-to-normal shield adapter".
3) It encourages cross-pollination(#2).  Some other hardware has adopted the shield pin out - that shows there's a desire to tap into the Arduino Shield market.  However, for some projects it appears overkill to have a (relatively) "honking big shield" when only a few components are needed.

Notes:
(#0) - I realize that this might require a compromise on some pins? (not sure entirely).  That's just my starting suggestion
(#1) - Easily is in quotes because I'm a software engineer and I just assume you hardware types can miniaturize anything! (That's a compliment!!!)
(#2) - Dear Arduino, Sorry and please don't feel bad, but I've started dating other hardware boards.  I still love you though!  Can we have an open relationship?

What do you think?

You say: A good idea? I reply: Cool, how do we get it done?
You say: A bad idea? I reply: OK, why?  What problems need to be addressed?
You say: Been done before and the implementation chosen rocks? I reply: Would you kindly point me to that implementation?  Thanks!
You say: Been done before but the implementation chosen sucks? I reply: OK, so why did it suck and can we learn lessons and do it mo' betterer this time?
3  Using Arduino / Programming Questions / Re: Arduino resets when "too many" stream operators (<<) are used inline on: September 25, 2011, 10:43:13 am
Thanks Rob.  Both for the advice and the best damn "geek quote" I've seen in a while (2B OR NOT 2B....)  I'm still laughing!
4  Using Arduino / Programming Questions / Re: Large switch statement gives: "relocation truncated to fit:" on: September 25, 2011, 10:39:44 am
Thanks!

Quote
Run into them the hard way!
Yup - that's what I'm doing now.  Not very efficient though.

Quote
Pay attention where it says "Binary Sketch Size"!
That just tells me how much Flash memory I've used, right?  Not really much help in this case.  Unless I'm missing something?  (BTW, I'm at 40K out of 128K).

Quote
Think "sizeof" for each and every global, static, string literal, and local variable you use!
But if I don't know my running limits that doesn't really help that much.  Unless I keep a running total in my head - but that's why I've got a compiler!

Quote
Never, ever, use heap-based allocation (new/delete/malloc/free). Pre-allocate everything you need as globals. Then you know it's there!
Ahh, good point.  This is one of those low-level vs. high-level type differences.  I've years of coding high-level where memory is bountiful and passing parameters is usually considered better form than globals.  I totally take your point though - globals are good!

(BTW, I don't have any heap allocation in this app - but I do in another one.  Time to go and eradicate that!)

Quote
Use objdump to examine the generated elf file (hold shift and press the play button to see where the environment puts your generated files).
Excellent - this is the sort of nugget I was looking for.

Quote
It is possible that you can turn your switch into a table of function pointers.
Another good point - you saved the best two for last ;-)
I've been meaning to tidy up that big ass switch statement anyway so making it table driven will make me do some good tidy up.

Quote
Really, when you have 2 kB of global data segment and stack space COMBINED, you just can't create enough globals that you can't find all references when you need them :-)
Right!  I must write out "Globals are Good" on the blackboard 100 times!  (Hey. maybe that could be a new one for the start of the Simpsons?)

Thanks again.
5  Using Arduino / Programming Questions / Re: Persistant Problem with Strings on: September 24, 2011, 06:34:41 pm
One thing you can do is to use the PROGMEM directives to store these tables of data:
Code:
// The tag database consists of two parts. The first part is an array of
// tag values with each tag taking up 5 bytes. The second is a list of
// names with one name for each tag (ie: group of 5 bytes).
char* allowedTags[] = {
  "1C00EFE643",         // Tag 1
  "04146E8BDD",         // Tag 2
  "0413BBBF23",         // Tag 3
   "1B001421DA",         // Tag 4
   "1B001461DA",         // Tag 5
   "1B001321DA",         // Tag 6
   "1B001221DA",         // Tag 7
   "1B002421Db",         // Tag 8
   "1B011421D1",         // Tag 9
   "1B101421D2",         // Tag 11
   "1B101421D2",         // Tag 12
   "1B101421D2",         // Tag 13
   "1B101421D2",         // Tag 14
};

// List of names to associate with the matching tag IDs
char* tagName[] = {
  "Jonathan Oxer",      // Tag 1
  "Hugh Blemings",      // Tag 2
  "Dexter D Dog",       // Tag 3
  "Set Paper Low",      // Tag 4
  "Jonathan Oxer",      // Tag 5
  "Hugh Blemings",      // Tag 6
  "Dexter D Dog",       // Tag 7
  "Paper Low8",          // Tag 8
  "Jonathan Oxer",      // Tag 9
  "Hugh Blemings",      // Tag 10
  "Dexter D Dog",       // Tag 11
  "Paper Low12",          // Tag 12
  "Paper Low13",          // Tag 13
  "Paper Low14",          // Tag 14
};

See: http://www.arduino.cc/en/Reference/PROGMEM for details
6  Using Arduino / Programming Questions / Large switch statement gives: "relocation truncated to fit:" on: September 24, 2011, 06:24:50 pm
I have code with a large switch statement.  All the code blocks are small but there are many of them:

Code:
switch(a) {
case 0: doSomething(); break;
case 1: doSomethingElse(); break;
...
case 20: doSomethingBetter(); break;
default: doSomethingUnknown();
}

When I added an extra case statement I got this compiler error:
relocation truncated to fit: R_AVR_7_PCREL against `no symbol'

Googling that it seems to do with the generated assembler not being able to create a jump statement.  At least this problem gets caught at compile time.  But it's starting to make me a little nervous - I come from a high level programming background (app development for Windows), and now this (along with another post about stack issues) is making me remember that I'm programming on a microcontroller.  But with a high level set of libraries and a "high level mindset".

Any words of wisdom as to how to find out more about these sorts of limits?  I want to keep using the Arduino libraries and I want to continue to write "high level" code (for all the usual productivity reasons).  If I knew more about the limits then I could (maybe!) design and code appropriately.

Any insight or advice greatly received!

Thanks.
7  Using Arduino / Programming Questions / Arduino resets when "too many" stream operators (<<) are used inline on: September 24, 2011, 06:16:47 pm
I'm using Streaming.h which adds the very handy << operator to the Serial class.

Code:
Serial << "foo" << _DEC(a) << "bar" << _FLOAT(b) << endl;
vs.
Code:
Serial.print("foo");
Serial.print(a, DEC);
Serial.print("bar");
Serial.print(b, FLOAT);
Serial.println();

Well I guess I got carried away.  If I used "too many" of the << chained together the code would compile but the Arduino would reset.  Simply splitting the long chain into two or more separate lines seems to solve the problem.

This might fail:
Code:
Serial << "a" << "b" ....... << "y" << "z";
whereas this might pass:
Code:
Serial << "a" << "b" ..... "m";
Serial << "n" .... << "y" << "z";

Sorry for the vagueness.  It seems to be dependent both on the size of the variables as well as the number of chained << operators.

Which begs the question - why is it failing?

Well, my guess is that the 'duino is running out of stack memory.

My question is what limits stack size and how does one know that limit and program defensively?

Or is this not a stack issue at all?

Any insight gratefully received!

Thanks.
8  Forum 2005-2010 (read only) / Development / Arduino Tool Chain with other ATMegas? on: October 24, 2009, 10:40:18 am
Hi,

We have built a hardware device that uses the ATMega1280 at it's core and I've been using the Arduino toolchain to work with it.  I love the simplicity and wide support of libraries - many thanks to all involved!  I'm a high level software engineer used to working with PCs and it's been great how quickly the Arduino lets me get into the world of micro-controllers.

On our produce we now want to use either an ATmega649 or ATmeag325 - kind of half way between the base Arduino and the Mega, right?  (I'm the software guy on the project - not the hardware guy).

My question is - how easy or hard is it to adapt the toolchain to one of the above two alternatives?

Is there a handy reference point for all the stuff that would need to be done?  I did a quick search and I can find things scattered around and about but I'm not sure there's kind of a high level checklist which I could use to determine how easy or difficult it would be...

Thanks in advance..
9  Forum 2005-2010 (read only) / Interfacing / Re: AVRUSB running on Arduino hardware with minishield on: November 23, 2008, 07:46:42 pm
Hi,

Many thanks for this library and the schematic.  I was able to go from a complete microprocessor noob to having the "hello world" USB demo working in a weekend (would have been less had I not had to make quite so many trips to Radio Shack!).

I have found one issue - and I don't know if it's my setup?  The USB device only seems to correctly connect through a hub - if I attach it directly to a USB port on the computer it fails.  However, if I attach a hub to that port and then attach my device to this hub it works.

My Arduino environment:
Arduino Nano, Arduino-012 IDE (*), ArduinoUSB_release_001 running UsbKeyboardDemo1

Host OSs tested include Linux (SuSE) and Windows XP.

(*) Note, I patched the code as per the patch file posted on this thread.  However, only the first part - the file did not seem to contain "// Control pull-up resistor".

Any help greatly appreciated.  

Although, I'm still enjoying pressing my button and seeing "hello world" magically appear!   ;D

hello world
hello world
hello world
(as "typed" by my Arduino Nano)

Many thanks!

Pages: [1]