Arduino fun..

[David Martin]

I'm using an RC circuit upstream of the 7414 - it all seems to behave nicely. So I am happy. I'll let the arduino worry about as little as possible.

Now thinking about how best to get a simple graphical display to run on the Mac.

[TimO]

I'd rarely use TTL these days, there would need to be a very specific reason for doing so.  If I needed TTL levels I'd use a 74HCT device, or 74HC if I wanted the wider voltage range of CMOS (and didn't need reliable TTL logic levels).  The HC and HCT (and their equivalent) devices will generally use less power than the older 7400 family technology.

Of course the CMOS devices are more prone to ESD issues, but that shouldn't be a problem with moderate care in handling, and you'll have the same issues with the Arduino, so you should be careful anyway.

[David Martin]

As a complete novice in this game, I'm wondering whether it should be done in software, using interrupts as suggested by others, or whether the hardware counters are a better solution. Obviously there are more parts to deal with in the hardware solution - a couple of extra chips per input, but you get a guaranteed [FGVO] expandability to as many inputs as desired. How many interrupts needing to be monitored on a millisecond scale can an arduino reliably handle in software whilst doing output and potentially responding to serial input as well?

[Feanor]

Well, that's the whole thing!

That's what I loved about the PIC project.
I could decide what it was reasonable to do in software, and what had to be done in hardware.
That is your bane.

I think that for your input ( a reed-switch ) that you ought to be able to pre-condition the signal so it's clean enough to not have to deal with it in software.

But that depends on your bias: HW v SW.

As has been said, A schmitt trigger is just a hysteresis device, to avoid multiple-triggers as the input hovers around the input-threshold.   It's not a debounce system, per-se.  A 555 one-shot can be, as it can hold the output for a period, following an initial trigger,and hold it beyond any bounce.  It's also not hard to de-bounce in software, if you set a timer to ignore edge for xx mS after one occours.   Handling it as an interrupt may work well.  On entering the interrupt service routine, simply mask interrupts for period x to allow the input to settle before  proceeding.

Also, I'd repeat previous advice about caution when mixing 74xx TTL and 4xxx CMOS regarding voltage levels.

[David Martin]

As mentioned, I'm using an RC circuit upstream of the schmitt trigger as IIUC the RC circuit provides a slower transition that is buffered by the capacitor, and the schmitt trigger removes the potential for 'intermediate' voltages giving spurious noise.

The 74 series chip feeds the 4520 as a pulse on the clock input. The output from the counter map onto the parallel inpus for the 4021 which is then read from the arduino. I was pleasantly surprised that it all seems to work. I suppose my bias is for hardware to sort out the hardware issues and the software to do the calculations rather than having to worry about hardware vagiaries.

[hazeii]

Ref. your question about doing it in software and reflecting on the need for multiple inputs, one approach that comes to mind to set up a timer as a relatively high-speed source of interrupts -  say 2k a second - and read the value of all your inputs in one hit. You can then tell which sensors are active by comparing the value read with the value last time.

For example, if you read an 8-bit port and you get 10001000 this time vs. 00001001 last time, you can see one input (top bit) has gone high, one input has gone low (bottom bit) and the rest haven;t changed. So you can read up to 8 inputs with a single instruction, also another nice thing about this approach is you effectively get debounce for free. The ISR routine will be really small and fast, so won't have any trouble keeping up (and if you want to handle loads of inputs, there are all sorts of optimisation tricks to split the processing between the ISR and the mainline code).

A pseudo-code ISR (non-optimised, no tricks) to maintain 8 counters would be something like:

ISR:
     Read 8 bit input port
     For N in 1 to 8
        if BIT 'N' is low AND previous BIT 'N' is high
          add 1 to counter N
       endif
    next BIT
   Save port data for next time
   Return

Some example optimisations if you want to make it really fast would be, say, unroll the loop, and use shifts/carry flag to detect bit changes.

[Feanor]

Some example optimisations if you want to make it really fast would be, say, unroll the loop, and use shifts/carry flag to detect bit changes.

The normal bit-wise way to detect a flag is to simply bitwise-AND the register with a mask.

So to increment a counter based on a flag in the LS bit, the pseudo-code is:

   If ( register & 0b00000001 ) counter++;

And I'd certainly not use a loop for only 8 bits.
That just takes up another register as a loop-counter, cycles to increment the loop counter, cycles to check the loop counter.
Simply in-line the code 8 times.
Nice, clear, de-buggable, fast.

[David Martin]

I'm not sure 2K/sec would be fast enough. It might work using an optical sensor where you can have half the rlre white ahd half black, but a magnet crossing a reed switch at potentially 100kph may well be missed. The pulse width one would need to capture is about 0.5 msec or less so I'd reckon on needing a higher frequency sampling rate to drive the interrupts, and then have to work out how long it takes to latch and read the shift register. I'm thinking that a cycle time of a maximum of 100usec would be needed - that would include data output to the upstream unit.

I'm pretty happy with the hardware vs software thing.  If the hardware works (which it seems to) then it guarantees catching every pulse to be read at leisure (within a certain period of time). The downside is more parts - are there any other downsides?

[Feanor]

No, not for a one-of design, no downsides at all.
All the signal conditioning done in HW leaving the SW to do it's business.
That's what I did in a similar situation: I used external latches so I could guarantee I would not miss an input pulse.


But in mass-produced devices, they want to shave the costs, and additional HW adds cost to every unit.
Doing stuff is SW has an initial development cost, but the per-unit cost is zero.
So it makes sense there.

[David Martin]

OK. I can ee that argument.

I'm currently attempting to lay out a PCB to hold 4 inputs - it is not small and it is struggling a little.

The 'software is eventually easier' case is quite strong..

..d

[Feanor]

To give another example:

We run geophysical instruments which measure things like rock porosity, resistivity etc down oil wells.   These transmit their data to the surface data acquisition systems via various telemetry systems, over 25,000 ft of wire.

Historically, it was the job of the logging engineer (me) to look at the data signal on a 'scope, and twiddle with gains and equalisations to try and make the signal look something like the original manchester data that was sent from downhole.   Once you'd done your best with the analog pre-processing, you'd hope that the manchester decoder was able to recognise the telemetry.   Sometimes, it actually worked.

Nowadays, it's all done in DSPs.
We make no attempt to gain / equalise the signal for a hardware decoder.
We simply stuff it into a DSP, digitise the mush, and let the DSP code figure it out.  Whch it does.

[Kim]

Black magic voodoo, I say!

[Feanor]

But here's an example of how doing things in hardware works:

The PIC system I designed had to do a data conversion that involved floating point maths.
That's not really something you can do on a PIC ( which didn't even have an ADDwithCARRY instruction ).
Yes, there were some libraries.
But this was a real-time system, and I could not even begin to figure the times through the routines.

