Do you forsee many problems with using a hex file compiled for the ATmega644P on an ATmega1284P?
I changed out the 644P for the 1284P on a couple of boards, and programmed the microcontroller via the SPI interface as normal. And the software seems to be running fine.
Obviously, I'm not gonna be able to utilize the whole flash, RAM or EEPROM on the 1284P. But will the software run as normal, and not crash when I turn my back?
Thank you for any and all input! :)
Since you don't know anything about SRAM-usage I would call this a russian roulette.
Read your data sheet.
1. Does it have the same interrupt vector table?
2. Does it use the same AVR instruction set?
3. Does it have the same fuses?
4. Are there any migration notes for 644P to 1284P?
Check all these points, and you will have your answer.
No. I have not checked these points myself. But I have a pretty good guess as to what the answer is.
David.
p.s. If you do not have access to the source code, you will never know if the author deliberately misused SRAM or sfr's.
Thanks for your answers. I've had a looksee at the data sheet, and as far as I can see the two chips are more or less identical. I found only small differences between the two.
But since noone can guarantee that this won't cause crashes or weird error symptoms in the future, I'm starting to think that the risk of failure outweighs the gain from not having to compile two sets of hex files.
It could be an interesting experiment, but I don't think I want to take the chance. :)
Thanks again.
If you have the source code, you are fine.
If you ask the original author, she may give you a new binary.
If you can trust the original author would not misuse registers etc., you are fine.
If you have the source code, you just re-compile for the correct AVR model and you should be fine.
David.
Yeah, you're right. As the hex files are stored in the flash of a main CPU, it would save both storage space and the time of compiling them to have only one set of hex files. But after checking a bit, I don't think it's worth the risk. We get enough vague and weird error messages as is, without adding more potential fault areas to the mix. :)
On another note, I have to give you credit for being politically correct when referring to the original author as "she". Alas, I wish this was true in a much larger extent. At least it would add some spice to the vast landscape of portly coke/coffee drinkers I see every day (and am a part of, I'm sorry to say). ;)
You have never said whether you own the source code.
Compile for m644P and for m1284P. diff the hex files.
If you just want to keep a single binary, yet find the larger chips more widely available. You should be fine.
David.
I'm sorry if I was unclear. My employer owns the source code, so I have the ability to modify it.
I diffed the files, and they're completely different. Furthermore the m1284P hex file is 49 bytes larger than the m644P hex file. So no, I don't think I'll take the chance of using the m644P file on the m1284P microcontroller then.
Øystein.
I diffed the files
But if you have the source I don't see the point of this thread? - you just set the build system to the model you want to use, press the Build button and out pops the suitable .hex
But if you have the source I don't see the point of this thread?
-- '48 binary will work on a '88.
-- '169 binary will work on a '329.
-- '640 binary will work on a '1280.
Now, I don't know if every feature is exactly the same. With those above I've tried on the bench (as well as one batch of '88/'48 in the "field").
If indeed the vector table is the same I think OP might be OK. Caveat emptor.
But Lee, how much time does it take to set MCU=xxxx and [build] to be absolutley sure the code is correct? It just seems to be a form of laziness to not simply rebuild the code image.
Lazy? I guess. In our case we were too "lazy" to make a separate firmware for what is/was expected to be a single-run of a few dozen units. No additional "part number" for the rebuilt firmware; no special instructions for the build crew or the rework crew to identify the processor type that happened to be on a particular board.
We are probably going to do it again soon. The upgraded processor will allow more features for the "deluxe" model. But the "non-deluxe" existing model can be built-upgraded-reworked with no regard to the particular processor.
[Actually, I lied--the signature check will fail. What a tangled web we weave...]
Lee
clawson: Good point. The bin files are similar, true enough, but not equal. It is of course not a problem changing the microcontroller in the build setup for only one card. But we prepare SW packages for our product used in the hospitality TV industry, which is produced in the range of 15-20K units per year. Early HW rev. came with 644P, but now comes with 1284P. Therefore, shaving off both time and storage space by compiling for only one of the chips sounded like a good idea. But since even Atmel tech support advice against it, I believe we'll shelf the idea. :)
theusch: Thanks for the info. But as you say, Caveat emptor indeed. :)
-Øystein.
-- '48 binary will work on a '88.
Eugene
which is produced in the range of 15-20K units per year.
A one-time project to read the signature at the programming station and then apply the correct flavour of firmware would add nothing to the per-unit build cost.
At those volumes the cost of a "gotcha" will far outweigh any assembly savings IMO.
