Pages: 1 2 [3]   Go Down
Author Topic: Help Choosing Upgrade from ATMEGA328 on UNO for Production Version of PCB  (Read 3707 times)
0 Members and 1 Guest are viewing this topic.
Atlanta, USA
Offline Offline
Edison Member
*
Karma: 56
Posts: 1848
AKA: Ray Burne
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Unless they plan to add new features half-way through the production cycle<...>

In my opinion, sizing should have been taken into account for the entire production run at a max of 66% of all known requirements.  I'm glad I am retired because I have fired PMs for less.  Everyone must learn and there is no better teacher than the real-world experiences, but  not considering a fair amount of reserved flash space in the hardware selection is inexcusably naive.

@Doc
Quote
My comment about 644 was only half a joke..
Sorry there Doc, I just lost contact with reality and was focused only on the change!  It's kind of funny now... Kind of...

Ray
Logged

Offline Offline
Sr. Member
****
Karma: 11
Posts: 358
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Do you have some proof of that statement?

Some libraries (eg. digitalWrite) can do things  in a less efficient way than ones that know the pins at compile time. Sometimes there is a trade-off of ease of use vs space.

However I don't know that the Arduino libraries are, per se, egregiously slow and inefficient.

Please supply some proofs in the form of an Arduino library compared to some other library that is much faster and less bloated. One that achieves the same things.


Here you go
I ran this test on the arduino uno
Arduino:
Code:
void setup(void){
 Serial.begin(9600);
 Serial.println("Hello World");
}
void loop(void){}
Code:
Binary sketch size: 1,934 bytes (of a 32,256 byte maximum)
avr-gcc:
Code:
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <stdint.h>
inline void serialWrB(uint8_t dat){
UDR0=dat;
while ( !( UCSR0A & (1<<UDRE0)) ) {} //wait for byte to transmit
}
void StringPgmln(char * str){
do {
serialWrB(pgm_read_byte_near(str));
} while(pgm_read_byte_near(++str));
serialWrB('\n');
}
int main(void){
UBRR0H=0;
UBRR0L=207;//These values assume double speed is enabled (see below) and a 16mhz clock is used 3 = 0.5M 2M baud rate = 0 7 = 250k 16 = 115.2k 207 is 9600 baud rate
UCSR0A|=2;//double speed aysnc
UCSR0B = (1<<RXEN0)|(1<<TXEN0);//Enable receiver and transmitter
UCSR0C=6;//async 1 stop bit 8bit char no parity bits
StringPgmln(PSTR("Hello world"));
while(1){}
}
Code:
avrdude: 240 bytes of flash verified
I would like to point out that another advantage for the code compiled with avr-gcc vs the arduino Serial library is the string is stored in flash memory instead of ram.
« Last Edit: July 26, 2013, 08:53:00 pm by Mr_arduino » Logged

Global Moderator
Melbourne, Australia
Online Online
Brattain Member
*****
Karma: 511
Posts: 19331
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes, well you can do a similar thing in the IDE:

Code:
inline void serialWrB(uint8_t dat)
  {
  UDR0=dat;
  while ( !( UCSR0A & (1<<UDRE0)) ) {} //wait for byte to transmit
 }

void StringPgmln(char * str){
do
  {
  serialWrB(pgm_read_byte_near(str));
 } while(pgm_read_byte_near(++str));
 serialWrB('\n');
}

int main (void)
  {
  UBRR0H=0;
  UBRR0L=207;//These values assume double speed is enabled (see below) and a 16mhz clock is used 3 = 0.5M 2M baud rate = 0 7 = 250k 16 = 115.2k 207 is 9600 baud rate
  UCSR0A|=2;//double speed aysnc
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);//Enable receiver and transmitter
  UCSR0C=6;//async 1 stop bit 8bit char no parity bits
 
  StringPgmln(PSTR("Hello world"));
  while(1){}
  }

