so your Ethernet board won't work with 1284 chips.
The point is, 1284 support has only recently been started to be included in the IDE AT ALL, and still hasn't been completely wrung out. The reason I know this is because
I've had to fix these things myself to get my 1284 boards to work.
jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328. I am positive that part of this is just that I don't code very efficiently (because I don't know what the heck I am doing) but going through all of my variables, even if I put some of the constant data (strings and such) in progmem I am still going to be constrained and it won't allow for any additional features on my program. I'm thinking the Mega644P may be a good next step up since it appears that the good folks at Sanguino have added support for this uC in the arduino IDE. It doubles the amount of flash and sram relative to the 328. It also comes in a fairly reasonably sized package (I don't need something in a massive 100 pin package). Any thoughts on using the 644P as a reasonable next step up from the 328?
I am not sure what you are trying to do but I think better coding would allow you to have all the features you want and keep using the atmega328. Also you only want strings and constant arrays in PROGMEM if it is just one varible you don't want that in PROGMEM. If it turns out that it is impossible to get the code to fit on an atmega328 then I would get something with more flash. Would you be able to post your code? It would help me evaluate if you really need to upgrade or this could be optimized to fit on an atmega328.
jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328. I am positive that part of this is just that I don't code very efficiently (because I don't know what the heck I am doing) but going through all of my variables, even if I put some of the constant data (strings and such) in progmem I am still going to be constrained and it won't allow for any additional features on my program. I'm thinking the Mega644P may be a good next step up since it appears that the good folks at Sanguino have added support for this uC in the arduino IDE. It doubles the amount of flash and sram relative to the 328. It also comes in a fairly reasonably sized package (I don't need something in a massive 100 pin package). Any thoughts on using the 644P as a reasonable next step up from the 328?
I am not sure what you are trying to do but I think better coding would allow you to have all the features you want and keep using the atmega328. Also you only want strings and constant arrays in PROGMEM if it is just one varible you don't want that in PROGMEM. If it turns out that it is impossible to get the code to fit on an atmega328 then I would get something with more flash. Would you be able to post your code? It would help me evaluate if you really need to upgrade or this could be optimized to fit on an atmega328.
Sure! There is a link on reply #3 that has the code.
jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328.
From your comment about code length I guess you're talking about program memory. How much is your sketch taking currently? You've only got a few hundred lines of code there so I wouldn't have thought that your own code would be using up a lot of it and probably the libraries you're using are responsible for most of it.
By the way, your implementation of timer() does not handler millis() overflow correctly. To handle overflow, you can code it like this:
PeterH:
By the way, your implementation of timer() does not handler millis() overflow correctly. To handle overflow, you can code it like this:
if(millis() - lastTime > interval)
{
// interval has expired
....
Mine should do the same thing. My code is:
//keep track of time and handle millis() rollover
boolean timer(unsigned long timeout)
{
return (long)(millis() - timeout) >= 0;
}
and then when I need to time something I do something like this:
last_valid_data = millis() + 2000;
and then I can just call timer like this:
if(timer(last_valid_data))
which I believe mathematically is equivalent to your code. I could be wrong though. I took calculus twice in college and still only squeaked out a "C" grade so my math may not be up to snuff.
The rollover business is fairly subtle. As I recall, the code in the BlinkWithoutDelay example
works correctly [although it does look like they declared previousMillis poorly]. Other forms
may look correct, but will give incorrect results. It pays to feed in a few values near the
rollover value and test the different forms.
long previousMillis = 0; // will store last time LED was updated
void loop()
{
unsigned long currentMillis = millis();
if(currentMillis - previousMillis > interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
// if the LED is off turn it on and vice-versa:
if (ledState == LOW)
ledState = HIGH;
else
ledState = LOW;
// set the LED with the ledState of the variable:
digitalWrite(ledPin, ledState);
}
}
I just read through your link and it is fantastic! I am wondering though, does any of this matter with regards to the package that I choose? I am trying to fit this all onto a fairly small board so I probably won't use the pdip version of the 1284P. If I am feeling brave I may go for something as small as the QFN package as I have had a lot of success hand soldering a 4mmx4mm QFN10 package and I think I may be okay soldering something that is materially bigger than that.
I think most of those items will still be applicable, except possibly the RX0
problem. Depends on whether the RX0 pin is located adjacent to the
Oscillator-in pin on the chip you use. Also, maniac bug still hasn't fixed
the Bobuino variant file. And you will still need to check all of the
library files for proper 1284 support.
oric_dan:
I think most of those items will still be applicable, except possibly the RX0
problem. Depends on whether the RX0 pin is located adjacent to the
Oscillator-in pin on the chip you use. Also, maniac bug still hasn't fixed
the Bobuino variant file. And you will still need to check all of the
library files for proper 1284 support.
CrossRoads:
Who knows. Can anyone access them besides Maniacbug?
Maybe time to copy them into a new area and start referencing that instead.
Ah! Truly excellent idea - time to fork the library and fix the bad boys.
The slight problem with this is how to get the word out that the library has been
forked, so people use the correct version. --> ????
Along these lines, I've recently been using MP-IDE and the ChipKit libraries for the
PIC32 [roughly Arduino compatible], and "belatedly" discovered there are 2 forked
libraries and both have the identical same name, and with just a few files different
this is a HUGE bummer. I lost a couple of days because of this silliness.
Well, calling it a new name and posting about in the forum would help.
Not sure how else folks come across it.
Call it something else besides mighty1284, just need to tweak a few names in the variant folder & pins_arduino.h, shouldn't take much. Like make it all Mega1284P, and keep Bobuino the same. Can add 164P, 324P, and 644P variants as well.
I figure you're the guy, since the big the problems are in the Bobuino variant,
plus I've never used any of those other processors myself, :-). Then, we can
stop referencing the bug library, along with wasting time over and over telling
everyone to beware of the bugs, ad nauseum, and can refer them to a fixed
library.
The name wouldn't have to be too different, just enough so that you don't
have 2 different libraries with the same name on your HD, and wondering which
is which.
If it were me, I'd change the library name, and also the name of the primary .h
file at least. This bugs me about the nRF2401, RFM12, and RFM22 libraries, is
that everyone picked such similar names for completely different RF modules,
all the way down to the .c and .h files.
I plan to order the PDIP version of the 1284P on my next mouser purchase so that I can breadboard my project and hopefully I can try out some of these fixes.
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');
serialWrB('\r');
}
Serial.println("Button Pressed");
becomes
StringPgm(PSTR("Button Pressed"));
The problem with the serial library is the text is stored into the ram even though the strings are constant. My code stores it in the flash memory.
If you want to send text from the ram use this code
Only use the StringSerialln for non static strings
Also you must remove Serial.begin too so change
Serial.begin(115200);
with
UBRR0H=0;
UBRR0L=16;/*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
Note if your processor has multiple uart outputs change the number from 0 to whatever you want. If you are using an arduino board the one that gets sent to the usb is 0.
That should save some space I can suggest more optimizations if it still does not fit on whatever processor you have.