Frank Krygowski writes:

On 3/14/2019 3:59 PM, Zen Cycle wrote:
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.

For what it's worth, Cateye says its units use a "4 bit one-chip
microcomputer (Crystal controlled oscillator)"
See
https://www.cateye.com/files/manual_..._HP_ENG_v1.pdf

Note that 4 bits is just enough to encode one decimal digit. I'll bet
most of the computation is done in binary coded decimal, as it is for
handheld calculators.