Compile for Atmega 1284p
Brought to you by:
oh2aun
Menu
▾
▴
Hello!
Is there any documentation for how to compile for the Atmega 1284p? I've found one in my component storage and it would be nice to test this chip.
I'm used to electronics and programming but I have no experience with compiling for Atmega processors (and quite rusty when it comes to assembler)
I think you mention about Mikael's github : https://github.com/oh2aun/flashforth/tree/master/avr/FF-ATMEGA.X
But every chip has different specs or peripherals, I think it is not an easy step as you think. He can answer your question if he wants
Hi,
You need to install MPLABX V6.20 and XC8 V3.10. These are the versions I am using.
Then create a project with ff-xc8.asm as source file.
I will update the code to compile with the Atmega1284 and related CPUs. Obviously I cannot test since I do not have the hardware.
Last edit: Mikael Nordman 2026-03-05
So now there is support for 1284 and 1284P. Also many others seem to compile and run in the MPLABX símulator. There are also ready made HEX files for 1284 and 1284P.
These are not tested on real hardware.
Don't hesitate to ask in case of problems.
Wow, you're really fast!
Hello and thank you for your time!
It sort of works, it boots with the message:
E FlashForth 5 ATmega1284p 05.03.2026
But then it stops. I've tried several methods of programming the chip (TL866II+ ZIF and ICSP) and avrdude through an usbasp. The latter feels more robust.
I've also tried to power it with both external 5V and with the FTDI adapter.
The only thing I can think of is the fuses. I've (sort of) read the documentation and concluded it should be the same as the 328p.
As this is only an hobby for me it is not super important but it would be fun to make it work. I will do some more testing tomorrow.
Could it be something simple like the UART line not being connected?
In the simulator the UART RX configs and interrupt vectors look right.
Are you using UART0 ?
I also think the same fuses as the 328P should work.
I use UART0 (pins 14=RXD0, 15=TXD0). I also use the "same" breadboard setup (obviously with shifted pins) for an 328p and it works. I will check all connections (for the umpht time) later today.
I've done some more testing and have "reliable" boot after reset with "E FlashForth 5 ATmega1284 05.03.2026" displaying each time.
Here's an example of output with a few key press from me:
after that it is non responsive
I got it to work TWO TIMES and tried "words" and a few calculations, all working perfectly.
Electrically the chip sits on a breadboard with decoupled +5V from the FTDI. As I said before the setup works with a 328p.
Fuses are: LOW: 0xFF, HIGH: 0xDF, EXT: 0xFF
If it sometimes works, I would say you have a hardware problem.
Maybe some intermittent connections on the breadboard. Poor decoupling etc,
Is the clock reliable ? 16MHz? Check the clock with an oscilloscope.
Does the FTDI supply enough current ? Are there voltage dips on the 5 volt.
Does USB supply enough current? Are there other devices on the same USB bus? Front side USB connectors can be current limited by the computer internal wiring. I had that problem one time.
The USB connectors or the cable can be bad, but unlikely when the 328 works.
You could try with EXT:0x04. That activates the brown-out reset at 4.3 volts. It prevents the chip to run at too low voltages.
You could try with LOW:0xf7 to use the full swing oscillator that has more gain. This could be a solution if the crystal is just marginally working in the low power mode(LOW:0xff).
It looks like the full swing oscillator did the trick. I thought i had tried that but obviously not...
Big thanks for the time you've invested in this!
If anyone is interested: I've tested all digital input/output and the ADC and everything works. The only glitch was that the pins for UART1 were configured for serial communication.
Next step was to test TWI/I2C and this does not work. I've compared the 328p and the 1248p and they are the same. Even different AI-chats (they sometimes have a hard time with Forth, but thats ok with me :) ) agree with me, it should work. When I inspect a simple i2c.ping with a logic analyzer the CLK-signal generates a 100kHz signal (for several 100ms) until the 1248p reboots . I have tested with a few different peripherals that works perfect with the 328. Any tips are welcome but I will continue to investigate...