My first C3 project?

Rsadeika

It has to be an OS (PropOS) for the C3 board. Since the C3 is readily available, and fully assembled, I think there will be more people that would be interested. I think it is best to start from scratch, that way you will not have to change pin assignments in the source code, which in a larger program, becomes error prone. I believe the standard should be for a VGA system with a keyboard and mouse. More people have extra VGA screens laying around then TV sets with the proper hookup.

I looked around, and there are PS/2 keyboard/mouse y-splitter cable that is available, so, the missing first item would be a driver for that device. Since there is a driver for the VGA, that is ready to go. The other thing that would be necessary is to be able to create a bootable uSD card, that way you have your OS on the card, plug it in, turn on the C3, and you are ready to go.

Now where do you go from here, I am thinking that a CLI/semiGUI, would be a good start. It would be a standard CLI, you type in commands, and the semiGUI would be some similar to the Edit programs that are used on a DOS box. When you open the Edit program you can use the mouse for cut/paste, file save, and that sort of stuff. Part of the command structure, you would need a 'Run' command, that way you could load other programs, and run them without to much hassle.

This is my outline, is anybody thinking along the same lines? I guess we can start a discussion about this, before to many people start to duplicate efforts.

Thanks
Ray

Dr_Acula

Sounds interesting. KyeDOS might give you the building blocks to get started and it might be as simple as changing a few pin definitions at the beginning of the code, and a tiny bit of driver code to select the SPI port for the sd card. KyeDOS sits in eeprom and runs programs that are on the sd card. It has a "run" command that can also pass command line parameters. The movie player demo might only need a few lines of code changed http://www.youtube.com/watch?v=170HLfl6VfI again, the sd card select. KyeDOS does not need external memory so it is fairly platform independent. You can use a graphical OS with a mouse if you want. This code http://www.youtube.com/watch?v=0NTXOG_HfVY&feature=related uses Kye's v2 code and the new v3 code is a lot faster, so those icon refreshes will be a lot more user friendly. Much of this code ought to drop straight into the C3. To run a file, just type the name of a file that ends in .exe and it will run. Reboots back to KyeDOS when finished running.

Testing for SD card
*** KyeDOS SD card operating system v3.01 by Kwabena W. Agyeman & J. Moxham ***
Type Help for command listing
>help

Command Listing
<clear>                        - Clear the screen.
<echo> <string>                - Echo the string argument.
<reboot>                       - Reboot the propeller chip.
<help>                         - Show the command listing.
<mount> <partition>            - Mount the file system.
<unmount>                      - Unmount the file system.
<df> <fast>                    - Free sector count. F=Fast. 1 Sector = 512 Bytes
<du> <fast>                    - Used sector count. F=Fast. 1 Sector = 512 Bytes
<ls> <all>                     - List contents of the working directory. A=All.
<dir>                          - List contents. Includes wildcards eg dir *.exe
<cat> <file> <hex>             - Print the ASCII interpreted contents of a file.
<cd> <directory>               - Change directory.
<chmod> <entry> <attributes>   - Change Attrib: R=R/O, H=Hidden, S=Sys, A=Arch
<mv> <oldPath> <newPath>       - Move a file or directory.
<rm> <path> or <era>           - Remove a file or directory.
<mkfile> <name>                - Make a new file.
<mkdir> <name>                 - Make a new directory.
<cp> <oldPath> <newPath>       - Copy a file.
<diff> <path> <path>           - Print differences between two files.
<boot> <file>                  - Reboot the propeller chip from a file.
<filename>                     - Reboot and run filename.exe
<format> <partition>           - Format and mount the file system.
<date>                         - Display the current date and time.
<time>                         - Change the current date and time.
<dump>                         - Dump the ROM font.
<test>                         - Speed test the file system.

>dir

