I have been taking some time reading the asm on datasheet of the pic16f, the block diagram makes alot more sense now of what is going on under there! but also so many questions, for starts I understand that the w register is the one feeding the alu and k is when passing in a literal value,
but what are the f and b registers? i did not see them in the block diagram.
also I am aware of what the stack basically is and how to keep it from overflowing .... but how does it actually work, what values is it storing there when i go in to each layer?
also I am looking at the descriptions of the operands and even those are confusing even if they are in English, such as:
Inclusive OR W with f
Swap nibbles in f
Rotate Left f through Carry
and where do the answers go after the operation is done.....ie..what/where is the d register, or is that exactly what d is defining?
I know we have working tutorials of this stuff, but is there one kicking around that explains each of the operands in a little more detail?
Hi,
About stack overflow, what i always did was just make sure i dont call too many subroutines. I dont remember now how deep the stack was, but if i call a subroutine that calls a subroutine that calls a subroutine, that's usually enough.
About getting something to 'repeat', i am not sure what you are trying to repeat.
If you have to repeat the transmit code, just run it again but only when the next frame starts. You had to have measured the frame time or else guessed (#6 below).
Also, some codes do not repeat exactly they have a different code for the repeat frame.
After studying several remotes now i find that they can vary quite a lot although they do have similarities.
All that i have examined have the following properties:
1. A start burst.
2. A short length burst.
3. A long length burst (often twice the short length burst).
4. A short silence delay.
5. A long silence delay (often twice the short silence delay).
6. A certain frame repeat period (may have longer silence delay).
7. Either the same code or different code for the repeat signal.
8. The carrier frequency.
9. The code set.
If you can discover the above for a remote you can control the device it is meant for.
With #9 the code set can be small or very large. With a large code set it may be harder to generate codes without detecting them from the old remote first, but with a small code set it is relatively easy to generate codes even without having the old remote just by testing each code to see it's effect on the device.
Most of the codes that have a variable burst time do not have a variable delay time, and those that have a variable delay time do not have a variable burst time although the start pulse may be different. So codes look like this (H=burst 1 period, L=silence one period):
HHLHHLHLHLHHL
or like this:
HLLHLLHLHLHLLH
but not like this:
HHLHHLHLLHLLHH
but i suppose that could be possible with remotes i do not have presently.
Because some of the codes are so simple to read on the scope, sometimes i just count the short bursts and sometimes the short and long bursts and create the programmed code that way. For example, if i see the start pulse, then 5 short bursts with 5 short delays, then 2 long bursts with 2 short delays, i would code that as simply as:
1111122
although this can also be coded as:
511
but that is for transmit codes that always have the same length delay periods (except at the start and end).
But anyway, you dont have to stick with the hex coding scheme if you dont want to have to keep converting to and from hex. If you have a short pulse and code that as 1 and then a long pulse and code that as 2, you've just coded the pulse width itself for example. Of course with only two different lengths you can code these as 0 and 1, so your code would end up being in binary anyway: 01110111, etc., and because each remote has it's own start and frame period, you always apply that anyway. Sometimes the address part is the same too for each and every code, so you could send that separately.
What else i find is that very short delays inserted into the stream dont seem to matter even though they dont belong there. For example, if you call a subroutine to generate the start signal, then call a different routine to send the code, then another routine for the ending sequence, the time it takes for each call and return dont seem to matter to the device. I never investigated how much i could get away with though.