FlexBasic SIRC Spin program usage

Rsadeika · 2020-07-09 15:17

I am trying to use a Spin program developed by Tom Doyle called IR_Remote_NewCog.spin, which I am calling sirc.spin, in a FlexBasic program, not having much success.

The below program, sirc.bas, compiles, but it is not working as expected. When I run the program, p26 turns on, but pressing other keys on the remote, does not turn off p26. Not sure why p26 is turning on, it is not supposed to go on until a button on the remote is pressed. I am using the FLiP module for this experiment.

I am wondering if there is an easier way to do this. The OBEX is a disaster for trying to find things now, let alone downloading. I think Jon MacPhallen had some sirc objects, but could not find those. The SIRC PROPGCC code, has not shown up in FlexGUI, so I cannot use that.

I guess I could try to convert the Tom Doyle program from spin to FlexBasic, but I think it should be made easier to just use existing spin objects.

Thanks

Ray

sirc.bas

dim sirc as class using "sirc.spin"

dim IRcode,lcode as byte
sirc.Start(16,IRcode)

do
	if IRcode <> sirc.NoNewCode then
		sirc.Start(16,IRcode)
		lcode = IRcode
		
		select case lcode
			case sirc.one
				pinhi(26)
			case sirc.two
				pinlo(26)
		end select
	end if
	pausems(250)
loop

{{
      IR_Remote_NewCog.spin
      Tom Doyle
      2 March 2007
      Panasonic IR Receiver - Parallax #350-00014
      Receive and display codes sent from a Sony TV remote control.
      See "Infrared Decoding and Detection appnote" and "IR Remote for the Boe-Bot Book v1.1"
      on Parallax website for additional info on TV remotes.
      The procedure uses counter A to measure the pulse width of the signals received
      by the Panasonic IR Receiver. The procedure waits for a start pulse and then decodes the
      next 12 bits. The entire 12 bit result is returned. The lower 7 bits contain the actual
      key code. The upper 5 bits contain the device information (TV, VCR etc.) and are masked off
      for the display.
      Most TV Remotes send the code over and over again as long as the key is pressed.
      This allows auto repeat for TV operations like increasing volume. The volume continues to
      increase as long as you hold the 'volume up' key down. Even if the key is pressed for a
      very short time there is often more than one code sent. The best way to eliminate the
      auto key repeat is to look for an idle gap in the IR receiver output. There is a period of
      idle time (20-30 ms) between packets. The getSonyCode procedure will wait for an idle period
      controlled by the gapMin constant. This value can be adjusted to eliminate auto repeat
      while maintaining a fast response to a new keypress. If auto repeat is desired the indicated
      section of code at the start of the getSonyCode procedure can be commented out.
      The procedure sets a tolerance for the width of the start bit and the logic level 1 bit to
      allow for variation in the pulse widths sent out by different remotes. It is assumed that a
      bit is 0 if it is not a 1.
      The procedure to read the keycode ( getSonyCode ) is run in a separate cog. This allows
      the main program loop to continue without waiting for a key to be pressed. The getSonyCode
      procedure writes the NoNewCode value (255) into the keycode variable in main memory to
      indicate that no new keycode is available. When a keycode is received it writes the keycode
      into the main memory variable and terminates. With only 8 cogs available it seems to be a
      good idea to free up cogs rather than let them run forever. The main program can fire off
      the procedure if and when it is interested in a new keycode.
        
}}


CON

  _CLKMODE = XTAL1 + PLL16X        ' 80 Mhz clock
  _XINFREQ = 5_000_000

  NoNewCode    =  255               ' indicates no new keycode received

  gapMin       =   2000             ' minimum idle gap - adjust to eliminate auto repeat
  startBitMin  =   2000             ' minimum length of start bit in us (2400 us reference)
  startBitMax  =   2800             ' maximum length of start bit in us (2400 us reference)
  oneBitMin    =   1000             ' minimum length of 1 (1200 us reference)
  oneBitMax    =   1400             ' maximum length of 1 (1200 us reference)

  ' Sony TV remote key codes
  ' these work for the remotes I tested however your mileage may vary
  
  one   =  0
  two   =  1
  three =  2
  four  =  3
  five  =  4
  six   =  5
  seven =  6
  eight =  7
  nine  =  8
  zero  =  9

  chUp  = 16
  chDn  = 17
  volUp = 18
  volDn = 19
  mute  = 20
  power = 21
  last  = 59


VAR

  byte  cog
  long  Stack[20]  



PUB Start(Pin, addrMainCode) : result
{{
   Pin - propeller pin connected to IR receiver
   addrMainCode - address of keycode variable in main memory
}}

    stop
    byte[addrMainCode] := NoNewCode
    cog := cognew(getSonycode(Pin, addrMainCode), @Stack) + 1
    result := cog



PUB Stop
{{
   stop cog if in use
}}

    if cog
      cogstop(cog~ -1)


    
PUB getSonyCode(pin, addrMainCode) | irCode, index, pulseWidth, lockID

