Advanced programming question

More
6 months 1 week ago #12526 by Ty_Eeberfest
Here are a couple things you may already know. If nothing else they might be useful to somebody reading this thread months from now...

1) When you program an Atmega chip using an ICSP device, the Arduino bootloader is not programmed on the chip and any existing bootloader is deleted. That's fine - if you're using an ICSP you do not need a bootloader. However, if you later want to use the chip in an Arduino and program it using the Arduino-esque USB method, you need to put a bootloader back on the chip. With your ICSP connected to the chip, just do Tools -> Burn Bootloader in Arduino IDE and you're good to go.

2) Virgin Atmega chips come with the fuses set such that it uses the on-chip 8MHz system clock instead an external crystal. Since Arduinos (and Ian's clock boards) include a 16MHz crystal the fuses need to be set to make use of it. I use the following command line, with the ICSP connected, to set my fuses:
avrdude -v -c avrispmkII -p m328p -P usb -b 19200 -U lfuse:w:0xFF:m -U hfuse:w:0xDE:m -U efuse:w:0x05:m

That works most of the time but if you keep getting "Yikes! Bad device signature" errors from avrdude try putting " -B 4 " (no quotes) right after -v in the command line.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
6 months 1 week ago #12527 by Ty_Eeberfest
Tim,
I'm curious about what you're adding or changing in the firmware, if you don't mind my asking.

Ian,
The AVRISP seemed expensive at the time I got it but I've never regretted it. It does what it's supposed to very consistently. It has two bi-color LEDs, one on the USB side and one on the ICSP side. The one on the USB side isn't terribly useful: it just lights up to tell you it's connected to USB, flickers to show data transmission and turns red if it receives something it doesn't understand. The one on the ICSP side is green for go, solid red if the chip loses power and blinking red if connected wrong.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
5 months 3 weeks ago #12554 by tgibbs99
Ty,
You asked about firmware changes. Just a few small adjustments, changing the default choice for MM-DD-YY, backlight option, etc. Also changed the default time provider.

A couple of things may be of interest.
in the Firmware Firmware V2 Classic Rev6 Code, V356,

Function
// ************************************************************
// Set the seconds tick led(s) and the back lights
// ************************************************************
void setLeds()

Changed: (at about line 987)

// Tick led output
analogWrite(tickLed, getLEDAdjusted(255, pwmFactor, dimFactor));

to:

// Tick led output
//flash the separators once per second
if (secsDelta <50 || secsDelta > 950) {
analogWrite(tickLed, 175);
} else {
analogWrite(tickLed, 0);
}
//analogWrite(tickLed, getLEDAdjusted(255, pwmFactor, dimFactor));

This gives a nice bright flash at the top of each second, then the tick neons go blank. It appears to the eye as if the ticks flash, and then the numbers change.

Directly after those lines I added:

// ************************************************************
// change backlight options per every six seconds
// ************************************************************
if ((second() >= 0) && (second() < 6)){
backlightMode = BACKLIGHT_FIXED;
markersecond9 = true;
if (markersecond0) {
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond0 = false;
}
}
if ((second() >= 7) && (second() < 12)){
backlightMode = BACKLIGHT_PULSE;
markersecond0 = true;
if (markersecond1){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond1 = false;
}
}
if ((second() >= 13) && (second() < 18)){
backlightMode = BACKLIGHT_CYCLE;
markersecond1 = true;
if (markersecond2){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond2 = false;
}
}
if ((second() >= 19) && (second() < 24)){
backlightMode = BACKLIGHT_COLOUR_TIME;
markersecond2 = true;
if (markersecond3){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond3 = false;
}
}
if ((second() >= 25) && (second() < 30)){
backlightMode = BACKLIGHT_FIXED_DIM;
markersecond3 = true;
if (markersecond4){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond4 = false;
}
}
if ((second() >= 31) && (second() < 36)){
backlightMode = BACKLIGHT_PULSE_DIM;
markersecond4 = true;
if (markersecond5){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond5 = false;
}
}
if ((second() >= 37) && (second() < 42)){
backlightMode = BACKLIGHT_CYCLE_DIM;
markersecond5 = true;
if (markersecond6){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond6 = false;
}
}
if ((second() >= 43) && (second() < 48)){
backlightMode = BACKLIGHT_COLOUR_TIME_DIM;
markersecond6 = true;
if (markersecond7){
markersecond7 = false;
}
}
if ((second() >= 49) && (second() < 54)){
backlightMode = BACKLIGHT_CYCLE;
markersecond7 = true;
if (markersecond8){
markersecond8 = false;
}
}
if ((second() >= 55) && (second() < 60)){
backlightMode = BACKLIGHT_FIXED;
markersecond8 = true;
if (markersecond9){
redCnl=random(5, 15);
grnCnl=random(5, 15);
bluCnl=random(5, 15);
markersecond9 = false;
}
}

These variables must be declared:

bool markersecond0 = true;
bool markersecond1 = true;
bool markersecond2 = true;
bool markersecond3 = true;
bool markersecond4 = true;
bool markersecond5 = true;
bool markersecond6 = true;
bool markersecond7 = true;
bool markersecond8 = true;
bool markersecond9 = true;
bool colourmarker = true;
bool colourmarkerd = true;

This causes the back light option to change behavior every six seconds, and makes for a very jumpy clock. However, I think this may be useful for demonstration purposes.

Finally, I was getting the decimal point at the 10's minutes position lighting up.

In this section: // ************************************************************
// Check the PIR status. If we don't have a PIR installed, we
// don't want to respect the pin value, because it would defeat
// normal day blanking. The first time the PIR takes the pin low
// we mark that we have a PIR and we should start to respect
// the sensor.
// Returns true if PIR sensor is installed and we are blanked
// ************************************************************
boolean checkPIR(unsigned long nowMillis) {
boolean pirvalue = (digitalRead(pirPin) == HIGH);

boolean useDPs = (dpEnable == DP_ENABLE_ALL);
dpArray[5] = pirvalue && useDPs;

if (pirvalue) {
pirLastSeen = nowMillis;
return false;
} else {
if (nowMillis > (pirLastSeen + (pirTimeout * 1000))) {
dpArray[5] = false;
return true;
} else {
dpArray[5] = true && useDPs;
return false;
}
}
}

The last [5] references had been [4] in the most recent firmware. Was that a typo?

Anyway, thanks for all your help.

Tim

Please Log in or Create an account to join the conversation.

More
5 months 3 weeks ago #12555 by Ty_Eeberfest
Thanks for the detailed answer Tim. I think it's interesting you wanted to alter the decimal and separator LEDs operation because those are the same things I alter in my own clocks. I'm not a fan of the throbbing separators (neon in my clocks) so I reprogrammed them to "step" back and forth between full intensity and roughly half intensity when the seconds change. The decimals I just disabled completely. To me the decimals are useless and distracting unless I'm having to troubleshoot a PIR (which I can troubleshoot just fine with a meter).

I'm not really into LED backlighting so I either turn them all the way off or set them to a constant color at low brightness.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
4 months 3 days ago #12619 by meq123

tgibbs99 wrote: This gives a nice bright flash at the top of each second, then the tick neons go blank. It appears to the eye as if the ticks flash, and then the numbers change.


Thanks for this, I don't particularly like the 'breathing' tick neons either, so I bookmarked this post in case I ever got to reprogram the MCU.

When I actually did get to that point, I'd noticed and liked the way the ticks work when in factory reset mode, where they light brightly at the top of the second, then dim out - kind of a sawtooth wave effect. On looking through the code for that 'special' treatment to copy into the setLeds function, I realised it was simply serendipity! The 'breathing' is caused by the upOrDown getting toggled each second. In the reset mode that toggling does not happen, hence the 'always down' effect. The change is simple, just comment out the upOrDown toggle line (I forced it to false anyway, but not really necessary). Hope this helps someone else coming across this. Somewhere around line 923:
  // Change the direction of the pulse
  //upOrDown = !upOrDown;
  upOrDown = false;	// change to always go down

Please Log in or Create an account to join the conversation.

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.100 seconds
Go to top
JSN Boot template designed by JoomlaShine.com