Question about HC-8+ and Running show from SD card.

[youngti]

Thank you, I am willing and "anything worth doing is worth doing well".  And by stout, a lot of amps right?

[JonnyMac]

Yes. You might use a hefty 6v battery. The problem is current surging upsetting the onboard electronics; these things don't bother batteries.

[youngti]

okay, just in case..........when might you be gettin more HC-8+'s in?

[youngti]

I am looking at some power supplies I have collected over the years.  I have one that is an ATX300W power supply.  It can produce on one side of it 5V@30A.  I know you said 6 to 7.2V but do you think the 5V high amp would work? Or is it the Voltage that is more important?

[JackMan]

5v is fine, you're only powering the servo header once that trace is cut. One thing I've done with my 3-axis Bucky Skulls (quite heavy also) is install a spring to counter balance the force needed when the servo raises the skull. Up/down (nod) is the only area where this is usually a problem with a heavy skull.

[youngti]

Okay so that solved that issue.  I can move all servos with the VEX.  Found out that using the kingston SD card when I would press record it would start but then hang.  Using a SanDisk, works perfectly.

And i also use the spring in the back to support the nod servos. 

Thank you.

[youngti]

I spent the better part of last weekend and Monday night reading the Propeller manual and stating to read two books about spin.  Programming and customizing the multicore propeller Microcontroller (the official guide) and Programming the propeller with spin a beginners guide.  Yes that is smoke coming out of my ears.

Reading the manual I could see some of the commands that I would need to use; the DATA and File command to get the  vixenNN.bin loaded, the cnt+ and waitcnt to control how long the first show plays before it is interupted by  the pir.  But I am not sure how to put it all together.  I wrote down what I thought the connections should be and what I would like the prop to do.  I didn't want to ask but I think I need help writing this first spin program.

This is what I think the connections should be;
Pin set-up
   TTL out0 = Left/Right servo
   TTL out1 = Jaw servo
   TTL out2 = Nod servo
   TTL out3 = Head Tilt servo

   TTL out4 = LED eyes, state is either on or off.
   TTL out 5 = PIR

DMX set to 1,2,4,8 on for 180 degree servos
Use the EFX-TEK uSD adapter and code
    vixen00.bin &  vixen01.bin on card and set for programed movements using the VEX.

Use AP-16= for sound connected to the serial pins
  SFX00.wav and SFX01.wav the only files on the card.

And this is what I think should happen (would like to happen);

Power on,
  there is a delay of say 15 seconds before the first show starts
  Show 1 starts and then plays for say 15 seconds before it accepts trigger from PIR

  IF activity on PIR then play show 2, else continue show 1


PIR triggered then play show 2, show 2 ends and there is a 4 second delay, then Show 1 start again

I have been looking at the code you have written and I'm not sure I understand some of it.  For example you have this in CON section

con

  RX1     = 31                                                  ' programming / debug port
  TX1     = 30
 
  SDA     = 29                                                  ' eeprom
  SCL     = 28

  OUT_EN  = 27                                                  ' outputs enable pin (low)     
 
  SIO     = 26                                                  ' TTL serial io
 
  RX2     = 23                                                  ' RS-485 port
  RX2_EN  = 22
  TX2_EN  = 21
  TX2     = 20

  R_LED   = 18                                                  ' bi-color LED
  G_LED   = 17

  OUT7    = 15                                                  ' outputs
  OUT6    = 14   
  OUT5    = 13
  OUT4    = 12
  OUT3    = 11
  OUT2    = 10   
  OUT1    =  9
  OUT0    =  8
         
  OPT_BR  =  7                                                  ' options switches
  OPT_A1  =  6   
  OPT_A0  =  5
  OPT_SM  =  4

  DMX_A8  =  3                                                  ' high-bit off DMX address

  DO_165  =  2                                                  ' control lines for 74x165
  CLK_165 =  1
  LD_165  =  0

I understand that these are constance being set-up but it looks like you start at value 0 from bottom and end at 31.  From my reading these look like the outputs on the propeller, is this correct?  Sorry for such a long post but I am trying to understand this.  I would eventually like to get to the point of writing my own code from scratch.

[bsnut]

I have been looking at the code you have written and I'm not sure I understand some of it.  For example you have this in CON section

con

  RX1     = 31                                                  ' programming / debug port
  TX1     = 30

  SDA     = 29                                                  ' eeprom
  SCL     = 28

  OUT_EN  = 27                                                  ' outputs enable pin (low)     

  SIO     = 26                                                  ' TTL serial io

  RX2     = 23                                                  ' RS-485 port
  RX2_EN  = 22
  TX2_EN  = 21
  TX2     = 20

  R_LED   = 18                                                  ' bi-color LED
  G_LED   = 17

  OUT7    = 15                                                  ' outputs
  OUT6    = 14   
  OUT5    = 13
  OUT4    = 12
  OUT3    = 11
  OUT2    = 10   
  OUT1    =  9
  OUT0    =  8
         
  OPT_BR  =  7                                                  ' options switches
  OPT_A1  =  6   
  OPT_A0  =  5
  OPT_SM  =  4

  DMX_A8  =  3                                                  ' high-bit off DMX address

  DO_165  =  2                                                  ' control lines for 74x165
  CLK_165 =  1
  LD_165  =  0