A.DSK        B.DSK        BLANK_E5.DSK BOOT.DSK     C.DSK        D.DSK
E.DSK        F.DSK        G.DSK        H.DSK        MYNAME.TXT   BASICS.P5
BASICS.PAS   NEW.BIN      OTHELLO.EXE  COGJECT.COG  COGTEST.BIN  CATALYST.TXT
CP.BIN       P8X32A.TXT   ELIZA.BAS    FACT.LUA     FIB.LUA      HELLO.LUA
HELLO.PAS    HELP.XVI     LS.BIN       MATCH.PAS    MKDIR.BIN    MV.BIN
PCOM.BIN     PINT.BIN     RM.BIN       RMDIR.BIN    ROMAN.PAS    SORT.LUA
SST.BIN      SST.DOC      STARTREK.BAS STARTREK.P5  STARTREK.PAS TREK15.BAS
TEST         UT-TREK.BAS  ZORK1.DAT    ZORK2.DAT    ZORK3.DAT    SCREEN.BIN
CLS.BIN      COMMAND.TXT  TEST.TXT     TEST3.TXT    TINY.TXT     TEST127.TXT
XMODEM.TXT   SBENTIRE.TXT TEST5.TXT    CATLYST1.BIN CATLYST2.BIN CPM.EXE
CPM1.EXE     ICON2.ICO    ICON3.ICO    ICON1.ICO    ICON5.ICO    ICON4.ICO
ICON6.ICO    ICON7.ICO    ICON8.ICO    ICON9.ICO    ICON10.ICO   ICON11.ICO
ICON12.ICO   ICON13.ICO   LARROW.ICO   RARROW.ICO   128X96.ICO   SCOOBY.RAW
SURFER.RAW   SURFER.ICO   SCOOBY.ICO   BUBBLE96.VGA CALC32.VGA   CALC96.VGA
COG32.VGA    COG96.VGA    COMPAS32.VGA COMPAS96.VGA DISK32.VGA   DISK96.VGA
EMAIL32.VGA  EMAIL96.VGA  INTERN~1.VGA INTERN~2.VGA MARIO32.VGA  MARIO96.VGA
NOTE32.VGA   NOTE96.VGA   PALAT32.VGA  PALAT96.VGA  PHONE32.VGA  PHONE96.VGA
PHOTO32.VGA  PHOTO96.VGA  TWIT32.VGA   TWIT96.VGA   WIFI32.VGA   WIFI96.VGA
BOOK32.VGA   BOOK96.VGA   BUBBLE32.VGA CALC86.VGA   BOOK86.VGA   PHOTO86.VGA
PHONE86.VGA  PALAT86.VGA  ABSWALL.RAW  ABSWALL.VGA  EMAIL86.VGA  MARIO86.VGA
KYEDOS32.VGA KYEDOS86.VGA KYEDOS.BIN   TWEETY.VGA   DEVIL.VGA    SCOOBY.VGA
SURFER.VGA   PHOTO.EXE    PROP160.VGA  DEMO.RAW     DEMO.VGA     DEMO2.VGA
CATEX.VGA    TEST.MAP     TEST.CHR     TWEETY2.VGA  TW338.VGA    TW339.VGA
TW340.VGA    TW341.VGA    TW342.VGA    TW343.VGA    TW344.VGA    TW345.VGA
TW346.VGA    TWEETY.PMV   TAZ.PMV      7SEG256.CHR  7SEG256.MAP  MOVIE.BIN
MOVIE.EXE    XMODEM.EXE   TYPE.EXE

>dir *.exe

OTHELLO.EXE  CPM.EXE      CPM1.EXE     PHOTO.EXE    MOVIE.EXE    XMODEM.EXE
TYPE.EXE

>dir *.txt

MYNAME.TXT   CATALYST.TXT P8X32A.TXT   COMMAND.TXT  TEST.TXT     TEST3.TXT
TINY.TXT     TEST127.TXT  XMODEM.TXT   SBENTIRE.TXT TEST5.TXT

>type myname.txt
Saving command line in COMMAND.TXT and running program
Command line: type myname.txt
Type/Dump a file

Hello, this is a text file.
This is a text file line 2.

Hit any key to continue:Testing for SD card
*** KyeDOS SD card operating system v3.01 by Kwabena W. Agyeman & J. Moxham ***
Type Help for command listing
>

jazzed

The C3 PS/2 port only supports one device at a time. My first C3 adapter will be a version of the TinyTwoWire board which will fix that problem.

Rsadeika

I thought I saw that somewhere, the one at a time thing, but after reading the manual I got the impression that it would be a software issue. So, a little set back, but, I still think the C3 needs its own OS, nes pas?

jazzed

Rsadeika wrote: »

So, a little set back, but, I still think the C3 needs its own OS, nes pas?

I agree.

Rsadeika

It looks like this could be a challenging project, but, I think I will give it try. If things go south, then I can just post the code that I have, and maybe somebody else will pick up on it.

What I would like to have is a bootable uSD card, but, I think I remember that when the Propeller starts, it only checks the EEPROM, is this a correct assumption? I started looking at the source for the C3, and it looks like AndreL has covered everything, so, if I have to create a boot program, that will reside in the EEPROM, I think there is enough source examples to give it a shot.

