An Observation

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
«1

Comments

  • 38 Comments sorted by Date Added Votes
  • Was the computer sending the time to the Propeller? If so, you have a bug in your Propeller code - the Propeller didn't expect time to go backwards an hour. If not, the OS your program running on the computer has a bug - it resets the serial port when time runs backwards.

    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 laptop does not send time and date data to the Propeller as part of the operating system.

    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

  • I was under the impression that the Propeller did not have a built in RTC clock, thus has no means to keep track of time as in whether or not it is DST. Does the board have an external RTC circuit that keeps the time or is the board picking up the time from some sort of NTP server?

    Can you share more details regarding the board or circuit that you are using?
  • Can you set the computer clock back before the time change and force the problem to happen again?
  • PublisonPublison Posts: 9,942
    edited November 2017 Vote Up0Vote Down
    He might be using the RTC object from the OBEX:

    http://obex.parallax.com/object/793

    or this one:

    http://obex.parallax.com/object/499

    Infernal Machine
  • Many years ago, I did receive a download supplied by a forum reference that used one Propeller COG as an RTC. It keeps time very well for my system. I don't know it the code is either of the ones listed above.

    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
  • I found it. The code was supplied by Ray Sadeika that was supplied to him from another. I modified the code slightly ...I don't use the SD card.

    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);
    }
  • Is there something wrong with the day light code?

    Discovery
  • AleAle Posts: 2,313
    edited November 2017 Vote Up0Vote Down
    its formatting ?

    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 has stopped several times since the observation of stoppage during day-light time change so it appears that it was a coincidence.

    The Propeller just plane stops running the program after several weeks of perfect operation.

    Discovery
  • What is your power source for the prop? If it is glitchy, you could be stopping the prop and rebooting (or not) and your count for the clock is lost. Remember, it is all in software and power dependent ram.
    Jim
  • Heater.Heater. Posts: 20,552
    edited November 2017 Vote Up0Vote Down
    I have no idea what is going on with your system Discovery.

    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.


  • I have about a hundred Propeller based embedded devices which have run for years - in some cases more than a decade - without trouble, some in fairly harsh industrial environments. These include a lot of QuickStarts, a small pile of DIP40's on boards designed by forum member Bill Henning, and a handful of PropMinis. Every single time I have ever had any kind of instability it has turned out to be in the software.
  • If this is a turn-key app vs bench testing I'd recommend disconnecting the Prop's reset from the PropPlug as you don't want any DTR or external glitches tripping the reset and especially considering the PC or OS could be responsible. The Prop itself does not crash, always troubleshoot by eliminating causes so do the easy stuff first such as the reset or power supply, the pcb, the soldering and wiring etc and of course the software itself. If you are not sure whether it is the software then leave a simple program running for that same time if you can. Just be methodical and don't ever rule out anything and you will certainly track down the problem, no one else can do this for you.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Power comes from the Utility line at 120 VAC, energizes a UPS, the UPS supplies 120 VAC to a +/-15 VDC open frame power supply, the +15 VDC drives a +5 VDC chip regulator and a 3.3 VDC chip regulator, the 3.3 VDC regulator drives the Propeller and the EEPROM. The PCB and +/-15 VDC power supply are contained in an aluminum housing and grounded to instrument ground...the green wire ground.

    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
  • Peter,
    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
  • Discovery wrote:
    If I disconnect the USB cable from the laptop...what do you expect to happen?
    That depends upon the circuit used to connect the USB chip to the Propeller. In some circuits, a high on the Prop's serial out pin will power the USB chip parasitically, causing it to reset the Prop. This happens continuously, preventing the Prop's program from running.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • There is some problem having serial connected all the time. Except of the spinnerette most available boards have no way to disconnect /reset from the serial interface.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote:
    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.
    This is true for some -- not all -- USB-to-Prop interfaces. Parallax's newer boards with built-in USB interfaces avoid this problem.

    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Wow...I have a response from localroger who states that he has about one hundred Propeller embedded chips that have run successfully for over a decade and other responses from those who know that several resets occur from a variety of causes.
    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
  • If you are using a PropPlug then simply make up an 4-way adapter cable with a switch or jumper in the reset line. The Prop itself is reliable but some Parallax boards have onboard USB which has been problematic for embedded applications although great for the education market. Some of my commercial products do have onboard USB but all these are always powered both from the host and from local power so there is never a situation where the USB is unpowered.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Discovery wrote:
    My factory controller Propeller has the PropPlug from Parallax that interfaces to a multi-layer PCB.

    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • If you are unplugging the USB PROPPLUG, then also ensure your program(s) is/are not running a serial connection as noise could give you corrupt receive characters.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Very good Pete,
    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
  • I have drawers full of these standard 0.1" pin header cables as well as a large assortment of singles in various gender types. I normally would just grab one of these, cut the reset wire, put a simple 2-pin jumper in there, and that's all. It helps if one end has pins for the PropPlug but I'd cheat there and just solder two 4-pins back-to-back, you know, those 0.1" pin headers (I have thousands of those too. However, don't be shy about using a narrow strip of matrix board or something similar, that way you can have mating connectors either end and mount a switch etc. But as mentioned, if you are going to unplug the cable then you are better off doing it at the PropPlug to Prop end rather than the USB cable itself.

    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.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Pete,
    Will my four step approach above work?

    Discovery
  • Discovery wrote: »
    Pete,
    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.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Shall do...thanks.

    Discovery
  • Peter,

    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
  • Do you mean the BS2 reads the one-wire sensor and communicates to the Prop which communications to the laptop via USB? If so then I wonder why use the BS2 but maybe you just happen to have it setup I guess. The reset line is only ever used for programming so the point is that it needs to be connected if you want to program the Prop but the reset line is not needed for serial communications of any type, just receive and transmit and ground.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
Sign In or Register to comment.