I understand that these are constance being set-up but it looks like you start at value 0 from bottom and end at 31.  From my reading these look like the outputs on the propeller, is this correct?  Sorry for such a long post but I am trying to understand this.  I would eventually like to get to the point of writing my own code from scratch.

As you see, Jon is using constants so he doesn't need to rewrite the or have to remember where he as the I/O assigned to and he also uses methods to do also handle things like turning a output on the HC-8+. Let me give you these examples:

1) Coding without the constants.

outa[8] := 1     ' turn on pin 8 that is connected HC-8 OUT0

2) Coding using the constants.

outa[OUT0] := 1   ' turn on pin 8

3) Coding using the methods and the constants. Which is the same thing as the above examples.

high(OUT0)

pub high(pin)

'' Makes pin output and high

  outa[pin] := 1
  dira[pin] := 1

And, since you have been reading the one book that I have "Programming and customizing the multicore propeller Microcontroller (the official guide)" You may have see how the Spin code is structured in Methods and Objects as well shown in that book and also in the template file that Jon did for HC-8+.
   

[youngti]

I sort of understand that, but I was wondering why they are numbered sequentially 0-31.

Such as;
out0 = 8
out1 = 9
out2 = 10
....
TX2 = 20
TX@_EN = 21,  etc.

[JonnyMac]

From my reading these look like the outputs on the propeller, is this correct?

Yes.

The Propeller chip has 32 IO pins, numbered 0 to 31. We can do anything we want with pins 0 to 27; 28 through 31 have special use as you see in the IO definitions section.

con

  RX1     = 31                                                  ' programming / debug port
  TX1     = 30
 
  SDA     = 29                                                  ' eeprom
  SCL     = 28


The rest of that section defines how we use the Propeller's IO pins on the HC-8+ and the support routines allow you to do the things you typically would.

[youngti]

Thank you for the information, of course I have more questions.  I was comparing the spin language reference to your hc-8_vex_recording.spin code and I have a few questions.

  _clkmode = xtal1 + pll16x           Set external low speed crystal and multiply frequency by 16  Correct? 
  _xinfreq = 5_000_000                                          ' 5MHz crystal (from above it is now 80Mhz)

  CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq   seems to be doing a bitwise shift to right.  Can you explain this line and the two below? 
  MS_001   = CLK_FREQ / 1_000
  US_001   = CLK_FREQ / 1_000_000

pub main | svocfg, state, t, ch, pos, tix, atimer   Are these declarations of variables used in the pub main section?

Looks like I will want to reuse the following objects from you;
Fsrw.spin, efx_servo8.spin, &  safe_spi.spin

So in the object section;
obj

  sd    : "fsrw"                                                ' for file i/o-  fsrw calls the object safe_spi.spin
  servo : "efx_servo8"                                          ' servo output

Would I use this section of code to read from the vixenxx.bin?

'' Reads n bytes from file to buffer at bpntr
'' -- returns true if good read

  check := \sd.pread(bpntr, n)
  if (check == n)
    return true
  else
    return false

You had mentioned that for the show it would be better to run the AP-16+ from the serial rather than out7. You were talking about the 3 pin serial and not the RS-485 right?
Could you give an example of the code?

Wondering if the PIR should be on the input TTL's and not the Output?

[JonnyMac]

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000     

These lines (or variations) are required by every program as they set the speed at which the Propeller runs. This is different from the SX which ran at a fixed frequency (crystal). The Propeller has a PLL (phase locked loop) circuit that can multiply the input. Advanced applications can even change the oscillator and PLL setting on-the-fly. I helped Parallax with the code for the DEFCON badge and in that application there is a timer that will cause the device to drop to very low power mode (using the internal RC oscillator at its slowest speed).

The first line tells the system that an external crystal is being used and that its frequency will be multiplied by 16. The second line specifies the speed of the connected crystal. Most applications will use a 5MHz crystal, though the AP-16+ actually uses a 6.25MHz crystal for additional speed when accessing and playing audio files.


  CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq
  MS_001   = CLK_FREQ / 1_000                   
  US_001   = CLK_FREQ / 1_000_000               

