Find the bug (SPIN/PASM) in signal genarator

MagIO2

Hi there! Here is one of the rare occasions where I have to ask for help. I seem to be to blind to find the bug here.

But let's start at the beginning. The current work is for those kind of remote power switches: http://avr.xn--brke-5qa.de/Funksteckdosen.htm
(sorry, it's in german, but you can at least see what I mean) These are using an HX2262 for sending 12 tristate "bits".

I simply removed the sender PCB from such an remote control and connected the input pin of the sender to the propeller.

So I implemented a signal generator which needs
a) a timing table and
b) the signal being encoded in a string

For example:

DAT
highTime      long 120,  40, 1240,   0,0,0,0,0,0,0,0,0,0,0,0,0
lowTime       long  40, 120,   40,   0,0,0,0,0,0,0,0,0,0,0,0,0

...
  ' load the timing table into COG
  remote.exec( remote#CMD_SETTAB, @highTime )

The values for highTime and lowTime have to be multiplied by 10 to get the microseconds.

The following code will then generate a signal:

    remote.exec( remote#CMD_SIGOUT | 16<<16, string("aAbBaAaAaAbBaAaAaAbBaAbBaAbBaAaAaAbBaAbBaAaAaAbBcCaAbBaAaAaAbBaAaAaAbBaAbBaAbBaAaAaAbBaAbBaAaAaAbBcCd") )

Easy to read: "a" generates a low and waits for the first lowTime, "A" generates a high and waits for the first highTime, "b" generates a low and waits for the second lowTime .... If the stringend is reached or if a time in the table contains 0 the COG should go back into wait-for-next-command-mode.

The code generated the signal as it should be, but the 3.3V of the propeller were not enough to enable the sender. So I added a FET for the level shifting. But this inverts the signal. In theory the code is able to generate an inverted signal - and actually it really works with one little but important exception!

Now comes the problem: It worked perfectly well when the whole signal was not inverted and the last letter in the signal string was a "d" - and had to be a "d". But with an inverted signal the last letter sould be the "C" (or a "D") and with an uppercase letter the signal-generation simply stops after the first cycle. I don't see why!

Thanks for your time!

MagIO2

Ok ... nevertheless ... here is an update from my side.

It's working pretty good! I added functions like setOnOff, setHouse and setNumber which generate the signal string. So, no more limits, I can control all power plugs in the house with my propeller. Now it's just a little step to connect the propeller to my RasPi running a webserver.

The only problem with the bug is that it keeps the transmitter running all the time. So, still feel free to help me finding the bug ;o)
Thinking about it, this might be a security feature. If one transmitter always sends the 434MHz signal no other transmitter can switch things on or off.

I think I'll also have a closer look into one of those receivers. Maybe receiving is as easy as sending. Then one can still use the remote controls but the prop stays updated about the status of each power plug.

Here is a picture of my setup.

MagIO2

Hmmm .... no replies .... how do I have to read this?


PS: Oh, I see ... nobody coding in Spin/pasm anymore ... everybody switched to Forth ;o)

kuroneko

MagIO2 wrote: »

Now comes the problem: It worked perfectly well when the whole signal was not inverted and the last letter in the signal string was a "d" - and had to be a "d". But with an inverted signal the last letter sould be the "C" (or a "D") and with an uppercase letter the signal-generation simply stops after the first cycle. I don't see why!

I assume the archive contains the non-inverted version? What needs to change to get to the inverted one? Just changing case? What does stops after the first cycle actually mean, i.e. processing one signal string or something else?

MagIO2

Thank you very much for your time! I'm close to simply rewrite the whole signal generator code, but nevertheless it would also be good to know what goes wrong.

Yes, the archive is the working version. It generates the signal on PIN 16 and gives a trigger signal on PIN 24.
You simply have to replace or remove the "d" at the end of the signal string (replace with "D" / remove means that "C" is the last letter - both uppercase, both have the same problem).

Stop after the first cycle means that there is no more signal output. And it won't go back to a functioning mode if it once got a string with a last letter being uppercase. The COG must be running because it still accepts new commands.
-SPIN (execute) checks the buffer whether there is still a command active and waits if so
-SPIN sets parameters and then sets command long to a valid command
-PASM polls the command long until it found something different than 0
-PASM executes the command and sets the command long back to 0

From my point of view the code should behave nearly the same way regardless of having "d" or "D" at the end, because there are only some instructions covered by an IF_BE or IF_AE to make the difference.

kuroneko

MagIO2 wrote: »

... it would also be good to know what goes wrong.

mov   cmdjmp, origjmp
                                                ' [COLOR="#020FC0"]cmdjmp = $5C7C000B[/COLOR]
        [COLOR="orange"]add   cmdjmp, cmd[/COLOR]
                                                ' [COLOR="#020FC0"]cmdjmp = ???[/COLOR]
        rdlong par1, spinBuf1                   ' get the parameter

cmdjmp  jmp   #jmplist-1
origjmp jmp   #jmplist-1

What exactly does this insn do to cmdjmp, i.e. what's there after the add using your example SIGOUT command?

MagIO2

Waaaaaahhhhhh!

I still have to digest why it is related to the uppercase letter because the bug is on a totally different place and the cmd is actually the same in both cases.

Well .. I use the kind of command dispatcher in several drivers, but this is the first time I thought it would be a good idea to use the not needed bits of the long for other things. Well .. and unfortunately it worked for the first time.

Thanks alot ... I owe you a drink!

MagIO2

For all, here is the corrected version of the SignalDriver. Once I have finished this project I'll clean up the driver and add it to the ObjectExchange. For the time being feel free to use this version and just ask here if you have any questions.

I could imagine 2 different versions:
one high performance version which goes down to 2 or maybe 1 microsecond
one parallel version which allows to generate 2, 4 maybe 8 signals at the same time


PS: Sorry, I uploaded a debug version of the driver. Now there is the really working version.

kuroneko

MagIO2 wrote: »

I still have to digest why it is related to the uppercase letter because the bug is on a totally different place and the cmd is actually the same in both cases.

For starters, an uppercase letter sets the carry flag. The command in question changes the jump insn from

jmp     #jmplist-1

to

if_nc   jmpret  [COLOR="#FFA500"]$000[/COLOR], jmplist+1

This explains why it works for lowercase tails (indirect jump, which is actually more efficient) and doesn't for uppercase tails. The latter will end up over origjmp and rt at address 0 again which at this point is a nop (reused for command and potential return location from a lowercase tail call). So it simply falls back into the command loop.

MagIO2

Thanks again Kuroneko!

I have to apologize, I uploaded the signal driver with some debug code enabled instead of the real working version 2 posts above. The debug version simply had some fixed timings which allowed to simply see the signal with an LED because it gets darker during transmission.

I updated the driver and now it contains the working version!

Now I'm working on the receiver side. Already killed one ;o) Thought it would be as easy as attaching 12V to the right PINs of the HX2272. Unfortunately current limit was set to something around 3A which turned the HX2272 into a heater immediately ;o)

Maybe I shall start another thread for this, as it's no longer about a question? But only if there is interest.