For my first ATmega1284P design, I wanted a small breadboard-friendly module with all the necessary support components plus FTDI and ICSP programming headers. The name is a nod to maniacbug's core for the 1284P. It's a general-purpose design with all GPIO pins brought out to headers so I thought I'd share it in case others could use it.
wanderson:
I have been meaning to try out OSH Park, so I ordered a set of your boards. Will post when I have put one together and tried it out! Thanks!
Cool, I look forward to hearing about it! Hmmm, you look like a biker? Slow spring here, bikes still in basement
Yep, I hate driving, so I use a bike for most of my transportation needs. I ride year round, though I try to avoid our icy days as much as possible. Thinking of getting a fat tire bike for those occasions in the winter, and to deal with the sandy areas around the four corners areas when I go out there.
I've been playing with the 1284p for about 6 month now. I love it. 16 kb of RAM comes in handy as you basically never have to worry about maxing out and hanging and having to troubleshoot that.
Glad to see the 1284 community growing! I use the Mighty bootloader as well. Maniacbug did a great job. Something to note is that you may want to include this branch with the bootloader so that you can use INPUT_PULLUP: Implement INPUT_PULLUP · wijnen/mighty-1284p@61f24a9 · GitHub
(It's just one or two lines of code, so you can just change it on your own).
I'll post some info on my project soon. For now, I am using the DIP package, but I will soon be in SMD land.
pekasus:
Glad to see the 1284 community growing! I use the Mighty bootloader as well. Maniacbug did a great job. Something to note is that you may want to include this branch with the bootloader so that you can use INPUT_PULLUP: Implement INPUT_PULLUP · wijnen/mighty-1284p@61f24a9 · GitHub
Glad to hear from another 1284 fan!
For the last week or so, we've been discussing and working towards a refreshed version of maniacbug's work based on Arduino 1.0.5. Just this afternoon I pushed what I hope is the first release. Consider it to be beta status, but check it out here. The (rather lengthy) discussion thread is here.
Wow...that is a lengthy discussion. I'll read through it in a bit. This is great bc the 1284 needs an ongoing discussion to keep it alive. The nice thing about it is that is breadboard-able, which is key for the open hardware community.
On another note, I saw that you posted about bikes. A group at Code for Philly just finished the Cycle Philly app http://www.cyclephilly.org/ (which can be used anywhere). I am now working with that group to link it with bluetooth to a 1284 board that reads pollution data and will get linked to a map. The goal is to empower bikers to seek out pollution (and ultimately avoid it). We may be able to use your board design to move the project faster to an SMD design (its currently DIP).
Sadly, I can't seem to get the board to program a bootloader.
I am using an AVR ISP Mk II with AVR STUDIO v. 6 on a Windows XP virtual machine, since avrdude stopped recognizing my Mk II when I upgraded Ubuntu. I have just used this same configuration to burn a bootloader for an Arduino Leonardo to confirm the equipment is working.
When connecting the Mighty Mini 1284P I am getting a message indicating that the device will not enter programming mode. I have examined the board with a 10x loupe and can not see any bridged connectors or other obvious problems.
Oh no! How can I help? Will it not even read the signature and fuse bytes?
wanderson:
Sadly, I can't seem to get the board to program a bootloader.
I am using an AVR ISP Mk II with AVR STUDIO v. 6 on a Windows XP virtual machine, since avrdude stopped recognizing my Mk II when I upgraded Ubuntu. I have just used this same configuration to burn a bootloader for an Arduino Leonardo to confirm the equipment is working.
When connecting the Mighty Mini 1284P I am getting a message indicating that the device will not enter programming mode. I have examined the board with a 10x loupe and can not see any bridged connectors or other obvious problems.
Yep, will not even read the signature or fuse bytes. Which tells me I likely did something wrong with assembling it. Not sure what. If you like I can mail it to you and you can look at it at your convenience, I don't have the time right now to debug what I did wrong.
Assembly was with solder paste and an electric skillet? That's a real good photo and things look good. Send it if you like (do you have the address?), I'm not sure what I might do other than maybe reflow the solder on the MCU, but like I said, looks pretty good already. Of course I'd just try to program it first, but it sounds like your setup works fine too.
Yes, I use type 3 solder paste and an electric skillet to perform reflow. I then use a soldering iron and solder wick to remove any excess solder that might bridge two adjacent pins. Seems to work quite well.
I am wondering if perhaps there was a problem with the board from OSH park. If you look at the photo you will notice a flaw with the silkscreen printing at PD0:7. I am wondering if perhaps there was a flaw with the copper... If I connect the FTDI header to a computer, the LED D2 doesn't light, but that should be the case since you have that wired to pin and not as a power indicator? I can't think of anything else at the moment. I don't have your address readily available, so if you could IM it to me I would appreciate it if you would like to look at the board, if not I can put it on the shelf until I get time to work on debugging it.
wanderson:
I am wondering if perhaps there was a problem with the board from OSH park. If you look at the photo you will notice a flaw with the silkscreen printing at PD0:7. I am wondering if perhaps there was a flaw with the copper...
I saw that, but an actual copper problem would be highly unusual, I've never had a problem with a board from OSH Park, even the silk screen is usually very good. See attachments of top and bottom copper layers, not sure that anything in that area would interfere with programming anyway. The SPI pins are the first three on the top of the left side of the chip.
If I connect the FTDI header to a computer, the LED D2 doesn't light, but that should be the case since you have that wired to pin and not as a power indicator?
Correct, it is not a power indicator. Actually it's connected to the SCK pin which is D7 on this board, and so should illuminate during programming.
I can't think of anything else at the moment. I don't have your address readily available, so if you could IM it to me I would appreciate it if you would like to look at the board, if not I can put it on the shelf until I get time to work on debugging it.
I tried speeds as low as 64K, still no joy. Also, note, I couldn't get AVRSTUDIO to even read the chips signature. My understanding is that this operation is designed to work even if the clock speed on the chip is only 32kHz.
My best guess is that there is a connection issue, either with my soldering (most likely), or with the circuit board (least likely).
No, the off the shelf version doesn't, but I hacked mine to provide either 5V or 3V when programming (this can be switched off). I was powering the board with 5V.
and a link to an earlier thread where I described the mods I made to my MK II