It turned out, that only a limited subset of FP maths was required.
And what I did was use a hooting great lookup-table which was pre-calculated on a PC on an external ROM.
Clock out the inputs to a pair of registers which were the address inputs of the ROM ( 2 clock cycles );
Read the answer ( 3 clock cycles ).
Result: Complicated FP maths done in 4 clock cycles ( or similar ).

[David Martin]

I suppose it is picking the best tool for the job in hand. I've been trying to get a 2-sided PCB to layout with 4 inputs with not much success. Two works fine, three struggles but gets there. It shouldn't be that hard. Time to try some trickery..

[hazeii]

I'm not sure 2K/sec would be fast enough

As you've spotted, it depends on the mark/space ratio. A reed switch is only good up to several hundred hertz (assuming a square wave signal) , and there's this thing called the nyquist limit that says you only need to sample twice as fast to capture every event.

At 2k, you could expect to detect all pulses off at least 500 usec. Where the magnet is on the wheel, this should be fast enough (obviously you can improve the pulse width by moving the magenet/sensor as close to the axle as possible). On rollers, the pulse rate is much higher but equally the magnet is much closer to the axle - though experimentally I know an old DOS 486 colud keep up (more of a problem was the magnet flying off the rollers because I hadn't stuck it down well enough ).

- are there any other downsides?

As a fairly-old-school hardware engineer, hardware is  a lot more hassle when you hook up the power supply to the wrong voltage/wrong way round/fail to spot the solder bridge

One way I look at it is that a DIP chip is a DIP chip; the difference with a PIC or AVR chip vs. TTL/CMOS is that you get to decide what logic you want inside it. At a certain (this) level, the distinction between hardware and software becomes blurred and it's the engineer's call which approach to take.

[David Martin]

Surely the magnet woul be going faster on the rollers than on the wheel spokes as it i travelling the full distance wheras on the wheel it is travellng Rm/Rw (at least with the positioning I have for the magnet.)

[TimO]

... One way I look at it is that a DIP chip is a DIP chip; the difference with a PIC or AVR chip vs. TTL/CMOS is that you get to decide what logic you want inside it. At a certain (this) level, the distinction between hardware and software becomes blurred and it's the engineer's call which approach to take.

It's even worse with FPGAs, where you can write VHDL (or Verilog) which looks a lot like a computer program, but is actually a description of how the hardware works.  If you consider it to be a program too much, you can come unstuck!

We use FPGAs a lot now, our current instrument design has three in it, one is the CPU, and the other two do a certain amount of DSP in the front end electronics as well as some digital comms to the CPU (SPI links, because we've only got a very limited number of IO lines available).

In theory that should make it all cheap and easy to develop, but unfortunately the FPGA (and they're single shot programmable devices) cost over £10000 each, and the IP for the CPU code costs that much again.

[David Martin]

We were looking at FPGAs for massively parallel data processing. They definitely look interesting but I don't have the time or budget to really get to play with them[1]

[1] for which I mean, get a bright young postdoc who actually has more than a smidgin of  clue to do it, because I don't know enough to even get started. The guys across the road are in TimO's field and have dabbled in such things.. (Steve Parks and group)

[TimO]

Some of the FPGAs are a lot more reasonable to use, there are amateurs who use them, and they do allow you to create what is in effect reconfigurable hardware.  As long as you realise that you are modifying hardware, and it doesn't work quite the same as software (stuff like race conditions etc)

We just use relatively unusual devices because of the requirements of our environment, primarily their rad-hard features, which is what makes them single-shot and stupidly expensive (and they need to be immediately usable).

I've also used them in devices for doing massively parallel processing, interestingly enough, also with look up tables in ROM to do things that are difficult or almost impossible to do in sensible hardware (trigonometric functions, square roots, and that sort of thing)

I've never had anything directly to do with Steve Parks, although I'm guessing he may have been involved with the SpaceWire bods, who we do talk to from time to time (SpaceWire being one of the new up and coming technologies in spacecraft electronics).

[hazeii]

Surely the magnet woul be going faster on the rollers than on the wheel spokes as it i travelling the full distance wheras on the wheel it is travellng Rm/Rw (at least with the positioning I have for the magnet.)

Absolutely; but it's generally easier to get the magnet much closer to the spindle of rollers than it is to the axle of a wheel, with the result the closure angle is increased by more than the ratio of the circumferences.

For example, a wheel with a magnet between 2 spokes of a wheel may close the sensor for 15 degrees (or worse cas even less). The period at say 40mph is then 15/360 * 1/Revs/sec = 15/360 * (27/12*pi)/(40 * 5280/3600) ~= 5ms.

At the same 40mph a magnet on 8" training rollers next to the spindle can close the reed for 90 degrees or more, so 90/360 * (8/12*pi)/(40 * 5280/3600) ~=8ms. And since you control that hardware, it makes sense to mount the magnet as close as possible to the spindle of the rollers (a real gotcha here is, as TimO points out in #16 above, with a bar magnet you can easily get double counts or worse, especially at low speed, as each pole of the magnet goes past the reed - if it happens, a bit of re-positioning usually solves it).

Anyway, as you control the physical setup in this case you can compute the minimum period and design your hardware/software around that. On the other hand, for the general purpose case the closure can be much less than these examples; say you put the magnet on the edge of a flywheel on a wind or mag trainer, it can easily be doing over 100mph (40mph * roller diameter/flywheel diameter = 40*8/3 = 106.7mph!).

As an aside, worth noting that (from personal experience) if a magnet flies off a roller doing over 100mph, it makes for quite a missile.

[Kim]

There's an argument for using an optical sensor for that sort of thing...

[TimO]

In general though, on a bike, an optical sensor wouldn't stay clean very long (or it's target wouldn't).  Admittedly purely on rollers, doing stupidly fast speeds, it may make sense.

[Kim]

That's what I meant by "that sort of thing".  Reed switches make good sense on bikes (well, the ones without hub dynamos, which is most of them).

[Feanor]

Would not a hall effect sensor be less prone to bounce than a wobbly strip of springy metal in a reed switch?

[Kim]

I suspect the electronics (and power, in the case of your typical bike computer) required to drive a hall sensor make debouncing a reed switch a more attractive option.  Hall would work fine at Ludicrous Speed, though.