These are convenience constants and the math of the first line is a bear to explain (I didn't originate this code). Please accept that in the end the value of CLK_FREQ will match the system speed, in this case 80MHz. Why bother? Because there are code techniques where using a constant value is much faster than not. We can access system frequency at run-time, but code will run faster when we use a constant. If the clock speed doesn't change during the program (as is the cast most of the time) it's best to use a constant.

The other two lines calculate the number of clock ticks in two convenient periods; these are used with the waitcnt keyword.


pub main | svocfg, state, t, ch, pos, tix, atimer

These are called local variables which means they only exist while a method is running (main is always running, but others are transient) and, importantly, local variables can only be seen by and used in the method where they are declared.  Global variables, on the other hand, can be seen and modified by all methods in the same object (file) and persist through the run of the program.


obj

  sd    : "fsrw"
  servo : "efx_servo8"

The FSRW object (called sd in the application) provides the low-level code for reading and writing SD cards. I have written high level routines that can read Vixen files by calling methods in FSRW. It's important to know the FSRW only transfers bytes from and to the SD card, it knows nothing about the structure of the file holding those bytes -- we handle that with high-level code.  FSRW is also at the core of the AP-16+ for WAV file input, though it is my high-level code that knows how to deal with the structure of the WAV format.  FSRW just feeds us bytes from the files; it doesn't know or care anything about those bytes.

Would I use this section of code to read from the vixenxx.bin?

pub readbuf(bpntr, n) | check

'' Reads n bytes from file to buffer at bpntr
'' -- returns true if good read

  check := \sd.pread(bpntr, n)
  if (check == n)
    return true
  else
    return false

This is part of it -- but only after the SD is mounted and the file opened. And one must understand the structure of the Vixen file. The first six bytes, aligned as three words, hold the number of channels in the file, the event timing, and the number of frames in the file. We have to read the header first to know how many bytes to read for each frame, and the timing in between each of those reads.

I've attached a demo program that will read and display the contents of a Vixen binary file; it details the process. I will use this code in your application (which really should be in a separate thread now that this one has morphed into a discussion on Spin programming)

You had mentioned that for the show it would be better to run the AP-16+ from the serial rather than out7. You were talking about the 3 pin serial and not the RS-485 right? Could you give an example of the code?

By using the SERIAL header we can tell the AP-16+ what to do: play a specific file, change volume, etc. It is always best to use serial when possible.

Yes, we will connect the 3-pin SERIAL header on the HC-8+ to the 3-pin SERIAL header on the AP-16+.

These are the routines that I can/will use in your program (again, start a new thread for the PROJECT that is not a discussion on general programming). The 'audio' object is actually FullDuplexSerial so we can "talk" to the AP-16+"

con

  { ------------------------------- }
  {                                 }
  {  A P - 1 6 +   R O U T I N E S  }
  {                                 }
  { ------------------------------- }


pub ap16_setup(pin, baud)

'' Start audio serial driver on pin at baud (half-duplex true mode)

  audio.start(pin, pin, %1100, baud)
  pause(10)
  audio.rxflush


pub ap16_version(addr) | idx

'' Returns version string from AP-16+ at addr

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.tx("V")
  audio.rxflush

  repeat idx from 0 to 2
    byte[@Version][idx] := audio.rxtime(25)


pub ap16_status(addr)

'' Returns AP-16+ status byte

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.tx("G")
  audio.rxflush

  return audio.rxtime(25)


pub ap16_playing(addr) | status

'' Returns playing status from AP-16+ at addr

  return ((ap16_status(addr) & %1000_0000) > 0)
   
   
pub ap16_sfx(addr, sfx, rpts)

'' Plays SFX file on AP-16+ at addr

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.str(string("PS"))
  audio.tx(sfx)
  audio.tx(rpts)   


pub ap16_aux(addr, aux, rpts)

'' Plays AUX file on AP-16+ at addr

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.str(string("PA"))
  audio.tx(aux)
  audio.tx(rpts)


pub ap16_wav(addr, spntr, rpts)

'' Plays WAV file (name at spntr) on AP-16+ at addr

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.str(string("PW"))
  audio.str(spntr)
  audio.tx(13)     
  audio.tx(rpts)
   

pub ap16_stop(addr)

'' Stops AP-16+ at addr

  audio.str(string("!AP16"))
  audio.tx(addr)
  audio.tx("X") 

Wondering if the PIR should be on the input TTL's and not the Output?

Yes, the PIR may only be connected to a TTL input pin. The TTL outputs pins are just that: outputs; connecting a PIR there will cause an electrical conflict that could damage the board.

Whew... this may be one of the most hard-core responses in EFX-TEK history! That's good, though, as we're raising the bar on the technology we use which lets us build better props.

Again, move the request for your project to a separate thread and keep the theoretical stuff here. Thanks.

[youngti]

Thank you and I am sorry I morphed this into a discussion about spin.  I will copy the first post and use that to start a new topic titled Cauldron Skeleton.  I have done a few props using pbasic but this is my first and I am trying to take the commands and fit them to EFX-TEK boards.  There is always a little difference between what the manuals say and what you do.  I prefer to use your style when using the EFX-TEK boards.  Thank you for your help.

Now I had better get back to my job fixing computers.  Need to keep the money rolling in to pay for my habit.

[youngti]

Okay so it sounds like for most of us writing our own code the default would be to start with the Constants set up on IO pins 0-31 and the _clkmode section.

[JonnyMac]

Yes. In fact, I would suggest starting with one of my templates. I'm not at my work computer right this second but when I get back to it I will upload all of them. Or, maybe I'll make a mega template that handles the HC-8+ hardware, can use an attached uSD card, and can control an AP-16+. Start with that and when your program is working you can eliminate code unused code (this feature is being added to SimpleIDE that will ultimately replace the Propeller Tool.