What I will try to accomplish is a bootable uSD card, keyboard with a VGA monitor, that will boot up, and accept some commands from the keyboard (maybe one command). That should keep me busy for a couple of months LOL.

Ray

Dr_Acula

Regarding a bootable uSD card, I've thought about that too. One practical problem that comes up is when you are moving files around and forget to put the card back in. I've found it is helpful to at least get an error message saying the card is not inserted. And to run that program, something needs to be in the eeprom. Since the propeller checks the eeprom first anyway, it makes sense to me to put something in the eeprom.

So I have a simple boot program in the eeprom that starts up and prints a message on the screen saying "Type Help for command listing". Then you can read the help and see quite easily how to run binary programs off the sd card (just type the name of the file).

That should keep me busy for a couple of months LOL

I think it might be easier than that!

If you use Kyedos you would need to:
1) remove the references to the LCD display
2) change references to pins in the CON section
3) add in a tiny bit of code on startup that resets the counter so the default device is the sd card

Take a look at the Kyedos thread if you want something to start from. http://forums.parallax.com/showthread.php?128779-KyeDOS-an-operating-system-for-the-Propeller Then start pulling it to bits!

Rsadeika

I am re-thinking this bootable uSD concept, instead, maybe a uBIOS, that would reside on the EEPROM. The uBIOS, in my case, to start with, would have a VGA driver. So, what would happen is, you start up the C3 with the VGA monitor hooked up, if no uSD card is available, an error would occur: "No bootable system available!" The next step would be is to figure out a way of determining what you have connected, a VGA monitor, or a TV monitor. The next piece of code would have to be the uSD driver, which would look for a file called uExec.bin. The uExec.bin file would contain the program that you want to start, and possibly some drivers that would be needed. My thinking is to set up a system where you do not keep replicating the code, for instance, if you have the uSD drivers available in the uBIOS, how can a program access them, instead of repeating the code somewhere else. There are probably lots of flaws in this, what am I mssing, or what will not work?

Ray

Rsadeika

This morning I started tinkering with some code, specifically VGA code. The C3 examples use the 32x16 VGA driver, which is way to big text. Does anybody have some code for 80x25 VGA driver, or some advice as to how to get there. I think the HiRes stuff will make the text way to small for a monitor type look that I am looking for.

Mike Green

Look in the Object Exchange. There are all sorts of VGA drivers there. Some of the text drivers are configurable for different screen (pixel) dimensions.

Rsadeika

Well, I did some more poking around in the C3 drivers, and other VGA drivers. In the OBEX I found a GUI type example, which, after running it on the demo board, looks like the text size is what I am looking for. I guess that might be a starting point.

I should mention that there is a programming complexity, at least for me, around the coding of the MUX. I have to decide if the MUX code should be in its own object, or if a PUB or PRI should suffice. By complexity, I mean, you have to turn on/off pins before you can use them. Other than that it looks like this could be a lot of fun.

On another note, I am surprised that Parallax did not provide an enhanced Propeller IDE for handling the C3. This is a great little board, but if you have to "pull teeth" in order to use all that is available on the board, you might run into some resistance for greater sales. Just my opinion, for what it is worth.

Ray

AndreL

@rsadeika,

I wouldn't say setting one bit is pulling teeth to select the VGA or IO And other than that, everything works thru spi, with examples of everything in my book. So, something that's advanced enough to use the new features can use them immediately, where newbies can just use the core propeller features as they would anything until they get comfortable and want to try the other peripherals. I am not sure what we would do the IDE to support the C3 specifically, or any other Propeller board for that matter. The C3 is like anything else, but just has a lot of stuff. So, when you say to yourself, I want to do "this" - first look in my manual on the "this" see if there is a demo, check it out real quick, the 3-5 overview of every system will save you a lot of time and then try it.

Moreover, the IO configuration of the C3 mimics the two most popular boards for the Prop; the demo board and HYDRA, so 90% of all objects work untouched or with a change to the start function. The other new peripherals and the SPI bus are really a new "standard" for the Propeller platform, so as time moves on people will modify drivers and other higher level functions to have built in support for the SPI bus selection logic. And I think that a lot of people will use this SPI bus design with mux/selection logic as the basis of their designs, so things will go in that direction.

But, like I said, modifying the IDE to support any board specifically isn't really a problem, the problem is WHAT what the IDE do differently other than have a section in the HELP on the board, but that's what the C3s manual is for.


