Possible late addition - a RTC feature using a 32bit counter that is clocked at 1 sec.

I realize this might just be a no-go, but it would certainly add a percieved value to the Propeller 2.

I recently came across the DS1672 which is a 32bit RTC I2C solution for the Propeller 1 or maybe the 2. But the cost is about $2.00 or so per chip.

Having this feature, or all the features of the DS1672 internally would appeal to many developers. It just might be a deal-making feature.

Take a look at what it does. It seems like the core feature would just take a wee bit of silicon, and of course two i/o for the clock crystal and one power for a backup battery.



  • Heater.Heater. Posts: 21,233
    edited 2015-12-07 - 07:59:17
    Eh, can't delete post on mobile.
  • jmgjmg Posts: 14,540
    .... It seems like the core feature would just take a wee bit of silicon, and of course two i/o for the clock crystal and one power for a backup battery.

    Low Power Oscillators and Power domains, are non-trivial, and are not verilog.
    It would be custom cells, of Oscillator stage, plus Low power buffer plus power island handling.
    Checking at Digikey finds RTCs from 29c/4k, and those are done in a process tuned for RTCs.
    Or, a full MCU with a 32kHz Osc, comes form 47c/1.5k

  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2015-12-07 - 13:01:46
    Well, prices at purchasing thousands of units may apply to Parallax adding this to their production boards, but Propeller chip purchasers in smaller lots might appreciate it being built into the Propeller. A cost analysis of which is best is beyond me.

    And for me to buy a small lot, make the boards for personal use is really expensive. The 8bit RTC boards that are available demand a lot more code than is justifiable on a 32bit CPU.

    Either way, it seems like there is an opportunity for Parallax to profit from selling these as added to boards, to make boards to support the Propellers AND any other 32bit processors without a RTC (like the Raspberry Pi, etc. when off the internet), or even selling the chips in small quantities for DIY.

    I do realize in some cases, a GPS unit could do the job instead of a network interface. But having autonomous RTC may be preferred for many projects.

    Nonetheless, this is merely an item put in the suggestion box. I don't want to bother with lobbying for it as a must have feature in the Propeller2 or or an added chip. I just offer the idea that it may make sense. I'd equally would like to buy a few chips or completed boards for Propeller 1 projects as an add-on

    And I do accept that it might not work out in an FPGA or chip production.
  • As mentioned in the related P1 thread, there does not seem to be much here that could not already be done with a cog and minimal code.

    I cringe a bit at how feature requests are written on the P2 threads, even though I know that they are well-meaning expressions. A user story provides a good format to ensure that you are answering the appropriate market questions - "Who", "What", and "Why":

    As a <who = role>, I want to <what = feature or problem solution> so that <why = benefit(s) that would be achieved>.

    Bonus points if you are able to articulate an acceptance criteria, so the designer can perform a back-test to ensure that success has been achieved.

    Negative points if you tried to answer "How".

    If I was the designer, it would not be clear to me what is specifically valuable - 32 bit data, battery back-up, reduced system cost, etc. See how this can get out of control so quickly?

  • Did you say "user story"? Are you some kind of HTML/Javascript web developer?

    Only joking. These suggestions have been going on here for years. You may not be aware of it but such suggestions were invited by Parallax for the PII. Many of them ended up in a design that became so bloated it was scrapped and a new start made.

    I am guilty of contributing to that disaster myself.

    Personally, I'm hoping Chip has his ears closed and is busy finishing the thing. Before most of the enthusiasts die!

  • On this design, there are timer interrupts that can provide that RTC. And there are 16 COGS. Any COG can provide the RTC, and if there is even one COG that isn't time critical, real time code, that RTC will be largely transparent to whatever else is happening with that COG.

  • I think Loopy has a point though.

    Pretty much every embedded system I have worked on has had an RTC bolted on to it. We always want the thing to know what the time is when it wakes up after a power cut.

    Can't be done in software, interrupts or not.

    Arguably the P1 can be in a low very low power state when "main" power goes down and it is run off a battery. Then it can keep time. Not so much the PII.
  • Well, I need the chip with the extreme low power that can be read on boot to initialize the time. It is all about keeping time when the Propeller is off.

    I have worked with at least one BasicStamp clone that had an internal RTC, but no indepented power to keep it running. One has to set the time each and every time you turn on the device.

    Forget that I suggested it be built into the Propeller 2, The DS1673 uses UTC time format and can be quickly and easily read via I2C. The other RTC chips have a dreadful series of registers that might have been reasonable with 8 bit processors, or 16 bit processors, but UTC is entirely based on one 32 bit integer. Mostly it is good for alarms and time stamping in data logging.
  • Heater. wrote: »
    Did you say "user story"? Are you some kind of HTML/Javascript web developer?

    Only joking.

    Ha! No, I just happen to have a great deal of empathy and a toolbox full of stuff stolen from other industries. The user story just seems to fit the format of a forum (i.e. self-reporting, concise, answers useful questions).

    Heater. wrote: »
    I think Loopy has a point though.

    Usually does, so I hope that I did not come across as busting his stones. The external RTC solution exists, so there is no new functionality, per se. Rather, there is some potential for easy prototyping, PCB real estate, and maybe BOM cost reduction. And of course, once it is settled that 1 second resolution is appropriate, someone will ask for 0.01 seconds and we will start all over.
  • hatallica,

    Back in the day we had "use cases". Your use of "user story" tickled me because I just returned from a Microsoft web developer conference where a young girl was talking about "user-journeys".

    Aside: Did everybody catch that: Heater has been to a Mircrosoft gig!

  • @HEATER. are you sick or something?

    I am worried about you. Not that you recently said you are USING windows once in a while, now you are going to a WEB seminar, even if you dislike HTML and CSS like you dislike MS?

    Or did you finally saw the light?


  • @Heater
    I would be curious to read your thoughts on the experience.
    I'm sure i'm not the only one interested. :)
  • On RTC
    Here's a simple and compact RTC in P2 PASM.
    rtc           incmod    hsecs,#99 wz
            if_z  incmod    secs,#59 wz
            if_z  incmod    mins,#59 wz
            if_z  incmod    hours,#23 wz
            if_z  add       days,#1
    Just connect it to a 100Hz interrupt.

  • I'm interested too. User journeys has all sorts of UX fun n gmes attached to it. Maybe that is why Metro was not so well received on non touch systems....

  • msrobots, ozpropdev,

    Thanks for your interest and concern. I'm OK, I think...

    I had a good day with MS. Such kind, gentle, generous and understanding people. They have been misunderstood and abused by everyone for such a long time. I think they can help me. Anyway I signed up for their little organization and gave them all my worldly possessions. Perhaps I can help spread the word that if only people used Azure their lives would be so much better.

    Slap...Heater...please come home...your family is missing you...

    Actually, I was thinking of posting about my day with MS. It was interesting in many ways. Perhaps when I have a few minutes.

    What tickled me is that I got to play on a Surface Pro for a few minutes, their new Edge browser on there refused to run the JS in my experimental Propanel web page. Amusing because the error message indicated the same symptom that I reported as a bug to Firefox a couple of weeks ago! It's to do with the internationalized domain name 2π.net https://xn--2-umb.net
  • Hehe, implying maybe just a little bit of source leakage ... I observed a similar leakage going on from Wine to Cedega from time to time.
  • Heater.Heater. Posts: 21,233
    edited 2015-12-08 - 11:05:09

    Oooo...I would not want to accuse them of "leaking".

    I'm suspecting some ambiguity in the specification of International Domain Name and Content Security Policy features has caused both Mozilla and MS to implement it wrongly, but both the same/similar wrong way.

    I have to play with Edge some more and confirm I was interpreting the error messages correctly. This bug is a show stopper if you want to use modern security features in those browsers. Which we do of course.

    Hey, could you explain what your sig is about?
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2015-12-08 - 16:29:14
    ozpropdev wrote: »
    On RTC
    Here's a simple and compact RTC in P2 PASM.
    rtc           incmod    hsecs,#99 wz
            if_z  incmod    secs,#59 wz
            if_z  incmod    mins,#59 wz
            if_z  incmod    hours,#23 wz
            if_z  add       days,#1
    Just connect it to a 100Hz interrupt.

    Yes, but how did you set the time at startup. 1 Hz resolution is adequate for setting computer clocks at boot for the whole WWW. That is even a 32bit standard.


    The 1Hz RTC is for start-up, it uses UTC so that Years, Months, Weeks, Days, Hours, and Seconds all fit into a 32bit framework that will continue to be good for at least a few decades from now. Files, data time/date stamps, and more can quickly take one 32bit number without decoding until you need to have a human read the info.

    At 100Hz, your scheme with a 32bit counter will cut years off the utility of the finished product. Nice for hobby work, but won't satisfy customers that outlive your products end of useful life. It wouldn't be UTC, so the range of time would go down to a year or less than two in a 32bit format. Reference to it would not be universal, others wouldn't understand.

    Try this tutorial to get up to speed about why 1Hz is useful.

    A. UTC reaches back pretty far and goes forward pretty far with one 32bit number.
    B. +/- one second is quite adequate for setting clocks in synch for most applications -- like internet servers.

    Just maybe if I forgot all my humor and changed my log in to "Wise Elder", I'd be taken more seriously.
  • The Unix time tick, a count of seconds since 1st Jan 1970, rolls over in 2038. Only two decades away.

    This fact has already bitten me a couple of years ago. I was using OpenSSL to create self-signed security certificates. They did not work. Only recently I found out why. I had set the expiry date 40 years into the future. That is way passed 2038 and when you did this on a 32 bit machine the expiry time rolled over. The certificates were created expired! This bug has been fixed now I believe.

  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2015-12-08 - 16:37:56
    Well if you are worried about going past 2038, one could just add a second 32bits to the 32bit counter. But it won't begin to change until 2038 - just all 00000000000000s.

    That's a detail easily resolve, but you can't dismiss the recource exists today.

    Maybe we should provide enough bits so that zero begins with Biblical creation goes forward to now and doubles that range.

    What is the end of the future range of alternative RTC devices, 2099 perhaps?
  • Heater.Heater. Posts: 21,233
    edited 2015-12-08 - 17:05:45
    Great idea, let's base our idea of time on a fictitious event that we have no idea when it happened. Or didn't.

    If we are going to go crazy, the universe came into existence with the big bang about 13.7 billion years ago.

    I make that about 432043200000000000 seconds. Or 4.3e17 seconds.

    with a 64 bit counter we can get to 18446744073709551616 seconds. Or 1.8e19 seconds

    That leaves 18014700873709551616 or 1.8e19 seconds to go.

    Or another 571242417355 years. 5.7e11 years.

    That should be enough. :)

    Anyone care to check my working here ?

    Anyway, the 2038 problem is already fixed in most places if I understand correctly.

  • Y2K38 bug ... start prepping for the apocalypse, because computer systems are going to shut down.

    Ok, I have been convinced that P2 should have an embedded RTC - relative time clock - that maintains Federation time regardless of speed.
  • hatallica wrote: »
    Y2K38 bug ... start prepping for the apocalypse, because computer systems are going to shut down.

    Ok, I have been convinced that P2 should have an embedded RTC - relative time clock - that maintains Federation time regardless of speed.

    And when is stardate zero?

  • @Heater
    The end of the universe is nigh; we're doomed, doomed I say.


    I find that very depressing, and I have a pain in my diodes all down my left side.
  • kwinn wrote: »
    And when is stardate zero?

    When the P2 comes in silicon.

    Easy peasy...

  • hatallica,
    I have been convinced that P2 should have an embedded RTC - relative time clock - that maintains Federation time regardless of speed.
    Cool, now the P2 will have built in accelerometers and gyros so it can make the time dilation adjustments.
  • Heater.Heater. Posts: 21,233
    edited 2015-12-09 - 12:43:34
    Guys, I have discovered something very deep and mystical:

    The age of the Universe in seconds is Ga = 13.8e9 * 365 * 24 * 60 * 60 = 435196800000000000

    Counting seconds since the big bang a 64 bit counter will roll over after Cmax = 2 ^ 64 = 18446744073709552000 seconds.

    I was wondering what fraction of that total count we are at now:

    Cm / Ga approximately equals 42

    Oh what ?!


  • But what if we want milli-second or micro-second accuracy? Let's add another 32-bit counter for a total of 96 bits. That will give us nano-second accuracy for a several more billions of years.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2015-12-09 - 14:20:03
    The whole UTC dilemma in 2038 could be avoided by just adding one-bit to the 32bit format. Or add two bits to the 32bit format and have one indicate 32bits before 1970 in a counting backwards number format (Just like BC and AD do), and the other bit indicates after 2038 in a positive format.

    00 = standard UTC
    10 = pre-1970 UTC counting backwards from 1970
    01 = post 2038 UTC
    11 = name your own not-standard by another start-date.

    I suspect that there is no really need for 96bit time as the future is merely speculative.

    But we do need to have enough to cover all of human history. One of these days, astrologers might actually get correct interpretation of the stars. Only then might we need to look forward so far.

    2038 dread? I will be 89 years old and unconcerned. And my bank's credit card division claims there is no future after 90-days. What me worry? By then, all I want is a good bedpan and a nice pretty nurse.
Sign In or Register to comment.