{{
   Decode the Sony TV Remote key code from pulses received by the IR receiver
}}

   ' wait for idle period (ir receiver output = 1 for gapMin)
   ' comment out "auto repeat" code if auto key repeat is desired
   
   ' start of "auto repeat" code section
   dira[pin]~
   index := 0
   repeat
     if ina[Pin] == 1
       index++
     else
       index := 0
   while index < gapMin
   ' end of "auto repeat" code section

   frqa := 1
   ctra := 0
   dira[pin]~
   
   ' wait for a start pulse ( width > startBitMin and < startBitMax  )
   repeat      
      ctra := (%10101 << 26 ) | (PIN)                      ' accumulate while A = 0  
      waitpne(0 << pin, |< Pin, 0)                         
      phsa:=0                                              ' zero width
      waitpeq(0 << pin, |< Pin, 0)                         ' start counting
      waitpne(0 << pin, |< Pin, 0)                         ' stop counting                                               
      pulseWidth := phsa  / (clkfreq / 1_000_000) + 1    
   while ((pulseWidth < startBitMin) OR (pulseWidth > startBitMax))

   ' read in next 12 bits
   index := 0
   irCode := 0
   repeat
      ctra := (%10101 << 26 ) | (PIN)                      ' accumulate while A = 0  
      waitpne(0 << pin, |< Pin, 0)                         
      phsa:=0                                              ' zero width
      waitpeq(0 << pin, |< Pin, 0)                         ' start counting
      waitpne(0 << pin, |< Pin, 0)                         ' stop counting                                               
      pulseWidth := phsa  / (clkfreq / 1_000_000) + 1
      
    if (pulseWidth > oneBitMin) AND (pulseWidth < oneBitMax)
       irCode := irCode + (1 << index)
    index++
   while index < 11

   irCode := irCode & $7f                                   ' mask off upper 5 bits

   byte[addrMainCode] := irCode

JonnyMac · 2020-07-09 15:35

Here's my SIRCS RX object -- I assume that's the side you want (I have a separate TX object).

Rsadeika · 2020-07-09 16:14

Thanks JonnyMac. I just had a chance to look at the code, melding it into FlexBasic, or even FlexC, and having it work as expected, will not be as easy as I had hoped.

So, the idea of having Spin objects available, for FlexGUI, does not lead to a plug and play scenario. You still have to know something, a lot, about the Spin language, and PASM in some cases. Not sure what the best approach for doing this is. If I have to know a lot about Spin, then why not just use Spin? But I am starting to like FlexBasic, and I am not sure if I know enough to start creating drivers in FlexBasic. I think at this point only Eric knows enough about FlexBasic to even consider doing a lot of drivers in FlexBasic. And if he does that, then it might as well be available for FlexC.

This is a heck of a dilemma, I am considering getting the new P2 Eval board, but it seems like there is long way to go, before any substantial code comes along to really use the board properly.

Ray

JonnyMac · 2020-07-09 16:48

So, the idea of having Spin objects available, for FlexGUI, does not lead to a plug and play scenario.

The idea of multi-language coding seems alluring, but -- in my opinion -- is impractical; it's kind of like mixing metric and Imperial units in a design. A while back I ran a test where I wrote a demo program in C and had it call my Spin objects. It worked, but one of those objects was tuned to the Spin compiler timing, so I had to modify it.

I'm a simpleton; I program in Spin and PASM and am happy as a clam. It's not that I won't "play" with other ideas, but for client work, Spin and PASM have always done the job, and I've never once had a client question my use of a "non-standard" language. In the end, they only care that their product works.

This is a heck of a dilemma, I am considering getting the new P2 Eval board, but it seems like there is long way to go, before any substantial code comes along to really use the board properly.

I waited until Spin was available to really jump into the P2, and now I'm having a blast -- I really like it. Yes, it will take a while for a large library to be built up, but then, if you're expecting every possible object/library you ever wanted to be available when you want it, in my opinion you're going to end up disappointed. You've been around the forum a long time -- crafting a library that you need should be second nature. Again, my opinion.

ersmith · 2020-07-09 16:49

Ray, look at the comments for the Start(Pin, addrMainCode) method. "addrMainCode" should be the address of a byte, not just the byte. So you need to do "sirc.Start(16, @IRCode)".

whicker · 2020-07-09 17:20

Rsadeika wrote: »

Thanks JonnyMac. I just had a chance to look at the code, melding it into FlexBasic, or even FlexC, and having it work as expected, will not be as easy as I had hoped.

But I am starting to like FlexBasic, and I am not sure if I know enough to start creating drivers in FlexBasic. I think at this point only Eric knows enough about FlexBasic to even consider doing a lot of drivers in FlexBasic. And if he does that, then it might as well be available for FlexC.

This is a heck of a dilemma, I am considering getting the new P2 Eval board, but it seems like there is long way to go, before any substantial code comes along to really use the board properly.

Ray

Don't give up! The promise of mixing C, Basic, Spin, and Spin 2 is there. There just might be little typos like ersmith just posted. Getting the first one working is always the hardest part.

Rsadeika · 2020-07-09 17:48

You've been around the forum a long time -- crafting a library that you need should be second nature.

I have been using SimpleIDE, so their has been no need for creating my own library. And if you do that, their is no easy way for other people to use your library, not in an easy manner that is.

Since I like FlexGUI, I might try doing some Spin work, again. First project, I guess, would be the Tom Doyle IR_Remote_NewCog.spin program. Then I could try creating some kind of Spin library with a lot of the methods that are normally used, when programming.

I still think that Spin is not my first choice for some easy program prototyping. I have found that using Python scripts was easier than doing something in Spin. But I started to dislike Python because of that indentation, caused a lot of problems, when you missed some indentation.

This is almost like starting from scratch again, all the user IO routines that are readily available in FlexBasic and FlexC will have to be crafted in Spin. Did not see any libraries for that kind of stuff, readily available.

When I look at the Propeller scheme of things, empirically, there is a lot of stuff, but its like a bunch of bits and pieces all over the place. You would think that after fifteen years or so, everything would have been sorted out to make programming the Propeller an easy task, for the old timers and some of the new people that are showing up.

Ray

FlexBasic SIRC Spin program usage

Comments