Now, a NEW ide that uses a different language like BASIC, Forth, etc. that has built in functions and a base set of drivers for dealing with the C3 that's a good idea. But, that's a LOT of work. Maybe something you want to tackle? Take one of these languages for the Prop that runs from a command line, wrap ecplise or a java tool around it, and then build an API and driver model, so from the users point of view they are just coding like this:

handle = Open_File( "sd", channel_n, mode_bits)
handle = Write_File( handle, data)

Or the SRAM is integrated into the memory model so when you declare something, you can do this:

VAR BYTE data_array[100] // normal array in local hub RAM
VAR BYTE SPIRAM data_array2[100] // this array is stored in SPI RAM

data_array[1] = 100 // stores a 100 in location 1 of local array
data_array2[56] = 200 // stores a 200 in location 56, but syntax is the same, compiler creates code to access the SPI ram for programmer transparently.

etc. stuff like that, I think that would be great. A new IDE, use a BASIC or CBASIC language, and put 100% support for the C3 and any other C3 like device with SPI bus peripherals.

Andre'

Rsadeika

Thanks Andre. What you just described is way out of my league. That project could be for somebody like Bean, BradC, or one of the respondents to the Big Spin thread. The only point that I was trying to make is, if the new people are having a problem with accepting Spin, what are they going to do if they also have to deal with the intricate device drivers? I would also like to thank you for the excellent write up for the C3, it could have been a much uglier scenario, like here is the product, and the part numbers, have fun.

I will keep poking around ...

Ray

Dr_Acula

On another note, I am surprised that Parallax did not provide an enhanced Propeller IDE for handling the C3. This is a great little board, but if you have to "pull teeth" in order to use all that is available on the board, you might run into some resistance for greater sales. Just my opinion, for what it is worth.

I guess this is all at the cutting edge, so a lot of things have not been written yet.

I've mentioned Kyedos a few times. This is not perfect either, but what it does is link together a number of Obex objects that have been proven to work well. One of those is an 80x40 vga character display, which I think is one of the things you are looking for.

I don't think you need a new IDE to do this. Just some customised code that is specific for the C3. I think mainly that revolves around the SPI device selection.

Using the external ram might come later, though I think it might be working already with C.

I'm not sure you can detect whether a TV or VGA is connected, but what you could do is include the code for both and then have one value in the CON section that you can change to select which one it uses.

AndreL

I have seen a couple people that want to detect if the VGA or TV is plugged in. This can be done actually, when either device is plugged in there is going to be a load/impedence on it. By writing a value to the port and then put the IOs in the read mode, you can tell if a VGA is there by interogating the RGB, and TTL hsync and vsync, they will act differently when no VGA is plugged in. Same thing with the TV connector, there is a lot of impedance and capacitance on that RCA into the TV, again that can be used to "scan" if its plugged in. Just some clever writing and reading and then look at the results with and without the load and then write an algorithm that can detect it -- pretty easy, couple hours work at most.

Andre'

Dr_Acula

Now that would be cunning!

AndreL

If I get a few mins, all you need to do is write an algorithm that writes a 0 - 255 to the port and then read the 10 -100 values back after each and then create a response profile for the port then compare plugged and unplugged and see what you see.

Andre'

Ariba

Here is what I use to detect VGA and TV connections:

For TV you can set one of the 3 resistors to High output and then read in another of the 3 TV-Pins. If the Pin is high nothing is connected, if it is low there must be a TV with a 75 Ohm input resistance which pulls the line to Low:

'TV detect
  dira[TVbasepin+1] := 1
  outa[TVbasepin+1] := 1
  if ina[TVbasepin] == 0
    'TV connected
  else
    'TV not connected
  dira[TVbasepin+1] := 0

For VGA I use the fact that my Monitor has PullUps on the H- and V-sync inputs. So I write a Low to the V-sync and switch it then to input. If it is still low, no Monitor is connected, otherwise there must be a VGA monitor which pulls the line high. Not sure if all Monitors have pullups.

'VGA detect
  outa[vgabasepin] := 0
  dira[vgabasepin] := 1
  dira[vgabasepin] := 0
  if ina[vgabasepin] == 1
    'VGA connected
  else
    'VGA not connected

Andy

Edit: I think this VGA detection is not possible on the C3 because of the Tristate buffer in between.

AndreL

Yup, something like that perfect -- that's the idea. But, yes, on the C3 and the HYDRA since we mux the VGA, it will be more challenging with that one way buffer there A little out of the box thinking....hmmmm.

Andre'

Rsadeika

