How do 1284P boards get added in 1.6.9? I'm totally new to that.
Looks like it may be as simple as downloading
Jack Christensen's v1.6.3 branch into the
arduino1.6.9/hardware/folder.
Nice to see a font size adjustment under File:Preferences too.
Took me a while to find this bookmark, hid it on myself:
Looks Bobuino pinout is supported as well for those that have purchased one of my Bobuino boards in it's different form factors (gotta thank LarryD for coining that name!) Some examples:
http://www.crossroadsfencing.com/BobuinoRev17/
or
or
MightyCore looks to make it easier to select the clock speed, brownout level, and board type too.
Haven't done much but get it loaded so far, looking forward to trying 1.6.9 out.
My most recent 1284P sketch using both serial ports to talk to USB and a GSM/GPS module, and SPI to control shift registers (to control transistors) and read temps from MAX31865 RTD chips still compiles ok, so that's a good sign ...
CrossRoads:
My most recent 1284P sketch using both serial ports to talk to USB and a GSM/GPS module, and SPI to control shift registers (to control transistors) and read temps from MAX31865 RTD chips still compiles ok, so that's a good sign ...
Yes, that is a good sign. Thanks for sharing your experience, I am a big fan of the 1284 uC (have a few of your Bob's too) but have been off playing in 32-bit land for a while. Will eventually work my way back to these 8-bit workhorses!
Ray
Stay tuned! Implementation of Majek's modified Optiboot bootloader are in the works! It's still less than 512/1024 bytes, and allow the microcontroller to write to its own flash. Interesting feature, huh? 
Could be. 1284 has tons of room already, never had a space problem.
Anyone seeing a problem with software reset not working in 1.6.9?
I have code that does the assembler reset, works in 1.0.6, not in 1.6.9. I use it because I have a DF Robot GSM/GPS card that boots up sometimes with incorrect responses to AT, comes back with "Normal Power Down" or a responds with "yyyy" with umlaut over them, only way to recover seems to be to reset the code. (which you wouldn't think would reset the GPS/GSM card, yet seems to solve the problem).
With 1.6.9, the software reset just hangs the 1284. With 1.0.6, everything restarts as expected.
Serial.println("resetting...");
asm volatile ("jmp 0");
while(1);
Now that I think about it, I don't recall seeing "resetting" in the Serial Monitor, so maybe it's something else.
It definitely hangs in 1.6.9 tho.
// check incoming messages
//NORMAL POWER DOWN - 17 - need a reset if get this
//
//RDY
//+CFUN: 1 - 8
//+CPIN: READY - 12
//+PACSP: 1 - 9
//Call Ready - 10
//GPS Ready - 9 - these two may be swapped
delay(500);
Serial.println("");
Serial.print ("Starting GPS/GSM 'warmup' delay");
Serial.print(" ");
for (x=1; x<=12; x=x+1){
Serial.print (x);
delay(1000);
}
//
// losing some data during the delay?
//
Serial.println("");
Serial.println ("GPS ready for AT?");
y =0;
for (x=0; x<64; x=x+1){
inGPS = Serial1.read();
// 13, 10, 32 ignore CR, LF, Space
if ((inGPS !=13) && (inGPS !=10) && (inGPS !=32)){
dataGPS[y] = inGPS;
y=y+1;
}
}
Serial.print ("received: ");
for (x=0; x<50; x=x+1){
Serial.print (dataGPS[x]);
}
Serial.println("");
Serial.println("");
// FIXed THIS? - waSN'T CATCHing NORMAL POWER DOWN as a failure mode. The R passes the current test. Added check for not-N at the start
if((((dataGPS[0] == 'R') || (dataGPS[0] == '+')) ||((dataGPS[1] == 'R') || (dataGPS[1] == '+')) || ((dataGPS[2] == 'R') || (dataGPS[2] == '+'))) && (dataGPS[0]!='N') ){
Serial.println("yes - sending AT");
Serial1.write((uint8_t*)at,strlen(at));
Serial.print("received: ");
y = 0;
delay(2000);
while (Serial1.available()>0){
inGPS = Serial1.read();
// 13, 10, 32 ignore CR, LF, Space
if ((inGPS !=13) && (inGPS !=10) && (inGPS !=32)){
dataGPS[y] = inGPS;
y=y+1;
}
}
// print response
for (x=0; x<4; x=x+1){
Serial.print (dataGPS[x]);
}
Serial.println("");
Serial.println("");
Serial.println("sending at+cgpspwr=1");
Serial1.write((uint8_t*)cgpspwr, strlen(cgpspwr));
y = 0;
delay(2000);
while (Serial1.available()>0){
inGPS = Serial1.read();
// 13, 10, 32 ignore CR, LF, Space
if ((inGPS !=13) && (inGPS !=10) && (inGPS !=32)){
dataGPS[y] = inGPS;
y=y+1;
}
}
// print response
Serial.print("received: ");
for (x=0; x<14; x=x+1){
Serial.print (dataGPS[x]);
}
Serial.println("");
Serial.println("");
Serial.println("sending at+cgpsrst=1");
Serial1.write((uint8_t*)cgpsrst, strlen(cgpsrst));
y = 0;
delay(2000);
while (Serial1.available()>0){
inGPS = Serial1.read();
// 13, 10, 32 ignore CR, LF, Space
if ((inGPS !=13) && (inGPS !=10) && (inGPS !=32)){
dataGPS[y] = inGPS;
y=y+1;
}
}
// print response
Serial.print("received: ");
for (x=0; x<14; x=x+1){
Serial.print (dataGPS[x]);
}
Serial.println("");
}
else{
Serial.println("resetting...");
asm volatile ("jmp 0");
while(1);
}
The code is looking for a couple of things:
R (implies RDY received)
- (implies +CFUN received)
yR (implies RDY received) (y is the y umlaut character)
y+ (implies +CFUN received)
yyR (implies RDY received), but not NOR
yy+ (implies +CFUN received)
My testing/monitoring shows these 6 will allow normal commands to be sent, anything else comm's are either hosed, or the device is going into some power down mode. The Reset in 1.0.6 works to recover comm's usually with the next set of messages, sometimes two. With 1.6.9, there is no recovery, the code just stops outputting stuff with
"received: NORMA" if I recall correctly. I'll have to enumerate the "received"s a little more so I can tell which one is sending that out, maybe it's hanging sooner than I thought.
This is the card, the browser I'm on right now won't open any further for me unfortunately. There's links to a Wiki page with some sample code that stinks for this SIM908 module that combines GPS and GSM for location info and texting. I use the 1284P's Serial1 port to talk to it, and Serial to talk to the PC for debugging (on a custom card).
Hmm, reads like I'm hijacking my own topic, doesn't it!
I had problems with asm("jmp 0") too (1.6.5 IDE)
I don't think you can count on it being safe (ie, not leaving shit in the cpu registers that would break assumptions about the startup state of said registers - plus ofc leaving things in the hardware registers, which could cause unexpected behavior). I put a bunch of effort into this, and eventually said fuck this and used the watchdog, which works right every time.
If you write to serial, and immediately try to reset the board, you may not get any output, depending on what the code that you've jumped to does to it, since writing to serial under the default core is non-blocking, if you get it into a bad enough state before it's finished outputting what you told it to, you can lose the output.
The sequence is: after power up, 12 seconds elapse (by experimenting it seems to take that long for the module to 'boot up' or whatever it does), I watch for its post boot-up message, if it looks ok I send it an AT and continue.
When it doesn't look normal (anything other then RDY or the +CFUN message, or those two proceeded by y or yy) then the software reset seems to work. Another 12 seconds elapses, and it talks normally.
With 1.6.9, I can't seem to reset tho. I'm not even writing to serial1 yet at that point, just receiving.
I have a test program that I can manually enter commands, I'll try that again when I get home and see if just waiting another 12 seconds does anything in 1.6.9.
If you are using Optiboot and you jump to the booloader address you will get a mcu (watchdog) reset.
asm ("jmp 0x7e00"); // m328p Uno
Should work for the 1284p, with the correct address.
Thanks, I can give that a try too. Probably tomorrow, I get home later after golf on Tuesdays.
Note to self:
Size, start address, BootSize bits
256 words = 3F00 BOOTSIZE1/0 =11
512 words = 3E00 BOOTSIZE1/0 =10
1024 words = 3C00 BOOTSIZE1/0 =01
2048 words = 3800 BOOTSIZE1/0 =00
Bits 2, 1 of High Fuse Byte
(offtopic: have been thinking of simple golf score tracker, button to press on each stroke an update running total, button to change briefly to show running total, button to reset hole score. Auto sleep after a couple seconds of showing hole or total, press any button to wake up. Stupid really, I think of things like that when I get bored. Not too keen on GPS devices that show hole layout and have score capability for 4 built in, don't want to take my reading glasses when I'm golfing just to see a little screen that I have to remember to recharge. Paper score card works well, I can add notes about a particularly bad shot or something, or 'chart' my fairway drives, greens in regulation, how many putts, whatever I feel like that day. No recharging needed.)
If I were going to do that type of jump to zero kludge, I'd mask interrupts before doing the jump to zero.
But why bother trying to do a soft "reset" using a kludge that doesn't really reset anything and is prone to problems when it is so easy to use the watchdog timeout and do it correctly?
/*
* Function to cause the AVR to reset
*/
#include <avr/wdt.h>
void resetArduino()
{
noInterrupts();
wdt_enable(WDTO_15MS);
while(1); // wait to die and be reborn....
}
--- bill
Im using the same core, but the problem is with Interrupts only when I use it in conjunction with the Adafruit nrf8001 library here GitHub - adafruit/Adafruit_nRF8001: Drivers for Adafruit's nRF8001 Bluetooth Low Energy Breakout
using standard pinout.
I thought I would follow your lead and try 1.69
I got the file GitHub - maniacbug/mighty-1284p: Mighty 1284P Platform for Arduino
I unzipped mighty-1284p files to:
C:\Users\LarryD\Documents\Arduino\hardware\mighty-1284p
See image attached image
IDE was restarted.
I got things installed but I do not get 1284 as an option under boards
Did I miss a step?
The maniacbug core is super outdated and doesn't work with Arduino IDE 1.5 and greater. Use GitHub - MCUdude/MightyCore: Arduino hardware package for ATmega1284, ATmega644, ATmega324, ATmega324PB, ATmega164, ATmega32, ATmega16 and ATmega8535 or GitHub - JChristensen/mighty-1284p at v1.6.3 instead.
Thank you pert!
Got things working now.
Thanks Bill, haven't checked this in a while, will give that a try.
Jump to 0 has been working okay so far in 1.0.6 where I do my '1284P programming.