Project Bambino

[CrossRoads]

Don't know, I'm not really a programmer, I just play one in the forum I'm not familiar with what the PC side is doing or how the programmer interacts with it.

[janost]

I can create the coolest thing ever but if it requires ISP not a single person is going to build it.
Sad but true.

I need to build something that is easy enough for everyone to make themselfs.

I was thinking that if I put an USB programmer onboard with a fat chip it would enable anyone to play with these kind of chips.

The 1284 is the largest anyone can solder at home?

[CrossRoads]

But - you need ISP to load a bootlaoder in, or set fuses, to start.

I used this one for a long time
http://www.mdfly.com/index.php?main_page=product_info&cPath=5&products_id=415
Had problems with '1284P (but might have been self induced frequency mis-matches) and I went to the MKii programmer to solve that, and then never went back.

If you follow some of the links you can get to the fischle.de (I think) programmer, and I recall there were lots of examples from folks who had made their own.

[CrossRoads]

I was thinking that if I put an USB programmer onboard with a fat chip it would enable anyone to play with these kind of chips.

The 1284 is the largest anyone can solder at home?

You mean like this?
I used an FTDI module vs discrete chip because I found the little chip too hard to solder,
and you can leave the module off and use an off-board USB/Serial adapter for downloads and the disconnect it for embedded projects.
http://www.crossroadsfencing.com/BobuinoRev17/


'1284P is the largest DIP, after that the 1280, 1281, 2560 are surface mount.

[janost]

Yes, exactly like that

Instead of a bootloader (or kind of) I plan to have a BIOS able to show video, read a keyboard and do files with an SD-card.
Out of the box.

An Autostart.hex on the card will start at Power on.

I plan to make something that presents a DOS if nothing is burned on the chip.

As fungus said, you dont need serial debug if you have video.

[janost]

I was thinking that if I put an USB programmer onboard with a fat chip it would enable anyone to play with these kind of chips.

The 1284 is the largest anyone can solder at home?

You mean like this?
I used an FTDI module vs discrete chip because I found the little chip too hard to solder,
and you can leave the module off and use an off-board USB/Serial adapter for downloads and the disconnect it for embedded projects.
http://www.crossroadsfencing.com/BobuinoRev17/


'1284P is the largest DIP, after that the 1280, 1281, 2560 are surface mount.

That is so Beautiful.

But why the FTDI module?

I want it to be just as easy as the Uno and just as cheap.

[CrossRoads]

USB/Serial chips are all very small, and we had trouble soldering them by hand.
FTDI chips are $4.50, plus the other parts that go with it. Pricewise the module works out to about the same, and it only has regular 0.1" pins to solder.
The module can be left off, and an offboard USB/Serial adapter plugged onto pins for programming and then unplugged when USB connectivity is not needed for embedded operation. I was going for a modular board that could be user repaired.
That makes it as easy as the Uno. I can't make is as cheap when I'm only working in qtys of 25 that  I slowly sell, vs Arduino making thousands and selling worldwide. $22 for a kit of parts is pretty darn reasonable, and $10 more if you want built in USB.

[janost]

I Think I will use a 3.5mm stereojack for both audio and video in the same connector.
Its compatible with both a normal stereo 3.5mm to audio RCA Cable and a 3.5mm to AV RCA 4-pin plug with mono sound.

It will save space and the RCA female is to large to fit the Bambino board.

[janost]

Why doesnt the ArduinoIDE erase the chip Before uploading?

I got the dreaded "Verification error" and googled it to find out that the chip must be erased Before reprogramming the sketch.

And the upload using programmer menu doesnt work.

Can I add the -e switch anywhere in the IDE to get it to erase Before uploading?

[CrossRoads]

I don't know. I don't see that when I program.

[fungus]

Why doesnt the ArduinoIDE erase the chip Before uploading?

It does.

[janost]

No i doesnt.
The bootloader does when you upload.

If I program the chip without a bootloader I have to erase it first with avrdude -e switch.

[fungus]

Why doesnt the ArduinoIDE erase the chip Before uploading?

I got the dreaded "Verification error" and googled it to find out that the chip must be erased Before reprogramming the sketch.

Don't believe everything you find via google.

It would be pointless making a program that didn't do an erase cycle when you do an upload. It would never work, ever.

When I upload a program with ISP I see this:

Code: [Select]


H:\program+files\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CH:\program+files\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cusbtiny -Uflash:w:h:\temp\Arduino\build\tinydream.cpp.hex:i

...

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.


Note no '-e' option in the command line. Message says you have to disable the erase, not enable it.

[janost]

That is why i suspected there might be some setting for it.

Now I have to erase the chip with Avrdudess GUI before I can upload in the ArduinoIDE.
It does not erase the chip before upload.

Could be something in avrdude.conf regarding AVRispv2?

[janost]

From the Avrdude documentation:


-e
Causes a chip erase to be executed. This will reset the contents of the flash ROM and EEPROM to the value '0xff', and clear all lock bits. Except for ATxmega devices which can use page erase, it is basically a prerequisite command before the flash ROM can be reprogrammed again. The only exception would be if the new contents would exclusively cause bits to be programmed from the value '1' to '0'. Note that in order to reprogram EERPOM cells, no explicit prior chip erase is required since the MCU provides an auto-erase cycle in that case before programming the cell.

-D
Disable auto erase for flash. When the -U option with flash memory is specified, avrdude will perform a chip erase before starting any of the programming operations, since it generally is a mistake to program the flash without performing an erase first. This option disables that. Auto erase is not used for ATxmega devices as these devices can use page erase before writing each page so no explicit chip erase is required. Note however that any page not affected by the current operation will retain its previous contents.



I know this is not an ATxmega device but some fishy is going on.