Migration from mega 8 to mega 48

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a mega8, 4 digit counter with a few hundred bytes of code, running 8MHz int RC.
I have tried a mega48 but it doesn't work. Can anyone offer any suggestions as to what is different?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most will be covered in (M8->M88):

http://www.atmel.com/dyn/resourc...

I guess but it's probably worth a trawl through the entire section to see if any of the other migration notes are relevant - here:

http://www.atmel.com/dyn/products/app_notes.asp?family_id=607#Migration%20Notes

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As clawson said, the migration document should give you everything that you need. Tell more about what "doesn't work" means. No, a compiled/assembled binary cannot just be dropped from one to the other. Vector tables are different for one thing, along with the entire I/O map. Certain I/O bits have "moved". Fuses will be different.

It isn't a hard port. Give more details.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've looked at the info, and yes, it's a long wayfrom a dropin. :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

it's a long wayfrom a dropin

???

Yes, we are experienced with AVRs at our shop. But a Mega8 -> Mega48 conversion should be about an hour of work on the C code, and some time with the fuses.

Is this an ASM app? Then maybe a bit longer 'cause the compiler won't help with interrupt vectors, individual I/O addresses, etc.

How many I/O references and ISRs could there be in a "few hundred bytes of code"? ;) Post here, or post parts that are questionable, or PM the code to me explaining which part(s) are scary.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I occasionally write asssembler code for the Mega48. First I write it for the 4433 and run it through the ICE200 in-circuit-emulator. The 4433 and Mega48 have the same features and pin-out.
The biggest difference is the need to use LDS and STS instructions to access the peripheral registers on the Mega48 because they are often outside the range of the In and Out instructions. I use LDS/STS for all peripheral access by adding 0x20 to the peripheral addresses located below 0x3f.
SBI and CBI instructions have to be implemented by first using LDS to read the value into a register. Then use the SBR and CBR to change the value, followed by an STS instruction.
SBIC and SBIS are implemented by using two temp registers. Get the original value from the peripheral into the first temp register using LDS. Use the second temp reg to make a mask for setting/clearing a single bit in the first temp reg. Then use the logic OR or logic AND instruction and the mask temp reg to isolate the test bit in the first temp reg. Branch according to whether the test bit is set or clear. What was a single instruction implementation in earlier AVR devices now takes 2 to 4 instructions. But the newer devices are cheaper and have more memory. This is all in assembler; it's possible that a C compiler will do all this transparently.
I set up the peripheral addresses for the various devices in the EQUATES section of the code by giving new names to the peripheral registers. Then the main code uses these new names for the peripheral registers. For example:
.equ MyLowBaud = UBRR0L ; Mega48
.equ MyLowBaud = UBRR + 0x20; 90S4433

ldi temp, (sysclock / (TargetBaud * 16)) -1
sts MyLowBaud, temp

This type of coding is a lot more work to set up at first, but it makes moving between devices easier.

Moving from the Mega8 to the Mega48 shouldn't be too difficult. Check the peripheral addresses and names first. Then check if there is any problem with the memory allocation of variables. Also check that the stack pointer is positioned at the top of memory. SRAM is 1K on the Mega8 and 512 bytes on the Mega48.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is hard to really work up proper fury without any details. What language? A small C or other higher-level language program may need nothing more than a recompile. At worst, a small program as described would require a check of each I/O register against the list of those that have changed. A small program as mentioned has what? Half a dozen I/O registers to look at?

And the responses to our questions was a short sentence and a frowny-face. No language statement. No source code or fragments. No description of what has been tried and the results.

It is at most an afternoon job to port a full Mega8 app to a '48 (assuming it fits into flash & SRAM & EEPROM--let's say Mega8 to Mega88). The small app as described should be going in less time.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.