Code:
Binary sketch size: 256 bytes (of a 32,256 byte maximum)

But by using "main" rather than setup/loop you are discarding the initialization that the libraries do for you, like setting up millis, the timers, the PWM outputs, etc.

Plus, your code has a hard-coded baud rate in it. Now of course you often want a hard-coded baud rate so that isn't too bad, but the supplied libraries work with a variable baud rate (as do digitalWrite with variables for pin numbers). So it isn't directly comparing apples with apples.

For a fair test, to prove that the libraries are "bloated" in the sense that they could have been written better, you need to compare with something that does the same thing.

Quote
I would like to point out that another advantage for the code compiled with avr-gcc vs the arduino Serial library is the string is stored in flash memory instead of ram.

It is a well-known technique that you can write:

Code:
Serial.println(F("Hello World"));

... in order to keep the string in flash memory.




A more direct comparison is probably:

Code:
int main (void)
  {
  UBRR0H=0;
  UBRR0L=207;//These values assume double speed is enabled (see below) and a 16mhz clock is used 3 = 0.5M 2M baud rate = 0 7 = 250k 16 = 115.2k 207 is 9600 baud rate
  UCSR0A|=2;//double speed aysnc
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);//Enable receiver and transmitter
  UCSR0C=6;//async 1 stop bit 8bit char no parity bits
 
  Serial.println(F("Hello World"));
  while(1){}
  }

OK, this uses your hard-coded baud rate, but the library println. And it does indeed use a lot of flash:

Code:
Binary sketch size: 1,248 bytes (of a 32,256 byte maximum)

An investigation reveals that the reason basically is that the whole Serial class is linked in (ie. Serial.available, Serial.peek, Serial.write, Serial.println etc.). Why, I'm not sure as usually the linker discards functions that are not called.

Also the generated code to handle incoming and outgoing serial interrupts is present. In practice, other than a simple example, you would probably need that. After all you usually need an interrupt handler for incoming serial, and one for outgoing serial. Your "small" example doesn't use those so it isn't really a proper test.

Put it another way: In a simple demo, which does nothing useful, you can produce smaller code. But that is exactly when you don't need it! A larger example, that handles interrupts, queuing output, timers, elapsed time, etc., your small examples are going to grow somewhat larger, approaching the size that the library-generated code is in the first place.
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Offline Offline
Full Member
***
Karma: 1
Posts: 131
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

As it turned out, the hardware engineer who put together the original prototype circuit board had made lots of mistakes that caused lots of noise on the pins and when we realized this and got another hardware engineer to come in and find and fix the issues things are working so much better now

Great thread this is

I am doing something similar but I am using a raw ATMega328 and an AVR dragon with a homebrew PCB prototype, the prototype is now very close to what will be the production model

I am interested to hear what the problems were the hardware engineer introduced?, was it simple tings like no decoupling caps and no pull down resistors?

Is there a definite checklist for hardware designs when using raw processors?, I think I have most of it covered but I am far from perfect!

I have read the datasheet and I think I am pretty much there but I would love to hear any suggestions on what is needed to ensure reliability

I have a ferrite bead and a 10uF and 0.1uF caps for decoupling/filtering of the supply

I Use 10k pull down resistors on the I/O pins I am using, should I also use pull downs on the unused pins?

I ground the ADC ground to the supply and use a 0.1uF cap between AVCC and ground I am using the 5V supply for reference so I dont think I need this cap but its not hurting

I am using two channels on the ADC, should I use a decoupling cap for both inputs ADC(0) and ADC(1)

To make the boards reprogrammable I bring out the MISO, MOSI, SCK, Supply +, Supply - and  reset

I have a pullup resistor on reset but I have found that I can't connect any resistors or anything to the MISO,MOSI and SCK as it refuses to program if I do this and thats copying what the datasheet advises probably me being stupid again but I have left them three pins unused for my program and I don't think it is a problem leaving these pins floating they are there should the software ever need to be changed not that I expect it to be field upgraded but its good to have the option IMO

