My Hackable Badge
Rsadeika
Posts: 3,837
in Propeller 1
So, I went ahead and ordered a couple of Badges, hopefully I will get them sometime next week. In the mean time, I decided my first "hack" would be a time piece.
Since I will be working with C code, Thanks Andy, I am going to try implementing the softRTC program on the Badge. When I was thinking about this, I was trying to figure out, how am I going too set the clock, when the program is running on the Badge. I guess the program will have to have a UI that is available when you plug in the USB cable and then you can run a setclock function from a terminal program, I guess. I will be trying to set this up where the softRTC is running in its own COG(background job), and it just updates the OLED, on the bottom line , a date and time.
Now, if the above works, it would be nice to have a setting, or a button to push, to display an analog clock, very crude version of course, using all the OLED space available for that. Then of course, you could hit a button and get it back to a digital display. I am just wondering why Parallax did not put an RTC chip on the Badge? When some people, maybe somebody like myself, after they have gotten bored, they could always use the Badge like a clock. No, Parallax should not get into making digital watches.
The one thing that I have not seen mentioned, is the battery capability, how long do you have, before you have to charge the battery? I am thinking with the clock hack, if I let the program run all the time, what would be a good guess as to how long you would have before you would have to plug in for a charge. I guess the other question would be, when you do plug in, is the charging a separate event, meaning you can still program the Badge while it is charging.
Their was some mention that the Badge could be used for passing messages between Badges, or something like that, is there any C code for that functionality, or this a "hack" that has to be done? Thinking about another hack, the QS HIB has an IR setup, is there any C code available for using that? Here is a way out thought, the QS+HIB is setup like a little server that talks to the Badge, a client, using the IR. I better stop now before I go into SciFi mode and dream up some things that only looks believable on a TV program.
Ray
Since I will be working with C code, Thanks Andy, I am going to try implementing the softRTC program on the Badge. When I was thinking about this, I was trying to figure out, how am I going too set the clock, when the program is running on the Badge. I guess the program will have to have a UI that is available when you plug in the USB cable and then you can run a setclock function from a terminal program, I guess. I will be trying to set this up where the softRTC is running in its own COG(background job), and it just updates the OLED, on the bottom line , a date and time.
Now, if the above works, it would be nice to have a setting, or a button to push, to display an analog clock, very crude version of course, using all the OLED space available for that. Then of course, you could hit a button and get it back to a digital display. I am just wondering why Parallax did not put an RTC chip on the Badge? When some people, maybe somebody like myself, after they have gotten bored, they could always use the Badge like a clock. No, Parallax should not get into making digital watches.
The one thing that I have not seen mentioned, is the battery capability, how long do you have, before you have to charge the battery? I am thinking with the clock hack, if I let the program run all the time, what would be a good guess as to how long you would have before you would have to plug in for a charge. I guess the other question would be, when you do plug in, is the charging a separate event, meaning you can still program the Badge while it is charging.
Their was some mention that the Badge could be used for passing messages between Badges, or something like that, is there any C code for that functionality, or this a "hack" that has to be done? Thinking about another hack, the QS HIB has an IR setup, is there any C code available for using that? Here is a way out thought, the QS+HIB is setup like a little server that talks to the Badge, a client, using the IR. I better stop now before I go into SciFi mode and dream up some things that only looks believable on a TV program.
Ray
Comments
Running the demo code (which has the leds all flashing and the oled display running constantly), the battery life was 14-18 hours. I'm certain you can find ways to increase that significantly by only displaying stuff on the oled when the accelerometer detects motion, or perhaps just displaying the time for 10 seconds every minute. Lot's of possibilities!
The Propeller could also be "sleeping" most the time too, perhaps just waking up on an input from the accelerometer interrupt.
Regarding power.... You can connect to USB and power/program the badge, and at the same time the on-board charge management will also charge the battery if needed (so YES to your question
You can also plug in one of those usb-boost chargers if you want a portable solution to providing 5V to the badge (perhaps to run servos). The left hand prototype area has USB-5V power when available, and the right-hand prototype area has 3.3V from the onboard regulator and Li-ion battery.
The badge has IR transmitter and receiver built in. You should find sample code at: www.parallax.com/badge
The demo software uses those for sharing contact info between badges!
Hope that all helps a bit. Happy Hacking !!
Since I mentioned that I am going to setup a UI, so I can run a setclock() function, and use it through a terminal program, can I just use the print() function and have the stuff appear on the terminal screen? Or do I have to call out the fdserial setup and do it that way.
Ray
As for the touch button design for entering some values to the setclock fuction, if you had another six buttons on the badge, then maybe it would be a little less cumbersome(0-9 buttons+ function button(s)). For that matter, with the extra keys you could have a very very basic calculator.
Since I have a general outline for the digital clock, how about a battery gauge. I noticed in the Badge .pdf a reference to RCTime, how does that work, I did not see any C code examples for that. Since there is an RGB LED Module available, could that be tied to the RCTime to provide a visual battery gauge? G - full, Y - medium, R - time to charge, visual power gauge. Just a few things to think about, hopefully my Badges will show up very soon.
I am getting a Staff and a Guest Badge, I am thinking maybe the Staff badge will be like the server and the Guest Badge a client. I wonder if I do a clock setting on the Staff Badge and then I could have it set the clock on the Guest Badge(s), using the IR functionality. For that matter, how about having a QS+HIB setup with a "master clock", and that setups the Badges using the IR functionality. Now I thinking about IR C code for the QS+HIB, anything available?
Ray
The reason badge_setup is in badgealpha.c is because I haven’t finished updating the filenames. It’s on the to-do list in the API docs. If I remember correctly, the time and softrtc libraries around took 2/3 of CMM program memory just to set and display. Have you considered using something more compact? If I were using buttons to set the badge’s time, I would probably use the P16 and P26 to shift left and right between digits and P27, P25 for adjusting digit values up and down. Yes, lots of possibilities with IR. There are examples of IR transmit/receive for contacts in folder 6. Here is an example that you could try for measuring battery charge. I would expect the t = value should decay with battery voltage. [edit] After a little testing, it appears to be the reverse, longer decay times -> lower battery voltage. [/edit] The value does seem to vary with different batteries, but I have not yet tested it as the battery loses its charge.
#include "simpletools.h" #include "badgetools.h" void main() { badge_setup(); int t; text_size(SMALL); while(1) { low(0); pause(1); t = rc_time(0, 0); //print("t = %d\n", t); cursor(3, 3); oledprint("t = %05d", t); pause(1000); } }- Andy
The first will be a UI system, that means plug in your USB cable, and, in a terminal program, do some initial settings, like respond to the first command available, 'whoami'. The expected response would be a name that you want displayed on the OLED top line.
Next will be the softRTC, again, using the UI, you will respond to the 'setclock' command. I think that, for now, the bottom line on the OLED should be fine. The digital read out will be the Date and Time(24 hour), updated every minute.
Then I will try to implement a battery gauge using the RGB LED to give a visual of the status of the battery state. This way you will not have to keep guessing as to when it is time to charge the battery, I hope.
After these items are working as expected, then I can see how much RAM memory I have left, maybe consolidate the code wherever possible and then move on to the next item, which would probably be the use of the IR system. I think I have the order in the correct sequence?
Ray
Sounds good. Make sure to try the 44 badge examples in the 20000-Badge-Propeller-C-Examples-Library-150918 folder you downloaded and unzipped to get comfortable with programming the badge.
I tried the timekeeping libraries you've been using last week and ran out of memory. So, I started writing something more compact (attached) with a manual Spin to C translation of Bob Belleville's date_time_ts.spin from Obex. It definitely takes less space, but still needs some more testing and also some functions for storing and retrieving the single int time value (vs. the datetime struct), which will be better for passing to/from EEPROM.
I'll be back in the office Thursday if you need help modifying it to suit your needs. In the meantime, there are a couple examples in the attached zip that show how to use it, and will hopefully give you a running start on your development sequence.
Andy
Maybe Parallax should add FedEx as a delivery choice, in my area I think UPS is going from acceptable to bad. I guess sometime yesterday the package got delivered. This morning I found the box leaning against the wall by the garage doors on the driveway, what's next, the UPS driver just throwing the box on to the end of the driveway when they drive by. I think FedEx still takes the package up to your front door and rings the door bell.
Now the badge(s), on the badge itself, covering the actual OLED, is a beige(?) colored shield, does this get pried off, or does it stay on? I tried the "hello" example, and viewing it through the shield is an interesting experience, or maybe my eyeballs are worst off than I thought. So, do I pry it off or leave it on?
I think a note should be made that the USB connector on the Badge is a little different than the ones for the QS and Activity boards, so you cannot just pull the cable off of your Activity Board and plug it into the Badge. I am glad I ordered some cables with the package, now I know these cables will not fit the QS and Activity Boards, at least not a loose fit :-).
I will try some of the examples with the OLED shield in place, maybe with time the viewing experience gets better, but I am not sure. Once I settle down, I will try some other stuff, and go from there.
Ray
That brown paper is just a protective cover. Peal it off, and you get a nice, clear, plastic window.
Interesting, when I first looked at the shield, it does not look like the "brown paper" could be peeled off. In fact when I ran my finger around the edge of the plastic, I could not get any of the paper edge to come up. I had to use a sharp knife on the very corner of the plastic edge to loosen up some paper so you could get a hold of to peel it off, once I was informed that it had a "brown paper" covering.
Now about that blue LED by the power circuit, when it is flashing, it is doing what? The other thing that I noticed is that their is no indication as to when the Badge is on or off. At first, when I plugged the cable in, and tried too run a program, an error came up, could not find the Propeller. After pulling the cable in and out a few times, and thinking that I got a bad Badge, I did try the on/off switch, I guess that did the trick. It is almost like a guessing game, you hit the switch, is the Badge on or off.
I guess the sequence is, once you burn the program to the EEPROM, pull the plug, and it just runs until you hit the switch to turn it off. My personal preference would be to have an LED giving me a visual as to whether the Badge is on or off, maybe I am missing something, or is that where the hackable part comes in to play.
Ray
Did you find the pdf badge user guide at the badge page at the Parallax store? That might help explain a few things like usb and the on.off, and save you a bit of time and frustration?
Looking forward to seeing what you create.
Yes it is a little confusing on the Power On/Off thing. You have to remember what program you had loaded last. I had a program just to run the Video out to a Composite monitor. Well, I unplugged the monitor and powered up the badge a couple of days later, and I also though I had a bad Badge. Just connect the USB cable, and try to identify in the PropTool. If it can't be found, hit the power switch and try again.
RE: Blue LED. I don't think it should be flashing. On my two Badges, it's either on or off. On=Charging, Off=Charged. You may want to check that the battery polarity is correct. Does the LED ever go off?
RE: Blue LED. When I first plugged the Badge in, it started out with a flashing LED, then after a while it went to a solid ON, now it is off. Now, that the Badge looks like it is lifeless, it is a 50/50 chance that it is On or Off.
As to the power save issue, maybe a little larger battery capacity size would be in order, unless there are some other unforeseen issues with that compromise.
I am really trying to be nice about my First impression, but I have to describe, honestly, what I am experiencing. Also, I am using, that forgotten program, SimpleIDE, exclusively. PropGCC all the way.
Ray
The battery size is always a compromise between size, cost, safety, availability, need, etc...
One source of confusion might be that the cells used are often sold in larger capacity versions.... But really they are all max 800mAh! Anything more, like 2000mAh, is marketing. You can buy and try up to a 2600mAh cell in the same package size and do some measurements for your own app.
On/off... If the badge seems off, then just switch on. This is one of those personal choices where we probably won't please everyone- but you can solder a resistor and led from the 3.3v on the right protoarea. The benefit of hackable design, so you can tailor to suit your dreams!
Ref. Your points on the guide, I will include them for future docs revision. Always great to get notes on first reactions to see where things can improve.
Ray
/* stbadge.c September 30, 2015 Staff Hackable Badge */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" char screenName[] = "Ray"; /* You need all y mo d h m s */ datetime dts = {2015, 9, 30, 15, 49, 30}; /* This is not valid 0, 0, 0, 15, 49, 30 I guess it can not have NULL or 0 values. */ datetime dta, dtt; void Get_time(); int main() { // Add startup code here. badge_setup(); // Setup the badge. dt_start(&dts); // Start the date time. text_size(LARGE); oledprint("%s\n",screenName); cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); pause(100); cog_run(Get_time,32); while(1) { // Add main loop code here. //Get_time(); pause(500); } } void Get_time() { while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); } }I am using P27 LED and button for displaying some general badge state information. It uses the bottom two lines on the OLED screen. Speaking of the OLED screen, since we have a LARGE and SMALL selection, it would be nice to have a MEDIUM selection, I would think.
The battery gauge is still a crude function. It is displaying a number and using the G RGB, but I will try to correlate the numbers to an appropriate color, as in G Y R colors for battery state. It would be nice to know how the numbers are related to the battery state. I am being shown 01442 at the moment, so should I assume that something like 01000 or less trigger a Y RGB, and 00900 or less trigger an R RGB, time to charge up?
A non cumbersome solution for the time clock part is still very vague in my brain if non existing. I was trying to get the time to display on the bottom line, constant update, but was not successful. I am thinking, if I can get the time displayed on the bottom line, all the time, then when I press P27 I can have the date displayed, for a short time, along with a battery state visual.
I think I will have to implement the QS+HIB with a master clock, maybe that way I can get the clock info onto the badge using the IR functionality. And then when the badge gets loaded up with data, via the IR, it would be nice to offload that data to the QS+HIB, and maybe have it stored on the SD card. For that matter how about having a Propeller RPi HAT with its own IR equipment, and have that as a functional server for working with the Badges? Just some crazy ideas at the moment.
Ray
/* stbadge.c September 30, 2015 Staff Hackable Badge October 1, 2015 - testing out button press, battery gauge, and time clock. */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" char screenName[] = "Ray"; /* Still need to figure out this correct timedate auto entry method. You need all, y mo d h m s */ datetime dts = {2015, 9, 30, 15, 49, 30}; /* This is not valid 0, 0, 0, 15, 49, 30 I guess it can not have NULL or 0 values. */ datetime dta, dtt; int states; void Get_time(); void Get_bgauge(); int main() { // Add startup code here. input(6),high(7),low(8); //LED P27 always on, a visual for badge state. badge_setup(); // Setup the badge. dt_start(&dts); // Start the date time. int t; // Battery gauge text_size(LARGE); oledprint("%s\n",screenName); cursor(0,7); text_size(SMALL); // This size will remain until altered. oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); pause(100); low(0); // Battery gauge pause(1); // Battery gauge t = rc_time(0,0); // Battery gauge cursor(0,6); // Battery gauge oledprint("t = %05d", t); // Battery gauge rgb(R,GREEN); // Battery gauge pause(3000); rgb(R,OFF); //cog_run(Get_time,32); while(1) { // Add main loop code here. //Get_time(); while(!buttons()) { while((states = buttons()) == 0); // Wait for button press. switch(states) { case 0b0000001: // Button P27 Get_time(); // Run the clock? pause(100); Get_bgauge(); // Run the battery gauge. continue; default: continue; } if(states == 0b0000100) continue; // Button release? } //pause(500); } } void Get_time() { // while(1) // { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); //pause(200); // } } void Get_bgauge() { int t; low(0); // Battery gauge pause(1); // Battery gauge t = rc_time(0,0); // Battery gauge cursor(0,6); // Battery gauge oledprint("t = %05d", t); // Battery gauge rgb(R,GREEN); // Battery gauge pause(3000); cursor(0,6); oledprint(" "); // Blank line rgb(R,OFF); cursor(0,7); oledprint(" "); // Blank line /* At this point bottom of screen is blank. */ }BTW, back when you tried http://learn.parallax.com/multicore-approaches, it probably declared smaller stack sizes. Since then, we updated all of them to 128 (x int, that's 512 bytes) for prototyping's sake. We also have Cog Stack Usage Test.side in Documents\SimpleIDE\Learn\Examples\Multicore\, for when you are ready to trim and conserve memory.
Ray
void Get_time() { while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(9,7); text_size(SMALL); oledprint("%02d/%02d/%02d",dts.y, dts.mo, dts.d); } }oledprint("%02d/%02d/%02d", dts.y % 100, dts.mo, dts.d);That's the modulus (remainder of dts.y divided by 100), which returns a value from 0 to 99. The result of 2015 % 100 is 15, so mission accomplished.Andy
Since I added code to seed the time clock too 00:00:00, theoretically when the battery goes to a Y and R state, I should have time elapsed values for both conditions. I am not sure if this will provide any useful information, other than showing that my 'if loop' is working correctly.
Since the Badge will be on battery power alone, most of the time, it would be nice to have some sort of indication as to when it is absolute necessary to turn the badge off and plug it in to be recharged, before you start wrecking your battery. I am not sure how to correlate the RTC values to the actual battery voltage conditions, if somebody knows, please enlighten me.
Now I will proceed with my tests...
Ray
/* stbadge.c September 30, 2015 Staff Hackable Badge P27 button and LED shows badge current status. October 1, 2015 - Testing out button press, battery gauge, and time clock. October 2, 2015 - Still no enter real values for timeclock, timeclock runs continuously on line 8, added low battery state to timeclock COG, added temp data log of battery state. */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" char screenName[] = "Ray"; /* Still need to figure out this correct timedate auto entry method. You need all, y mo d h m s */ datetime dts = {2000, 1, 1, 0, 0, 0}; // seed value. /* This is not valid 0, 0, 0, 15, 49, 30 I guess it can not have NULL or 0 values for the date portion. */ datetime dta, dtt; int states; void Get_time(); //void Get_date(); void Get_bgauge(); int main() { // Add startup code here. input(6),high(7),low(8); //LED P27 always on, a visual for badge state. badge_setup(); // Setup the badge. dt_start(&dts); // Start the date time. int t; // Battery gauge text_size(LARGE); oledprint("%s\n",screenName); cursor(0,7); text_size(SMALL); // This size will remain until altered. oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); pause(100); low(0); // Battery gauge pause(1); // Battery gauge t = rc_time(0,0); // Battery gauge cursor(0,6); // Battery gauge oledprint("t = %05d", t); // Battery gauge if(t > 01400) rgb(R,GREEN); // Battery gauge else if(t <= 01400 || t >= 01300) rgb(R,YELLOW); //Battery gauge //else if(t >= 01300) rgb(R,YELLOW); else { rgb(R,RED); } pause(3000); cursor(0,6); oledprint(" "); // Blank line rgb(R,OFF); cog_run(Get_time,128); // Runs time on last line continuously. while(1) { // Add main loop code here. while(!buttons()) { while((states = buttons()) == 0); // Wait for button press. switch(states) { case 0b0000001: // Button P27 //Get_date(); pause(100); Get_bgauge(); // Run the battery gauge. continue; default: continue; } if(states == 0b0000100) continue; // Button release? } //pause(500); } } /* Runs in seperate COG. */ void Get_time() { int t; while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,7); /* month day year, last two digits */ oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100); /* Check the battery state. */ low(0); // Battery gauge pause(1); // Battery gauge t = rc_time(0,0); // Battery gauge if(t <= 01300) { rgb(R,RED); // Battery gauge cursor(0,6); // Battery gauge oledprint("t = %05d", t); // Battery gauge read out. } /* Temp data log of battery state when run on battery alone.*/ if(t <= 01400) { cursor(0,4); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,4); oledprint("Y state"); } if(t <= 01300) { cursor(0,5); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,5); oledprint("R state"); } } } /*void Get_date() { cursor(10,7); text_size(SMALL); oledprint("%02d/%02d/%02d",dts.y, dts.mo, dts.d); } */ void Get_bgauge() { int t; low(0); // Battery gauge pause(1); // Battery gauge t = rc_time(0,0); // Battery gauge cursor(0,6); // Battery gauge oledprint("t = %05d", t); // Battery gauge read out if(t > 01400) rgb(R,GREEN); // Battery gauge else if(t <= 01400 || t >= 01300) rgb(R,YELLOW); //Battery gauge else { rgb(R,RED); // t value is < 01300. } pause(3000); cursor(0,6); oledprint(" "); // Blank line rgb(R,OFF); }The really strange part is that when I had it plugged in with the USB, and was running the program in RAM, the highest RTC reading I ever saw was 01474 and it would go down fairly quickly, to lets say, the 01424 mark. And then at some point the blue LED associated with the charging circuit would go on.
Now I am really scratching my head trying to figure out what the heck is going on here, help!
Ray
I posted a correction yesterday that I expected the numbers to go up as the battery decays. It's right above your most recent code post. The measurement starts by emptying the capacitor (to 0 V). Then, rc_time allows the battery to charge it to the 1.6 V Propeller logic threshold. It will do so more slowly with lower battery voltage.
Andy
The other problem that I am noticing is that when I run RCT function in a COG, the t values that I get there are quite a bit different than the t values I get when I run RCT in main(). The values were something like 00910 in the COG and the main() value was 01446. I increased the stack value to 256, did not help.
As a diversion I did a quick visual on the RGB colors, the RED, GREEN, and BLUE look good. But some of the other colors, like YELLOW look more like an off GREEN color. Is it my eyeballs, or is that the best the RGB LED can do? Also when those RGB LEDs are on, boy do they suck the juice from the battery. Will have to use those very carefully, when the Badge is on battery power.
Ray
Using your 1435 for 4.17 V, we'd have:
Vbat = 1.6 / (1 - e^(-1435u/360k*0.01u))
= 1.6 / (1 - e^(-1.435m/3.6m))
= 1.6 / (1 - e^(-1.435/3.6))
= 4.8 V
Hmm, seems a little high. If the logic threshold was 1.4 V, that would take it down to 4.26 V.
I took a step back this morning and tried to do an evaluation as to where I am at, with this Badge stuff, and where I am going. I have a Staff Badge and a Guest Badge, and now I have some quickie C programs also, now I have to get logical in my development approach.
The Staff Badge will become my experimental platform, and my Guest Badge will be the functional one, as I work out a particular modular idea on my Staff Badge, it will be applied to my Guest Badge, and so on.
The first modular idea is the timeclock, I will get that working correctly using the tightest code possible, which will include a terminal necessitated approach to setting the clock. Once that is working, I will then implement it on the Guest Badge.
I see from the limited amount of time that I spent on the RTC stuff, that will be a very time consuming effort, for me, before I get that to work correctly. The RTC functionality is not an easy thing to comprehend and have it work correctly. So, hopefully, some expert in that field can come up with a C function that just works for showing what the battery state(voltage level) is at any given time. This may have to be implemented at some later date.
Also adding the use of buttons, within my UI idea may become a little challenging, this will be my second modular idea to implement. Since there are only seven buttons to work with, will have to think long and hard as to the best approach for using these within my UI approach. Maybe seven buttons is to much, the more you have the more complicated everything becomes when you try to implement them all, just because they are there.
Ray
But, when I plug the USB cable back in and start a terminal program, do the setclock function that seems to work as expected, also the bottom line shows the new timeclock setting. The problem arises when you pull the USB cable, it seems that the Badge reboots itself and you lose all the new timeclock settings, the reboot is not what I was expecting.
If you always get a reboot when you plug and unplug the USB cable, then I got problems with the program bellow. Using a terminal approach will not achieve what I am trying to do, wait, unless the problem is with the terminal program. Is the terminal program making the Badge reboot itself?
Ray
/* stTbasic.c October 3, 2015 Badge Basic Functionality *UI implementation of setclock, manual setup. *setclock to run in its own COG for constant real time update on bottom line. *no blue LED constant on, always on clock will be indication of Badge status. */ #include "simpletools.h" #include "badgetools.h" #include "datetime.h" datetime dts = {2000, 1, 1, 0, 0, 0}; // seed value. datetime dta, dtt; // timeclock related /* COG functions */ void System_base(); /* System functions */ void System_Clock(); int main() { // Add startup code here. badge_setup(); // Setup the badge. dt_start(&dts); // Start the clock. clear(); // Clears the screen of any previous // OLED memory. /* Main system variables */ char inBuff[40]; /* Start the system base utilities. */ cog_run(System_base,128); while(1) { // Add main loop code here. print(">"); getStr(inBuff,40); if(!strcmp(inBuff,"setclock")) Set_Clock(); } } /* COG for running base utilty. */ System_base() { while(1) { cursor(0,7); text_size(SMALL); oledprint("%02d:%02d:%02d",dts.h, dts.m, dts.s); cursor(8,7); /* month day year, last two digits */ oledprint("%02d/%02d/%02d",dts.mo, dts.d, dts.y % 100); } } void Set_Clock() { printi("Enter Time\n"); printi("Year: "); scan("%d", &dtt.y); printi("\nMonth: "); scan("%d", &dtt.mo); printi("\nDay: "); scan("%d", &dtt.d); printi("\nHour: "); scan("%d", &dtt.h); printi("\nMinutes: "); scan("%d", &dtt.m); printi("\nSeconds: "); scan("%d", &dtt.s); dt_copy(&dts, &dtt); }The program above is working as expected, it was the terminal programs fault. I first used putty, and that program, for so reason, at a default setting, does reset the Badge. When I used Tera Term, the problem goes away.
Now the program is running the clock with the new settings, will have to run the Badge for awhile to see how well the new softRTC keeps time. So, now every time you power down the Badge and start it back up, you will have to reset the clock. Oh, I am missing a hardware RTC already.
OK, lets to do a manual battery voltage check, where is that voltmeter...
Ray