I found a small TV set, about 5" diagonal, that acts as monitor, to test the C3 diagnostics. I had the VGA, keyboard, sound, TV, and power plugged in. The first pass got to a line where the ADC: kept running through some numbers. Thinking some thing was wrong I turned the board off, starting the diagnostics again, this time it got to the SPI ram test, and it failed where everything just stopped. This when on for about five tries where the memory test failed, then on another start it passed, then it failed. So, I wonder what is going on? Is there a problem with the board, already?

Ray

AndreL

Just load a demo in the IDE and download it into the unit. If not, then the only thing it can be is a bad soldering job and wasn't cooked enough, etc. But, step one, download the test program again, freshly, clean the board with air, make sure there is not gunk or metal on it. But, all the boards passed Q/A and the loading of the test demo, so the only thing this can be is soldering issue or there is some particulate matter on the board.

Andre'

Rsadeika

I have been playing around with the hires driver, and this is the best that I could do. This puts out seven lines of characters, but I cannot figure out how do display other stuff. I am looking for some help as to how to put a simple character on the screen.


Code:

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

'' Pin that controls VGA and status/debug LED
STATUS_LED_BUS_MUX  = 15

cols = term_vga#cols
rows = term_vga#rows
chrs = cols * rows


OBJ
term_vga  : "VGA_Text_010.spin"  '' VGA High-Res Text Driver v1.0

VAR
long screen[cols*rows/4]
word colors[rows]

byte cx0
long sync

PUB Main

'' Enable VGA (leave low)
  DIRA[STATUS_LED_BUS_MUX] := 1
  OUTA[STATUS_LED_BUS_MUX] := 0

 
'' Turn on VGA buffer, and status LED
''  OUTA[STATUS_LED_BUS_MUX] := 0

   term_vga.start(16,@screen, @colors, @cx0, @sync)
  


  colors[0] := %%3000_3330
  colors[1] := %%0000_0300
  colors[2] := %%1100_3300
  colors[3] := %%0020_3330
  colors[4] := %%3130_0000
  colors[5] := %%3310_0000
  colors[6] := %%1330_0000
  colors[7] := %%0020_3300




  repeat

AndreL

There are countless VGA demos on the OBEX, just go into video and pick some and then print to the screen with them. Just remember you have to change the pin IO group to the C3s and you have to enable the VGA buffer (add 1 line of code to them). But, with this driver just go into the source code and look at the functions, there are string and character functions, just use the character function to print single characters and dump the char set and that's how you print characters.

Andre'

Rsadeika

I changed gears on the project, I am going to use the C3 as a controller for a robot. Attached is a program in progress where I use a remote, and a serial program to control a robot. Since this is a simulation, the LEDs act as a visual for the wheels. Now, the question that I have is, since I will be using the DAT, is there a way of using the SRAM, or the FLASH ram for the storage? In other words, is there a C3 utility for moving the DAT to SRAM or FLASH ram? I guess this would be a good time to experiment.

Ray

AndreL

Just read my book on the C3 programming, look at the SRAM and FLASH demo, they show exactly how to do this. Then just copy the code from the demos which in the SRAM's cases is very short, FLASH is more complex. Then you can read and write the SRAM or FLASH.

In general, every peripheral on the C3 I wrote a chapter and demo about, so just read up, then you can integrate anything you want.

Andre'

Rsadeika

I decided to show how I have my robot simulation setup. On the right side is the C3, and on the left side is the breadboard. On the left side of the breadboard are four LEDs that simulate the wheel movement, two greens are forward, and the two reds are backward. On the right side, I will be using the red, yellow, and green LEDs for the visual status of the battery charge. The green board with the duck antenna is the bluetooth module, which is used to connect with the computer. I tested the distance on the bluetooth, and I got a good eighty feet, that is all that I wanted to test, in terms of range.

Now I will proceed with trying to get the battery connected to the AD connector, and hopefully I will get the LEDs to show the battery charge level. After I get that to work, then I will be moving the platform on to the robot, and see if it all works the way I expect it to work.

Ray

Rsadeika

I was doing some thinking about the voltage divider circuit for my project, I can create a little wire harness that will hold the resistors in place. But, the bigger problem is going to be, how do I measure the voltage draw down when the battery is plugged into the C3? On some previous experiments with a voltage divider, I found out that you can get the resistors to create the five volts that are needed, but I did not figure for the voltage dropping even further when it is plugged in. Any ideas on how to get around this problem?

Ray

Rsadeika