Are there any other things I should be doing to make my hardware reliable?
« Last Edit: July 27, 2013, 06:02:26 am by Resinator » Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 549
Posts: 27425
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Unused pins, have your sketch define them as inputs with internal pullups enabled.
Get rid of all the pulldowns.
Put a diode in parallel with the reset pullup resistor, anode on reset pin, cathode to +5.

* Atmel AVR042 AVR Hardware Design Considerations.pdf (236.19 KB - downloaded 12 times.)
Logged

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Offline Offline
Full Member
***
Karma: 1
Posts: 131
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Unused pins, have your sketch define them as inputs with internal pullups enabled.

I will do that

Quote
Get rid of pulldowns

Use internal pull ups instead of external pull downs for unused pins  was the plan now its certain

Quote
Put a diode in parallel with the reset pullup resistor, anode on reset pin, cathode to +5.

Will do this, this isn't something I thought of, it doesnt affect programming does it?

Thank you
Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6639
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Put a diode in parallel with the reset pullup resistor, anode on reset pin, cathode to +5.

The diode is only needed if you have something connected to the reset pin that might drive it higher than Vcc. The Arduino Uno R3 has that diode, because there is a capacitor connected between reset and one of the outputs of the mcu used to do the USB-to-serial conversion; so without the diode, reset is driven above Vcc when that output transitions from low to high. Unless you have something similar in your design, you don't need the diode.

I have found that I can't connect any resistors or anything to the MISO,MOSI and SCK as it refuses to program if I do this and thats copying what the datasheet advises probably me being stupid again but I have left them three pins unused for my program and I don't think it is a problem leaving these pins floating they are there should the software ever need to be changed not that I expect it to be field upgraded but its good to have the option IMO

It's perfectly OK to use the MISO. MOSI and SCLK pins for other purposes as well as bringing them out to the ICSP header, if you obey the following rules:

