Go Down

Topic: atmega1284 programming from a 328 chip (Read 11704 times) previous topic - next topic


Jan 29, 2013, 11:41 pm Last Edit: Jan 30, 2013, 12:19 am by retrolefty Reason: 1
Well I would like to report a successful 1284P installation, so I will.  ;)

I'm using CrossRoads great through-hole Bobuino board and so far no signs of serial uploading problem using a 68K big sketch on repeated tries, no errors reported or seen.

So I would like to thank CrossRoads for designing, building, and selling a great blank PCB that will support 644P and 1284P chips, and a big hand to Nick's great bootloader program that kept me from having to purchase a more capable hardware programmer then the USBtiny that I do have.

So my Arduino (well one of them anyway) now has 16K of SRAM, how large is yours?  :D



Well if it's good enough for Lefty.... I'll build the PCB tomorrow and report back.


So lefty, what is the data code on your chips? The 1284Ps I got last week are 1247.


So lefty, what is the data code on your chips? The 1284Ps I got last week are 1247.

Forgot all about datacode thing. Just checked and it's a 1247 also, so either 47th week or 47th batch of 2012, sounds like a fresh one to me.

Which remind me that starting Friday for 3 days our Local Lucky grocery store is having a sale of fresh (not previously frozen) Dungeness crab for $3.99 a pound. Quite a reduction if price as it's been pretty high this year.



OK we have a result.... it programs with no errors

I followed the notes on this site (http://www.gammon.com.au/forum/?id=11637 I breadboarded both chips and having confirmed the 328P was working, hooked up the ICP pins between both chips.  Loaded his sketch that interrogated the 1284p and the serial monitor reported details as described, so that proved the 1284p was running.  I then sent the command to upload the optiboot loader which again came back as successful.   I continued down the page and downloaded the files from Maniacbug's site again and copied them to the hardware folder, confirming the operation to overwrite the existing files.

Removed the ICP wires and connected the RX and TX lines, with the DTR to reset via the 0.1uf capacitor.  I also found and placed a 220K resistor in series with the TX line from the FTDI board (had previously tried this with the same sync errors before I re-loaded the bootloader).  Loaded the BLINK sketch, selected the Mighty 1284p optiboot 16mhz board and clicked on the upload....and waited

The TX and RX leds flickered as they did before... then flickered again as data was transmitted.... I hocked up the LED to pin 19 (D13 in the mappings) and it's flashing away as I type. :) :)

My only conclusion, and I don't mean this with any disrespect, is that the initial upload of the bootloader either failed, or in some way got corrupted ??

Anyway... I'm a happy bunny now, and can now start work on building my aquarium controller project - Thanks to all those who have commented and offered suggestions


Well, good at last. Breadboarding on both sides is probably not something I would have
wanted to do myself.


Jan 30, 2013, 08:16 pm Last Edit: Jan 30, 2013, 09:05 pm by pito Reason: 1
FYI - This is how the 115kbaud signal (ie. 0xAA, 0x55 sent) looks like at the 1284p' Rx input when passed via 220kohm serial resistor with 100pF to ground (the "RC filter"). Hard to recommend, though.. The same with 10k pullup on the Rx input. The same with 10kohm serial.. And a picture when connected directly w/o the "RC" filter (FTDI or BT output resistance assumed ~200ohm typically)..


Jan 30, 2013, 09:21 pm Last Edit: Jan 30, 2013, 09:24 pm by oric_dan Reason: 1
10K series-R with 100 pF to gnd looks like the winner, if wanting to make a reasonable
low-pass filter on RX0.

For reference, you might try the 220K series-R *without* the 100 pF to gnd, and no pullup.
The first and second waveforms here are useless. The first is basically like smoothing out
a PWM signal to produce a d.c. level, and in the 2nd, the output is too tiny.


Basically I would not recommend to put 220k in series even w/o the cap for such speeds..


Looks about right. Estimated capacitance to gnd, from T.C. = 63% of swing, is approx
C = 2.5usec/220K = 11.5 pF. Spot on. Slow, but much better than with the 100pF on


Must admit all that with the graphs went over my head :)

I now have another issue, and would welcome comments.

I've breadboarded the chip neatly, and tested it using the example blink and fade examples - worked fine.  I then breadboarded the 1307 RTC chip and uploaded the sample code below (found on this forum)

Code: [Select]

* Read and set through serial port demo sketch for DS1307 I2C rtc clock
* DS1307 library provided by mattt & D.Sjunnesson, corrected by bricofoy.
* See DS1307.h for more details.
* This exemple code is under GNU GPL
* (c) bricofoy 2012

// This is for compatibility with both arduino 1.0 and previous versions
#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#include "WProgram.h"

#include <Wire.h>
#include <DS1307.h>

void setup() {

// use explanation message
void use() {
  Serial.println("\nUSE      : u U r R h[00-23]m[00-59]s[00-59]j0[1-7]D[01-31]M[01-12]A[00-49]");
  Serial.println("\nEXEMPLE  : h09m35d03 set time to 09h35 and day of week 3 (thuesday).");
  Serial.println("\nCommands : h** : hour,  m** : minutes, s** : seconds, d0* : day of week");
  Serial.println("           M** : month,  Y** : year,   D** : day of month.");
  Serial.println("           r stops clock, R starts it. ");
  Serial.println("           u or U shows this message, all other caracter shows time.");

// DS1307 time read function
void read_RTC() {
  Serial.print("\nActual time : ");
  Serial.print(RTC.get(DS1307_HR,true)); //read the hour and also update all the values by pushing in true
  Serial.print(RTC.get(DS1307_MIN,false));//read minutes without update (false)
  Serial.print(RTC.get(DS1307_SEC,false));//read seconds
  Serial.print(" ");                 // some space for a more happy life
  Serial.print(" ");
  Serial.print(RTC.get(DS1307_DATE,false));//read date
  Serial.print(RTC.get(DS1307_MTH,false));//read month
  Serial.println(RTC.get(DS1307_YR,false)); //read year

// set clock values
void write_RTC() {
      char value=0;
      char command=0;

      command = Serial.read();
      delay(50); //delay to allow good serial port reading
      value=byte((Serial.read()-48)*10); //-48 becaus ASCII value for 0 is 48, 1 is 49, etc and *10 because we read tens first
      value+=byte((Serial.read()-48)); //and then we read units

      switch (command) {
case 'h' :
  Serial.print("hours set to ");
case 'm' :
  Serial.print("minutes set to ");
case 's' :
  Serial.print("seconds set to ");
case 'D' :
  Serial.print("day of month set to ");
case 'd' :
  Serial.print("day of week set to ");
case 'M' :
  Serial.print("month set to ");
case 'Y' :
  Serial.print("year set to ");
case 'u' :
case 'U' :
case 'r' :
  Serial.println("Clock stopped");
case 'R' :
  Serial.println("Clock running");
default :

void loop() {
   if (Serial.available()) {

This is (if I ready the details correctly) will display the date / time via the serial monitor, which is fine as I don't have an LCD hooked up yet.  The code compiled and loaded without error, but when I launched the serial monitor I got the message that the port was in use and I needed to close other applications.  So I tried uploading the basic blink example and got the same message... it seems that the code running won't free up the com port :(

Any suggestions ?



belay that - re-boot the PC and all is well

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131