On Thursday, March 14, 2019 at 1:37:04 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

On Wednesday, March 13, 2019 at 5:36:37 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:


The simple count method I listed would easily be able to update
current speed with a one-second display refresh rate.

We'll just have to disagree, then. Have you written any embedded
software at all?

Not using a microcontroller/processor as the target. I'm not a
software engineer - quite franlkly it bores the **** out of me.

And yet you are entertained by arguing about it. Odd.

I didn't write that I don't have any experience at it - I've been involved in code reviews at my various positions for over 30 years. In my current position, one of my responsibilities is maintaining and updating Labwindows CVI (also c-based) for our manufacturing ATE, and even then I've been caught sleeping with my fingers on the keyboard. IF I had to write those whole 10K+ lines of code from scratch.....ugh.


I'm a
hardware engineer. I've written VHDL with Altera and Xilinx targets
for combinatorial boolean blocks and counter/timer functions. It's all
C-based, so not too far removed from 'real' software (our software
team used to like to bust our chops about 'real' SW vs FW/VHDL). Some
were implemented in manufacturing as programmed FPGAs, but a few were
prototypes with the intention of using the resultant structure to
develop an ASIC. This was part of a telecom optical network testing
tool for commissioning optical network switching hubs (aka 'central
office') when I was with a telecom test group at HP in the early
'90s. We specialized in asychronous transfer mode (ATM) protocol error
injection to test the ability of the networks to both detect the
errors and correct them. Our senior scientist got a patent for a
segmentation and reassembly chipset that used the 'leaky bucket'
algorithm. Those were fun times.....

That explains the idea of an ASIC, and the idea that it's simple to count
clocks between two signal edges.

Designing for hardware is much different from software.

You don't say...

In hardware,
everything happens at once, which can bite you in the ass.

Well, that's the first I've heard that concurrent task handling and speed are a bad thing, though I do remember having to write synchronizers into the combinatorial sections because the propagation delay took us a bit by surprise. This wasn't exactly a bad problem to have.

In software,
at least with only one core, you can't do two things at once no matter
how convenient it would be. In hardware, if you have the gates you can
dream up completely new ways of capturing inputs. In software, you use
what the hardware gives you, sometimes ingenuity pays off and you can
use it for an unintended use, but that's not the way to bet.

Consumer electronics is also much different from industrial test
equipment. In consumer software the three most important things a

1. BOM cost
2. BOM cost
3. Schedule, it has to ship in time for Christmas, no matter what.

Right, that's why earlier I wrote "To invest in that kind of software development [quantization error correction] for a bike computer simply isn't cost effective, they'll never get the NRE return. For us, a simple counter with an ALU is more than enough". You're suggesting an ASIC won't give the return on investment - which can be true - and I'm suggesting quantization error correction won't give the return.


That's why I don't believe an ASIC is used in bike computers, sure you
could build in a bunch of neat features, but the NRE for a new ASIC,
while it has come down a lot, is still well north of $1M.


Nah....from https://electronics.stackexchange.co...stom-asic-made

*********
FPGA Conversions: ........

Pros: Low NRE (US$35k is about the lowest). Low minimum quantities (10k units/year).

Cons: High per-chip costs-- maybe 50% the cost of an FPGA. Low performance, relative to the other solutions.
**************

Making that
back on a product with a wholesale price of a few dollars is just not
easy. Also note #3, picking parts that are available now is the way to
go.

Considering that a cheesy 8 bit Microchip ucontroller is about $5 in the 100's it's likely you're right - most non-gps bike computers are probably ucontroller based.




A typical frequency tolerance for an RTC crystal today is +/- 20 ppm.

Frequency tolerance and phase jitter aren't the same thing, but even
so, 20ppm is 2*10e-5. So a typical ~32KHz xtal is accurate to less
than .001 Hz. More than accurate enough for a bike computer.

Nor did I say they were the same. Frequency tolerance is more
interesting.

It depends, Tight frequency tolerance is great, but doesn't help
phased based modulation schemes if your base synthesis has high phase
errors. A crystal with a tight phase tolerance helps keep loop
bandwidth tight, which means higher data throughput for phase based
wireless datacomm protocols in use today (e.g. QAM and its'
derivatives). If you're into wireless IoT, phase tolerance _should_ be
just as interesting as frequency tolerance. FWIW, phase error can have
just as much of an effect on quantization errors as frequency
instability, depending on the sampling technique.

But we were talking about an RTC on a bike computer.

Right, just bringing things into perspective. Quantization error correction and crystal stability can be critical issues in certain applications, I just don't think bike computers are one of them

I think IoT is a
tool of the Devil, and would hate myself if I helped it spread.

LOL....I like that, I may use it the next time it's brought up in one of our market requirements review meetings. I personally have no use for IoT, but I have several friends and co-workers that want to run their whole house from their smart phone. I tell them I'd rather ride my bike.


The thing about an RTC that is likely to make users
unhappy is having to adjust the clock time.

I find this aggravating. I know this probably isn't a legit RTC, but
the clock in my car loses a minute per month (no, I'm not
exaggerating), yet I have a ten year old MP3 player I use when working
out that I've never had to rest the clock (I paid $40 for it in
2009). My car is a 2010 element, and it's had this problem since it
was new. I understand from reviewing several internet forums that this
is sort of a known issue, and the dealer said all hondas from that
period that _don't_ have factory navigation systems have this
problem. I understand that saving a few pennies per car means a lot on
the overall cost of the product, but really?

Somebody saved $0.05 on parts. Not always a win.

Right, remember this?

https://en.wikipedia.org/wiki/Genera...switch_recalls

"The company continued to recall more of its cars over the next several months, resulting in nearly 30 million cars worldwide recalled and paid compensation for 124 deaths. The fault had been known to GM for at least a decade prior to the recall being declared. As part of a Deferred Prosecution Agreement, GM agreed to forfeit $900 million to the United States."

All to save a couple of bucks on the ignition switch, which had already been redesigned for the problem before the cars went into production. At least my clock isn't going cause any deaths.