1. If you use them as outputs, then they must be only lightly loaded (so don't use them to drive LEDs, reed relays etc.), and whatever is connected to them must not mind the signals that appear on them during programming.

2. You can use them as inputs for normally-open push-buttons or similar, if you don't use external pullup or pulldown resistors, and can guarantee that the push buttons will not be pressed during programming.

3. You can also use them to connect one or more SPI devices, if you have pullup resistors on the /CS pins of the SPI devices, to ensure those devices are not active during programming.

I typically use them as inputs for push buttons or as outputs driving LCD displays.
« Last Edit: July 27, 2013, 11:55:17 am by dc42 » Logged

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Wow! O.P. here. I got caught up in another project for a few days and finally got back to working on this project again and was taken aback by the number of replies to this post. I seem to have really hit a sore point on some issues!

To clear up some of the background for those that are interested......

Our products use a main control board that was engineered many years ago and has served us well, but we decided to embark on an effort to come up with a next-gen version for our newer products.

We prototyped this new project using the Arduino Uno and an RN-XV Wifly chip. The Arduino Uno and Wifi Shield/RN-XV plugs into our new main control board. The main control board does a LOT of other "non-Arduino" related stuff. (it manages some pretty big motors running at 240V and also controls some very powerful hydraulic valves) So they had a bunch of sample motherboards built with pins to allow me to piggyback the Arduino Uno on top of it to try things out. The code we've written does some pretty intensive stuff for an 8 bit chip, and it also communicates back and forth between multiple phones and tablets at the same time.

BUT......We had all kinds of stability issues on the Arduino side of things. After a lot of hair pulling on the software side, we brought in an outside engineer and he brought with him a really nice scope and showed us that the design of the motherboard was really bad (the original design engineer is no longer with the company). There was tons of noise being injected into the Arduinio by the motherboard, and that was causing all of the craziness.

So the original motherboard design was very bad. The engineer who designed it was no longer around. The new guy has fixed the design so that the Arduino works really really well, and the signals on the Arduino are now nice and clean (we had no idea how noisy the signals previously were since we relied on the previous engineer to handle that)

So, we have to now build the new improved motherboard that is now working as it should in prototype form. At the same time, we want to fold the Arduino and WiFly chips onto the board as well, so really, this is the perfect time to think about what chip we should use.

I really appreciate some of the tips that have been supplied, especially the one about noinlines, which will definitely look into. I've done some sample optimizations that can free up about 2K, and I'm sure if I tossed the WiFlyHQ library I am using and wrote my own version I could probably save a few more K.

In our situation though, it is very likely we will have improved versions of the firmware in the future that will have more features added to it, so by having more program memory it gives us the option of offering our customers an improved version without have to redesign the board.

My push has been to just work with what we already know, and stick with the 328. I can't imagine what they would want to add that would add beyond a few K of code space at this point. But if they do want to move to a bigger chip, it would seem that the 2560 or Arm Cortex chips are the best choice. (afterall, if you are worried about future proofing it, you might as well go with the current top-of-the-line option).

Everyone else is pushing for the 644, so we may wind up going that way. But I don't see a lot of people using the 644, so it gives me some pause.

In any case, I really appreciate all of the comments. It's been very informative. And it's given me some ideas to try some different things to optimize our existing code base.
Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 549
Posts: 27425
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I use the '1284P a lot, bigger memory version of the 644. 16K SRAM, twice that of the '2560, and much lower cost - like $7 in qty vs $17. 32 IO.
Easy to set up the IDE so it can just be treated like another board.
http://www.crossroadsfencing.com/BobuinoRev17/
Poke around here.
Logged

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

Global Moderator
Melbourne, Australia
Online Online
Brattain Member
*****
Karma: 511
Posts: 19331
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

To give yourself a lot of headway I'm inclined to agree with CrossRoads. The 1284 at least is the same basic hardware (most of your current code should work unchanged) and you have a lot of room to move.

If you move onto ARM you may want to first check how good the support is (eg. forums, libraries, etc.). I don't know myself, it might be great, but it would be a consideration.
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Is their any significant risk in using the Arduino IDE with a non-standard board or chip? I assume the 644/1284 series is different in significant ways to the 328 or  the 2560

My understanding is that the Arduino IDE does a lot of behind the scenes stuff that would be a lot more involved if using the Atmel Studio package

So whereas the 328 and 2560 are "officially" used by the Arduino team, what kind of issues might I run into using the IDE with a chip that's not "official"?

Thanks.

I use the '1284P a lot, bigger memory version of the 644. 16K SRAM, twice that of the '2560, and much lower cost - like $7 in qty vs $17. 32 IO.
Easy to set up the IDE so it can just be treated like another board.
http://www.crossroadsfencing.com/BobuinoRev17/
Poke around here.
Logged

Global Moderator
Boston area, metrowest
Offline Offline
Brattain Member
*****
Karma: 549
Posts: 27425
Author of "Arduino for Teens". Available for Design & Build services. Now with Unlimited Eagle board sizes!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

How do I say any more clearly that it's "Easy to set up the IDE so it can just be treated like another board."??

All the parts are in the 8-bit AVR family, core processing is the same, the difference is the amount of memory and IO ports. Your assumption is incorrect - nothing is significantly different.
Logged

Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

SF Bay Area (USA)
Online Online
Tesla Member
***
Karma: 137
Posts: 6805
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
what kind of issues might I run into using the IDE with a chip that's not "official"?
The big one seems to be that as the Arduino team updates the IDE in various ways, the "support" for the unofficial chips can be slow to get updated in compatible ways.  For example, the web pages at http://sanguino.cc (ATmega644-based derivative) still talk about modifying Arduino-0018  (there is a download for 1.01, but Documentation is a part of support too!)
Logged

Pages: 1 2 [3]   Go Up
Jump to: