start/stop bits

[Dr_Doggy]

how can i use a start bit to start my "input clock" and a stop bit to stop and register it, is there simple logic circuit for this?

 

[Nigel Goodwin]

You need to be MUCH more specific about what you're trying to do, but start and stop bits are for asyncronous serial comms.

 

[Dr_Doggy]

i know, and i dont like!!

i am trying to intercept ir data an push it in to a shift register or such, or vice versa, push it out of a register across a IR link and then receive it in another register

 

[Nigel Goodwin]

You need to study how IR remote controls work, you require a processor to do anything with it, and it's nothing like RS232.

 

[Dr_Doggy]

ya, i did, but i have the same problem decoding the bits, since they use pulse width too, for logic 1's and 0's, similar to the servo thing, , but again how would i decode that pulse to a logic 0 or 1(on linear clocking)?

 

[Nigel Goodwin]

ya, i did, but i have the same problem decoding the bits, since they use pulse width too, for logic 1's and 0's, similar to the servo thing, , but again how would i decode that pulse to a logic 0 or 1(on linear clocking)?

Like I said, you do it in software, attempting to build hardware is going to be VERY expensive and time consuming.

 

[CafeLogic]

Like I said, you do it in software, attempting to build hardware is going to be VERY expensive and time consuming.

Tell that to this guy: **broken link removed**

 

[Dr_Doggy]

there's gotta be a way,

so far im thinking of shifting the data in to a register that clocks at a fraction of the pulse width, then using gates at the parallel outputs to establish the length(by finding the low bit),

 

[dknguyen]

That said, you're not even going about the most inefficient route in the right way. Rather than reinventing the wheel, you should at least look at how input compare modules work in MCUs. Just because you deem that there should be a way doesn't mean there is one, and if there is one it doesn't mean that it will meet your requirements for ease and laziness (not necessarily a bad thing, the field of engineering wouldn't exist if it were not for laziness).

A few problems with your idea is that it's highly redundant (shift registers? parallel searches? for time invariant events entering the system sequentially? That's seriously redundant and overcomplicated. Did you even think about the control logic required to pull off a parallel search? If it was actually required it'd be totally unfeasible to do with discrete components). It also doesn't take into account of the control logic that makes all those large prominent circuit components (mostly timers, counters, and comparators). Notice how registers aren't actually included in that list because they aren't actually needed yet you have them in your design while having none of the required components listed? It's a rather large indication of your underestimation of how much components and wiring it's going to take.

But anyays, this control logic is the most intensive to design and wire in the entire design. But being the least prominent and numerous components in the circuit they are the easiest to gloss over and forget about. Then, of course, there is the "decoding" part of the circuit that must produce a fixed period HI or LO digital pulses from a PWM stream where the HI and LO times are of variable.

Real input compares use a timer to measure the pulse width (nixing the shift register and parallel search). And they might have an analog input comparator too. And then there's the issue of control logic to reset your timer on the falling edge and start it on the rising edge. As for the issue of producing a digital bitstream from PWM pulses, you'd need a digital comparator working with a second timer IC that keeps track of when each the PWM pulse period starts and ends. This requires more logic to sync with the rising or falling edges of the input signal and is not the same as the syncing logic circuitry for the timer that records the widt of the pulse. And then you need circuitry so that the period timer can control when ouput of the digital comparator is so that it updates at the proper intervals to produce a fixed frequency digital bitstream.

The work required to wire up to a single digital comparator or a timer is several times more complicated than just wiring up a clock and regulator to a microcontroller. And the control logic can't even be compared to anything really. It's a bunch of bits and pieces lying around everywhere and a much more wiring between them. And if you trip up just once...good luck finding what's wrong and good luck rewiring it if you do. Microcontroller? Just reprogram - simpler to use, simpler to fix, and can do much more. And if the IR is modulated or the bistream is encoded, you can forget about doing anything discretely.

If you're trying to go for the cheapest, easiest and laziest route, a microcontroller is definately the route to take.

It's rather analogous to how flapping wings first appeared to be the easiest and most straightforward way to achieve flight because we lacked of full awareness of what is really required to pull it off. In reaity it takes way more complexity and effort to pull it off than fixed wing flight.

 

[dknguyen]

Oh yeah I should add that's only for converting a straight PWM bitstream into a fixed frequency bitstream of 0 or 1s depending on whether the pulse width is below or above a certain duty cycle.

If it's IR, there's probably some kind of encoding and/or modulation so you can forget about doing it with anything but a microcontroller. At that point it doesn't matter whether or not you can convert successfully convert the IR pulses into a bitstream because you still have to decode it and that takes WAY more logic than you can build discretely. Depending on the IR link, you *might* be able to find an ASIC to do the encoding/decoding for you rather than a microcontroller, though the chances are rather slim since most of those said protocals require a microcontroller anyways even after decoding for you to be able to do anything with the bitstream. Those ASICs are usually made to work with a processor rather than standalone in vacuum.

he one exception is if you are modulating the IR transmitter yourself in the crude PWM duty cycle threshold scheme I just described (which contains no encoding or modulation).