An Observation
Discovery
Posts: 606
in Propeller 1
I have a Propeller Controller running a system and displaying system data on the computer screen via the USB standard Parallax interface to the controller. The system has operated perfectly for months then the propeller stopped.
I had all the Internet programs and automatic programs removed from the controlling laptop computer so that it was just a basic control computer. However, I noticed the computer clock changed from Day-light time to Standard time and I noticed the propeller interface hung up.
Has this observation been reported before?
Also, how can I stop the computer from automatically changing the clock time?
Discovery
I had all the Internet programs and automatic programs removed from the controlling laptop computer so that it was just a basic control computer. However, I noticed the computer clock changed from Day-light time to Standard time and I noticed the propeller interface hung up.
Has this observation been reported before?
Also, how can I stop the computer from automatically changing the clock time?
Discovery
Comments
I'm guessing you're using Windows, which always had problems with Daylight Savings Time and timezones in general. On Unixes, time is kept in UTC and only converted to local time when it's actually displayed as text, so these problems don't exist.
I suppose you could somehow tell your computer that DST doesn't exist in your area. But supposing the bug isn't part of the OS, you should really just find the bug and fix it instead of preventing your computer from adjusting the clock automatically.
The application program in the Propeller asks for the year, month, day, hour, minutes, and seconds then starts a Cog in the propeller that keeps the time.
The Propeller program sends data to the laptop for display.
I wonder if the USD ports get initialized when the laptop time changes from DST to ST and vice versa.
One more thing...the Propeller application that was provided from someone in the forum asks if the "setclock" time is DST or ST. The "setclock" was in DST when the Propeller stopped operating.
Discovery
Can you share more details regarding the board or circuit that you are using?
http://obex.parallax.com/object/793
or this one:
http://obex.parallax.com/object/499
I am not knowledgeable enough about the "C" code to know if there is a fault in the code or not. I will try to find the code and post or reference it.
It may be a coincidence in the Propeller stopping during a clock time change but somehow...I don't think so.
Discovery
Discovery
// Add startup code here.
uint8_t buffer[40];
// int DO = 22, CLK = 23, DI = 24, CS = 25; // SD card pins
// sd_mount(DO, CLK, DI, CS); // Mount SD card
_rtc_start_timekeeping_cog(); // <---- important.
print("This is softRTC\n");
print("help - for menu\n");
while(1)
{
// Add main loop code here.
print("> ");
gets(buffer);
if(!strcmp(buffer, "quit")) break;
else if(!strcmp(buffer, "help")) Help();
else if(!strcmp(buffer, "setclock")) Set_Clock();
else if(!strcmp(buffer, "time")) Get_Time();
else if(!strcmp(buffer, "date")) Get_Date();
else
{
print("Invalid Command!\n");
}
}
print("System Stop!\n");
}
void Help()
{
print("Commands are: setclock, time, date, quit.\n");
}
void Set_Clock()
{
struct timeval tv;
struct tm t;
t.tm_isdst = getdst();
t.tm_year = prompttime("Year")-1900;
t.tm_mon = prompttime("Month")-1;
t.tm_mday = prompttime("Day of the month");
t.tm_hour = prompttime("Hour");
t.tm_min = prompttime("Minute");
t.tm_sec = prompttime("Second");
tv.tv_sec = mktime(&t);
settimeofday(&tv, 0);
}
int getdst()
{
int rc = 0;
print("Use daylight savings time [y/n] ? ");
fflush(stdout);
rc = (getchar() == 'y') ? 1 : 0;
getchar();
return rc;
}
int prompttime(char *prompt)
{
int rc = 0;
char *endp;
char buffer[BUFFERLEN];
do
{
print("Enter %s: ",prompt);
fflush(stdout);
fgets(buffer, BUFFERLEN,stdin);
fflush(stdin);
rc = strtol(buffer, &endp, 10);
if(endp == buffer)
{
if('\n' == *endp)
{
rc = 0;
break;
}
print("Invalid entry \"%c....\" Please enter a number.\n", *endp);
}
} while(endp == buffer);
return rc;
}
void Get_Time()
{
char timebuff[16];
time_t now = 0;
now = time(&now);
strftime(timebuff,16,"%T",localtime(&now));
print("%s\n",timebuff);
}
void Get_Date()
{
char timebuff[16];
time_t now = 0;
now = time(&now);
strftime(timebuff,16,"%b %d, %Y",localtime(&now));
print("%s\n",timebuff);
}
Discovery
for easier reading you can enclose your code between [ code ] [ / code ] without spaces between the word "code" and the brackets, it preserves indentation and forces a sane fixed width font
The Propeller just plane stops running the program after several weeks of perfect operation.
Discovery
Jim
But I am very confident that given a stable source of power and a bug free program the Propeller will run and do what you want longer than you and your children.
If the Propeller was prone to just "plane stops running the program after several weeks of perfect operation" I'm sure we all be aware of it after all these years.
Aside: I guess you mean "plain".
Time to start homing in on potential issues here.
For example, I cannot make out what your code above is supposed to do exactly but it looks like if some corrupted message comes in it can all get jammed up.
One should always be aware than incoming data, from serial ports or whatever, can be erroneous. Due to noise on the communication line or whatever.
Tomorrow, I will setup my oscilloscope in the factory and monitor the 3.3 VDC output of the regulator chip for a negative going spike. If I don't catch a spike in a reasonable period of time, I will see about installing a switch in the reset line. Closed for communicating and open for operation.
Discovery
When I run my Propeller program, there is interactive dialog with the laptop to set the year, day, date, and time...then the main program runs. I removed all print statements in the Propeller program.
If I disconnect the USB cable from the laptop...what do you expect to happen?
Discovery
-Phil
if using a propPlug you can simply just NOT connect /reset, on most other boards with USB you are - hmm - bound to cut some traces and solder two pins to make /reset able to disconnect.
The reason is that when you PC reboots or needs to re-enumerate the USB bus the build in usb adapter will reset the Prop.
That is a problem with most Propeller boards available, It even can bite you when NOTHING is connected to the USB port of the P1 board. Because as soon as you SEND serial data from the Prop to USB, and nothing is connected, the stray power over serial tx from the prop will activate the USB chip, thus resetting itself.
To make this clear, if NOTHING is connected to the serial USB output of your board, the USB chip will reset your P1 whenever you send something to the serial output.
might be the cause of unexpected restarts.
Mike
So it's important to look at the schematic of the OP's Prop module to see if errant USB-chip resets could be a contributing factor to his problems.
-Phil
I have a Propeller Activity Board with the built-in USB chip on board and have not had a problem; however, this board does not run a factory for months on end.
My factory controller Propeller has the PropPlug from Parallax that interfaces to a multi-layer PCB. I really don't like the prospect of cutting down to the /reset trace and soldering wires to a switch so that /reset to the Propeller can be held high while the Propeller is running it's program.
Is that my only option here?
Sincerely,
Discovery
That's one of the scenarios that might be problematic. The solution is to unplug the PropPlug, rather than just unplugging the USB cable.
-Phil
That is what I will do. In the interim, rather than leave my oscilloscope on the factory floor for who knows how long to monitor the 3.3 volt regulator output...I designed a negative pulse catcher instrument that will latch an LED should the 3.3 volt line drop below 2.1 volts. Nice instrument.
Now let me determine if I understand what needs to be accomplished. First, I build a 4-wire interface cable that fits between the PCB header that feeds the Propeller and the propPlug. Second, I build into the interface cable a switch that opens and closes the /reset line to the Propeller. Third, I close the switch whenever I make a program change and need to download the program to the Propeller. And last, I open the switch so that the Propeller supplies Vcc power to it's own internal /reset signal. Is that correct?
Discovery
My software can write to the EEPROM very easily so my boot routine normally has a reset counter that writes back to EEPROM each time. That's handy as I can easily check via a terminal if everything has been running smoothly or not. BTW, Spin variables for instance can be backed up to EEPROM at the same address as the variable and when the Prop boots from the EEPROM all it does is read in 32k of EEPROM into 32k of hub RAM, and presto! there's the variable "preloaded" with the saved value.
Will my four step approach above work?
Discovery
But of course. Mount the switch closer to the Prop end so that the Prop's reset line is not acting as an antenna ready to pick up stray glitches.
Discovery
I assume that the Propeller can send data back through the USB for display on the laptop with the /reset switch in the open position and all will be well. I use the Propeller communicating through a BS2p to collect one-wire sensor data for display using the Propeller USB port on the laptop.
Discovery