Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 3 [4] 5 6

Author Topic: New project, A Clock  (Read 6344 times)

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #45 on: December 06, 2020, 02:50:28 PM »

Many thanks, Weaver,  much for me to think about there.

I had hoped to do deploy a working clock (no filtering) today before sunset, then wait to see what it showed in the morning.  Code to do so was supposedly complete, just needed a bit of testing with the blinds drawn and a torch to simulate sunrise/sunset events.    Unfortunately today has not gone well, too many gremlins, not yet debugged and I have run out of time - presence is required elsewhere for the rest of the afternoon.  Ah well, that's software for you.   ::)

Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #46 on: December 06, 2020, 04:16:02 PM »

If any of that doesn’t make sense then please do shout.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #47 on: December 06, 2020, 07:07:38 PM »

If any of that doesn’t make sense then please do shout.

Thanks Weaver.   

I have now deployed Clock, but it will continue to display a count increasing from 00:00:00 (at power on) alternating with the word “Calibrating” until it encounters a sun transition, which will be tomorrow sunrise.   It’ll then show some diagnostics. But nothing very exciting will happen until tomorrow sunset, when it might, just maybe, if it works, set the hh:mm:ss to a meaningful estimate.

In other words, since my prototype is unavailable for development, I should have all day tomorrow to consider your suggestions.  My gut feeling is, I may well need to shout for help. :D
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #48 on: December 06, 2020, 07:48:16 PM »

The circular buffer is the usual thing; you have a start index and an end index when wrap( last_index + 1 ) == wrap( start_index ) then the circular buffer is full and then the last_index chases the start_index for evermore. Could initialise the to start_index = 1 and last_index = 0 say; every time you increment it your wrap the value round to keep it inside the buffer’s index range. Could have 8 entries or 256 entries or whatever, then you only need a byte for an index type.

Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #49 on: December 06, 2020, 08:13:55 PM »

In my career, we frequently used what we often called “ring interfaces” for transfer between, say, a front end card and the host CPU.   The read index chased the write index, which I think is similar to what you are suggesting.

As an aside that’s not relevant here as my PIC is single threaded and written in assembly... people would often scream “hardware bug!” or “compiler bug!” when they found corruptions in such a dual CPU interface.  Despite careful code sequencing they’d sometimes find that an index had changed yet the corresponding value remained as it was.  Nearly always the hardware engineers and compiler writers were off the hook, when one explored the lesser known topic of memory barriers. :)
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #50 on: December 06, 2020, 08:33:29 PM »

Exactly; a ring buffer I would call it, often came up in i/o or protocol engineering. There are various ways of doing it.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #51 on: December 06, 2020, 08:43:40 PM »

Another point worth mentioning is that RAM on the PIC I’m using is split into disjointed “banks”, each bank separately addressable, and each bank containing 80 (decimal!) bytes.

For most purposes the disjointed banked RAM is a pain.   But with carefully judged parameters the banks might actually lend themselves quite well to such circular buffering. :)
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #52 on: December 06, 2020, 08:53:23 PM »

think about how much soothing you want and that determines the size of your ring buffer. It may be that quite a modest number of entries will be really effective.

What size/data type are the entries going to be? bytes/words/longs? signed or unsigned?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #53 on: December 06, 2020, 08:57:34 PM »

A thought - might be worth playing around with a simulation in a spreadsheet and/or a very short C program to get the numbers to your liking rather than have to fiddle around with machine code debugging both the code and the algorithm + maths all at the same time.

I was once writing a crude interpreted programming language to run on a Psion Organiser I which had a 0.92MHz Hitachi 6301 in it with 2k of RAM and no ROM at all! So it was 2k for everything code, data and user program code too. I first wrote part of it, the syntax checker, on a DEC VAX in Pascal to get the algorithms right and get all the bugs out of it and then after that I just machine coded it by hand very quickly. When everything was finished there was the fun of trying to get it all crammed into 2k.
« Last Edit: December 06, 2020, 09:12:24 PM by Weaver »
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #54 on: December 06, 2020, 09:02:34 PM »

think about how much soothing you want and that determines the size of your ring buffer. It may be that quite a modest number of entries will be really effective.

What size/data type are the entries going to be? bytes/words/longs? signed or unsigned?

I currently count things, length of days and of nights, in seconds.  24 hours in seconds is 0x15180 requiring a 17 bit width.  I may eventually compromise in a count of 2-second intervals, which fits into a much more hardware-friendly 16 bits.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #55 on: December 06, 2020, 09:12:33 PM »

A thought - might be worth playing around with a simulation in a spreadsheet and/or a very short C program to get the numbers to your liking rather than have to fiddle around with machine code debugging both the code and the algorithm + maths all at the same time.

Also has the advantage of not eating into the prototype’s PIC flash endurance.  Microchip say it’s 10k erase/write cycles which sounds a lot, but hitting ‘run’ on the debugger button every few minutes soon adds up.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #56 on: December 06, 2020, 09:27:30 PM »

You could store 17-bit values in 24 bits and just waste the last 7 bits, or could fully bit pack them; I suspect you might not need to have that many entries for your smoother’s ring buffer, fewer entries allow more spikes through, more entries provides powerful smoothing. Say you had 16 entries each 24-bit entries; that would easily fit into 80 bytes, but I don’t know you might want more entries than that. One other thing is you could make three parallel arrays one for each byte of your entry, low, mid, hi byte, and put 64 entries in the triple of parallel single-byte ring buffers and that would fit into three 80-byte banks. To bit pack to 17 bits exactly, means all that multiplication and masking and shifting - a real pain. Did an enormous amount of that kind of stuff with variable-width bit-packed data fields that straddled across byte boundaries, used for data compression.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #57 on: December 06, 2020, 09:33:41 PM »

At the moment I store my 17 bit vars in 24 bits of memory.   And that preys upon my conscience.

But the PIC has 1024 bytes of SRAM, of which I have only used about 60 bytes so far.

The time may come when I need to optimise, but even if I give generously to the ring buffers, chances are it may not be necessary.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #58 on: December 07, 2020, 10:10:36 AM »

Oh dear, my first test launch is listing badly.   :-[

When the lighting level hit my (arbitrary) threshold, about 5 mins after sunrise, it triggered the correct state transition.  Clock then began counting seconds.  Idea being, when it hit the same threshold this afternoon, it would calculate calculate Solar Time offset and synchronise the quartz controlled clock.

Unfortunately... a bug.  I'd simulated the whole cycle by switching a desk lamp off/on, but I'd been impatient, and used 'days' that lasted only a minute or two.  That all worked but when it encountered a real day  my counter went skew whiff after 256 seconds.

Checking the source code it is a very obvious and trivial bug, exemplary of the perils of assembly language, an 'addwf' mnemonic that needs to be 'addwfc'.  But I have to wait half a day before a chance to start another test.   :(

Thinking further I'm reasoning that, in addition to estimating Solar Noon by sunrise/sunset,  a very useful additional parameter will be to count seconds between sunrise transitions.  That should give me the length of a solar day, and would be self compensating no matter which direction I am facing, or whether in the shade of mountains or buildings.  And Solar Day length opens up all sorts of avenues for deductions and assumptions.   ;)
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #59 on: December 07, 2020, 02:55:26 PM »

Think about a really modest sized rig buffer, only say 16 entries, would that give you enough smoothing? Might be an idea to collect some real data first, by hand, with a clock and stored in a spreadsheet. That would give you something real to run your spreadsheet smoother or C smoother to work on and see how big the smoothing effects are. Ask yourself - what would the average of the last say 16 days be like?
Logged
Pages: 1 2 3 [4] 5 6