Does an IR sensor (tsop1738) or something that creates a series of bits exist
I finally put everything together into a package called 'IRRemote'.
The 'Prog. Sequencer' is a script as described above, having a bunch of sequences selected by pressing one of the buttons. That's all been put into a package. There are just some minor problems. First of all the package in 'Board Modus' looks fine, but when I use that package, most of the labels are not upright anymore
Second, the overall length of the sequences is less than a 100ms, but if I press a button it takes a couple of seconds before all the pulses of the sequencer have appeared at the output. If I just take the sequencer and a push button at D0 pulling the input to high the pulses show up as fast as expected. What makes it so slow? Is it the extra 74HC147 or putting it into a package?
Nice job.
First of all the package in 'Board Modus' looks fine, but when I use that package, most of the labels are not upright anymore
I see... the only solution I can see right now is placing the switches upright in the circuit, now they are rotated -180º.
Second, the overall length of the sequences is less than a 100ms, but if I press a button it takes a couple of seconds before all the pulses of the sequencer have appeared at the output. If I just take the sequencer and a push button at D0 pulling the input to high the pulses show up as fast as expected. What makes it so slow? Is it the extra 74HC147 or putting it into a package?
It is difficult to know without watching the code and circuits, but putting it into a package or using an extra 74HC147 should not be a problem.
The "led driver" could cause a noticeable slowdown and I don't see why it's needed here.
I would just remove all this components:
There are other considerations, for example if simulide is compiled for debug it will be much slower, maybe 10x slower or something like that.
Then there are some other optimizations, for example would be more efficient using an encoder (DecToBcd) instead of a 74HC147 + inverters.
The "led driver" is just for lengthen the pulses for the led to show a transmission. I can easily skip that part. I wasn't aware of the DecToBcd encoder. I'll try that too.
The 'led driver' made a big difference. Without it, it's a lot faster. Just to make sure I understand, the slow simulation was still correct, it was just very slow?
It is difficult to know without watching the code and circuits.
I guess "slow" means slow in "our time", but correct in simulation time, but I'm not sure.
Have a look at the data at the bottom panel : speed, simulation time, etc.
The "led driver" by itself should not be a big deal in a average computer.
If Simulide is not compiled in debug mode then probably that capacitor has "Autostep" activated.
BTW: I'm going to delete "Autostep" functionality right now, it causes more problems than benefits.
The encoder part is not critical because it runs at "human speed".
Yes, slow means 'slow' in human time. I fed the output into a ATTiny85 and it was able to decode the signal propperly. Hence, the simulation was working. Simulide shouldn't be compiled in debug mode. Is there any way to figure that out? Just in case I overlooked it.
There is another minor thing that puzzles me. The IRRemote uses the Sequencer for creating the pulses. The sequencer itself reads the pulse length from a firmware stored in PGM and than calls outPort.addSequence(). That all happens during reset of the Sequencer, so it doesn't affect simulation speed. I could have hard coded the sequence, but I thought it might be smarter to put that in a hex file. The sequencer itself is used by IRRemote like shown above. It's all working perfectly so far, but would it be possible to load the hex file into the IRRemote which would basically pass it on to the sequencer? That way I could build a generic remote control which can be configured by a hex file.
Simulide shouldn't be compiled in debug mode. Is there any way to figure that out? Just in case I overlooked it.
That depends on how you compile it.
If you create a copy of build_XX folder and just: qmake and make it should compile for release.
In Linux, release binary should be around 9 MiB and debug around 125 MiB for current trunk.
would it be possible to load the hex file into the IRRemote which would basically pass it on to the sequencer?
You can "expose" any component in the subcircuit: https://simulide.com/p/subcircuits/#exposed-components
Then in the IRRemote: right-click->Name of the script component->Load Firmware
I need to come back to this old thread. I did some more modifications on the scripted component discussed in this thread. The use of sequences has proven to be a good choice. Whenever a button is pressed a sequence is triggered. This cannot be faster than every 50ms, but what happens if the sequence takes longer than 50ms and the button is still pressed? Will it quit the current sequence and start it over again?
but what happens if the sequence takes longer than 50ms and the button is still pressed? Will it quit the current sequence and start it over again?
Once a sequence is started it will ignore new triggers until it's finished.
Quote from arcachofo on January 8, 2024, 5:38 pmbut what happens if the sequence takes longer than 50ms and the button is still pressed? Will it quit the current sequence and start it over again?
Once a sequence is started it will ignore new triggers until it's finished.
And is there any way to check if a sequence is still in progress? Or even schedule a new sequence after it?
The reason I'm asking is because of the way some ir remote controls work. A sequence can easily take more than 50 ms, e.g. the NEC protocol takes 68ms. If the same button is still pressed after the initial sequence has been send, the ir remote control will not send the same sequence again, but instead sends a short repeat command telling the receiver that the button hasn't been released. That repeat command will start roughly 100 ms after the initial command was started. That 100ms is perfect for this protocol if the button is checked every 50ms, but there are other protocols with different timings. Hence, it would be nice to have some more information about the sequence, e.g. if it is still running, how long it takes, when it was finished, etc.