In the file attached, I added some AD code, but, I am not getting what I expect. I am not getting anything at all, I wonder if somebody would look at the code, and see if there is some obvious error that I am not seeing. I am using the code straight out of the C3 manual.

Ray

AndreL

Ray,

A couple things. First, I would start with something WORKING -- then add a tiny bit of code, make sure it WORKS then a tiny bit more.

Also, on your question about voltage dividers, not sure what you are asking, but voltage dividers work on the ohms law etc. they aren't magic, so if you put a load on one of the resistors this CHANGES the resistance and thus the voltage divider action. So, either you need zener diodes if you want some modicum of regulation, or real regulators, or you need to "tap" your voltage divider with a very high impedance probe like an Op Amp and then use the output of that as your voltage, this way you "buffer" the signal and don't draw current from the voltage divider.

ANdre'

Rsadeika

Below I pulled out the specific code that pertains to running the AD. All that it is supposed to do, is turn on the green LED, the g_temp1 value just has to be greater than zero. For whatever reason, the LED does not turn. On my wiring harness the AD connector part is getting 4.22V, when it is not plugged in to the board, and 3.89V when it is plugged in and the C3 board is turned on. So, what code parts am I missing in order to get the AD to work?

Ray

I attached a picture of my wiring harness, I think the professionals will be amused.

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  ''IRdetpin = 4  '' IR detect pin
  IRdetpin  = 26

  SPI_SEL_CLK   = 8
  SPI_SEL_CLR   = 25
  SPI_MOSI      = 9
  SPI_MISO      = 10
  SPI_SCK       = 11
  
  SPI_CHAN_AD   = 4

VAR
  long IRremstack[40]
  long BTdevstack[40]

  byte IRcode  '' Global IR code
  byte Bytearray[15]

  long g_temp1

PUB Main

  cognew(IRremote, @IRremstack)
  cognew(BTdev, @BTdevstack)

  '' This main cog will contain the
  '' AI or control system.

  SPI_Init

  

  repeat
    AD_Init
    g_temp1 := AD_Read(0)

    if g_temp1 > 0
      misc.high(7)

PUB AD_Init

  SPI_Select_Channel(0)
  SPI_Select_channel(SPI_CHAN_AD)
  SPI_Select_Channel(0)
'''''''''''''''''''''''''''''

'''''''''''''''''''''''''''''
PUB AD_Read( Channel) | _data

  SPI_Select_Channel(SPI_CHAN_AD)
  _data := SPI_Write_Read(17,%0001_10_1_0000000000000 | channel << 14, $FFF)
  SPI_Select_Channel(0)
  return(_data)
'''''''''''''''''''''''''''''

'''''''''''''''''''''''''''''
PUB SPI_Init

  DIRA[SPI_SEL_CLK] := 1
  OUTA[SPI_SEL_CLK] := 0

  DIRA[SPI_SEL_CLR] := 1
  OUTA[SPI_SEL_CLR] := 0
  OUTA[SPI_SEL_CLR] := 1

  OUTA[SPI_MOSI] := 0
  OUTA[SPI_SCK] := 0

  DIRA[SPI_MOSI] := 1
  DIRA[SPI_MISO] := 0
  DIRA[SPI_SCK] := 1

  SPI_Select_Channel(0)
'''''''''''''''''''''''''''''

'''''''''''''''''''''''''''''
PUB SPI_Write_Read(num_bits, data_out, bit_mask) | data_in

  data_in := 0

  repeat num_bits
    OUTA[SPI_SCK] := 0

    OUTA[SPI_MOSI] := ((data_out >> (num_bits -- - 1)) & $01)

    data_in := (data_in << 1) + INA[SPI_MISO]

    OUTA[SPI_SCK] := 1

  OUTA[SPI_MOSI] := 0
  OUTA[SPI_SCK] := 0

  return (data_in & bit_mask)
'''''''''''''''''''''''''''''

'''''''''''''''''''''''''''''
PUB SPI_Select_Channel(channel)

  if(channel == 0)
    OUTA[SPI_SEL_CLR] := 0
    OUTA[SPI_SEL_CLR] := 1
    return

    OUTA[SPI_SEL_CLR] := 0
    OUTA[SPI_SEL_CLR] := 1

    OUTA[SPI_SEL_CLK] := 0

  repeat channel
    OUTA[SPI_SEL_CLK] := 1
    OUTA[SPI_SEL_CLK] := 0

RS_Jim

Ray,
Goto Radio Shack and get a 5 volt regulator from the parts drawer. Output will be 5 volts for any current up to one amp.
Jim