When I tried to open the case, I found that the wires to the Scart Plug had melted themselves into the plastic base of the router!

Router Case After the Wires 'Moulded' Themselves to it.

I thought ‘perhaps I had drawn too much power through the wires’, but the marks at the top of the picture are from the wires to the LEDs.

I guess the problem is a result of a chemical reaction between the soft plastic of the base and the rubbery style insulation used on the black wires from the ‘cheap’ scart splitter.

I notice that the scart to scart leads with coloured wires inside seem to be made with a different insulating material.  I’ll have to re-wire, (using one of these) as when I pulled the wires from the base, several of them left a good portion of insulation behind.

The following program requires an update to the PIC I2C Slave software to set PORT B to output and the Remote Control On/Off lines connected to PORTB 0 and 1.  A 0v Line is also required between the two.  I continue to run the Mains Remote Control unit with its own 12v Battery although, the 12v supply to the router could also be used.

The following Blassic (Basic) program sets up the Router I2C software to talk to the PIC and then inputs “On or Off” from the console.  If the Response is On, PORT B0 is set high for a few seconds.  If it is ‘Off’, PORT B1 is used.

Here is the Program Listing

     10 REM Remote.bas
     11 REM Test The Mains Remote Control Via I2C
     12 REM Input On or Off then Switch the Plug On or Off
     14 REM Needs Update to PIC I2C software to Set Port B as Output
     20 REM
     30 REM I2C Control
     40 I2CAddress=34
     50 I2CData=35
     60 PIC16F876=46 : REM Address of Our Chip
     70 REM Commands
     75 PortB=1
     80 AnalogRead = 4
     90 PortA1Invert = 5 : REM Invert A1
    100 REM Begin
    105 INPUT "On or Off ",a$
    106 IF a$ = "On" THEN OnOff = 1
    107 IF a$ = "Off" THEN OnOff = 2
    110 POKE I2CAddress,PIC16F876 : REM Address the chip
    200 POKE I2CData,PortB : REM we are sending port be some data
    210 POKE I2CData,0 : REM ensure PortB All off
    220 POKE I2CData,PortB
    225 POKE I2CData,OnOff : REM Bit 0 = A1On, Bit 1 = A1Off
    230 GOSUB 800 : REM Delay long enough for the Remote Xmit
    240 POKE I2CData,PortB
    250 POKE I2CData,0 : REM and Stop Pressing Remote Buttons
    300 END
    800 FOR x=0 TO 4000: NEXT : RETURN
Ok

Update:
I was setting PORT B to 03 to turn off the power switch, ( B0 and B1 both HIGH) in error, the above code now only sets PORT B1 HIGH.

I also was getting random result trying to use a Blassic program to control the PIC 16F876a/Mains Remote from inside a shell script. That turned out to be a power problem, I’m only using a low power regulator for the 5v rail. This supplies both the USB Memory Stick, an LCD Display and the PIC Processor. When the USB Memory Stick is accessed, the power dips enough to reset the PIC Processor.

As the LCD Display was not needed for the Power Remote Control, I simply unplugged the display from the bus and the reduced power load allowed the rest of the systems to function.

I will now add a second 78L05 to the router and use that to power the bus.

Updated JAL Source for the 16F876 I/O Processor

-- Sebastien Lelong Copyright (c) 2008, http://sirloon.net
--
-- This file is part of the Sirbot Project (http://sirbot.org)
-- Released under the GPL license
--

-- !! changes by Phill, ProjectNotes.co.uk for
-- use with the 16F876a as an I/O extender for the Midge/OpenWrt
-- & Sunspot software driven routers.

-- 29/08/08 Added basic PWM support and I/O Command List
-- At Reset, PWM is set to 50% (2.5v)

-- I/O Commands
-- 01 - Write Next byte to Port B
-- 02 - Write Next Byte to H/W Serial Port
-- 03 - Next Read Byte is Latest Serial Port Rx Data OR ZERO
-- 04 - Next Read Byte is Analog in From Pin A0
-- 05 - Toggle Output Pin A1 (status led?)
-- 06 - Write Next Byte to Jal PWM  Duty Cycle

-- Once a read data command has been sent, it will star in effect until
-- another command has been sent.
-- After a Write data or immediate command (05) is complete, the command
-- byte is set to zero (ready for another command)

include 16F876a_bert

--include sb_config
--include sb_protocol
--include sb_mainboard

-- !! 16F876a port C3&4 are the I2C i/o pins
-- AppNote says must be configured as input first
--pin_b4_direction = input
--pin_b1_direction = input
pin_c6_direction = output -- tx
pin_c7_direction = input  -- rx
pin_c3_direction = input
pin_c4_direction = input

-- For testing purpose (checking if slave is responding to START/STOP signals)
-- you may want to activate 7bits address with interrupts (see spec)
;;SSPCON = 0b_0011_1110	-- slave 7bit address, start/stop interrupt
SSPCON = 0b_0011_0110	-- slave 7bit address

-- I2C slave hardware
-- Careful: we're in 7bits i2c address, *but* PIC
-- wants an address coded on 8bits, that is, with read/write bit
-- In master, slave address is:
-- 		0x2E <=> 0b_0010_1110
-- So, in slave, by left-shifting once, we have:
--		0x5C <=> 0b_0101_0110
SSPADD = 0x5C

-- init SSPSTAT
BF = false
WCOL = false
SSPOV = false
SSPIF = false
-- enable interrupts
SSPIE = true
GIE = true
PEIE = true

-- !! no ready/busy leds, we want port B all OUT
-- "Ready !" LED
-- var bit ready_led_direction is pin_b0_direction
-- var bit ready_led is pin_b0
-- ready_led_direction = output
-- Error LED
-- var bit error_led_direction is pin_b3_direction
-- var bit error_led is pin_b3
-- error_led_direction = output

var byte tmpstat
var byte tmpbuf
var byte data

-- !! add a few temp registers of our own
var byte serialtemp
var byte command
var bit a1f
command = 00
a1f = off
-- !! set up our a1 toggle bit
pin_a1_direction = output
pin_a1 = a1f
-- !! set up our adc in pin
pin_a0_direction = input

-- !!

-- test to set SSPBUF to see if it's changed while receiving
-- the first byte address
SSPBUF = "A"

function read_i2c() return byte is
	tmpbuf = SSPBUF
	return tmpbuf
end function

procedure write_i2c(byte in what) is
	-- wait 'til buffer is empty
	while BF loop end loop
	var bit dosend = true
	while dosend
	loop
		WCOL = false
		-- try to write into buffer, checking collision
		SSPBUF = what
		if ! WCOL
		then
			-- ok, done
			dosend = false
		end if
		-- else continue trying
	end loop
    CKP = 1
end procedure

procedure proceed_state_1() is
	-- state 1:write operation, last byte is address, buffer full
	-- byte is an address, it we get here, we just know master
	-- wants to talk to us...
	-- and we also know address is recognized (BF is set, see spec)
	-- anyway, we must read buffer to reset BF bit
	read_i2c()
end procedure

procedure proceed_state_2() is
	-- state 2: write operation, last byte is data, buffer full
	-- got data, need to echo char + 1
	data = read_i2c()
	-- ultimate data processing... 
  -- !! here do something useful
  if command == 01 then
  portb = data
  data = 0
  end if
  if command == 02 then
  serial_hw_write(data)
  data = 0
  end if
  if command == 06 then

  PWM_set_dutycycle (data,data)
  data = 0
  end if
  command = data -- Not in a command, this must be a command.
  -- if we don't handle it here, it may be a read data command
  if command == 05 then
  a1f = ! a1f
  pin_a1 = a1f
  command = 0 -- done with this command
  end if

end procedure

procedure proceed_state_3() is
	-- state 3: read operation, last byte is address, buffer empty
	-- master wants to get a value from us

  --!! decide what data to return
  if command == 03 then
  data = serialtemp -- last serial rx char
  serialtemp = 0 -- clear it
  end if
	if command == 04 then
	data = ADC_read_low_res(0)
	end if
	write_i2c(data)
end procedure

procedure proceed_state_4() is
	-- state 4: read operation, last byte is data, buffer empty
	-- master still wants to get a value from us
	write_i2c(data)
	-- note: this shouldn't occur
end procedure

procedure proceed_state_5() is
	-- state 5: nack
	-- master doesn't want to talk with us anymore
	-- reset slave logic
	-- AN734 does not talk about setting CKP, whereas spec says
	-- it must be set. Some people say it can be error prone.
    CKP = 1
	data = 0
end procedure

procedure proceed_error() is
	-- something went wrong, that is, XOR operations did not match
	-- SSPSTAT bits
	-- Just log current status
	serial_hw_write("E")
	serial_hw_write(SSPSTAT)
end procedure

procedure ssp_handler() is
	pragma interrupt
	if SSPIF
	then
		SSPIF = false
		tmpstat = SSPSTAT
		-- mask out unimportant bit
		tmpstat = tmpstat & 0b_0010_1101
		-- check state 1: write operation, last byte is address, buffer full
		if (tmpstat ^ 0b_0000_1001) == false
		then
			proceed_state_1()
		-- check state 2: write operation, last byte is data, buffer full
		elsif (tmpstat ^ 0b_0010_1001) == false
		then
			proceed_state_2()
		-- check state 3: read operation, last byte is address, buffer empty
		elsif (tmpstat ^ 0b_0000_1100) == false
		then
			proceed_state_3()
		-- check state 4: read operation, last byte is data, buffer empty
		elsif (tmpstat ^ 0b_00101100) == false
		then
			proceed_state_4()
		-- check state 5: nack
		elsif (tmpstat ^ 0b_0010_1000) == false
		then
			proceed_state_5()
		-- check only got a start signal (when using interrupts)
		else
			proceed_error()
		end if
	else
		-- another interrupt. Weird...
--		ready_led = low
--		delay_10ms(100)
--		ready_led = high
		serial_hw_write("*")
	end if
end procedure
-- don't need status leds
--ready_led = low

--error_led = high
--delay_10ms(30)
--error_led = low
--delay_10ms(30)
--error_led = high
--delay_10ms(30)
--error_led = low
--delay_10ms(30)
--error_led = high
--delay_10ms(30)
--error_led = low

--ready_led = high

-- 29/08/08 add PWM support
pin_c2_direction = output
PWM_init_frequency (true,true)
PWM_set_dutycycle(128,128)

forever loop
	-- just loop until interrupt is raised
	-- !! poll the serial port

	if RCIF then
    serial_hw_read(serialtemp)
    serial_hw_write(serialtemp) -- echo to confirm hardware is working!
 end if

end loop

Next, the Blassic source

AnalogLightWarn.bas

The following Blassic program uses the PIC 16F876a I2C I/O processor to monitor a solar panel (1.5v max!) If the light reading changes by less than 2 up or down, no action is taken.

If the light increases by more than 2, a message is sent to the console.

If the light decreases by more than 2, a beep is sounded via a small speaker connected to the PWM output pin (Port C,2).

As the speaker is only 8 ohms, a 47 ohm resistor and 1uf capacitor are inline to limit the current through the speaker coil.

The Tone of the beep is quite low, this is because of the speed of the basic interpreter AND the time it takes to send 4 bytes of instruction via the I2C Interface.

Later I will look at using an alternative method of sending data to the 16F876 via two other led lines, simply clocking out the required data.

     10 REM Read the Analog Input A0
     15 REM if the level is a lot different from last time, say helo
     20 REM
     30 REM I2C Control
     40 I2CAddress=34
     50 I2CData=35
     60 PIC16F876=46 : REM Address of Our Chip
     70 REM Commands
     80 AnalogRead = 4
     90 PortA1Invert = 5 : REM Invert A1
    100 REM Begin
    105 last=0
    110 POKE I2CAddress,PIC16F876 : REM Address the chip
    120 POKE I2CData,AnalogRead
    130 a = PEEK(I2CData)
    135 REM PRINT a
    140 POKE I2CData,PortA1Invert
    150 IF ((a>last) AND (a-last > 2)) THEN GOSUB 300
    160 IF ((a<last) AND (  last-a > 2)) THEN  GOSUB 400
    165 last = a : REM remember for next time
    170 REM pause
    180 FOR x=0 TO 1000: NEXT
    190 GOTO 120
    300 REM lighter
    310 PRINT "Lighter"
    320 RETURN
    400 REM Darker
    410 FOR N=1 TO 30
    420 POKE I2CData,6 : POKE I2CData,255 : REM PWM=0v
    430 POKE I2CData,6 : POKE I2CData,0 : REM PWM = 5v
    450 NEXT N
    460 RETURN
Ok

It first sets up the I2C Address.

Then, Writes commands to read the PIC Serial Port, Toggling Port A,1 every New Line.

The program exits if a “!” is received.

midge# more PeekPokeTest.bas
10 POKE 34,46 :  REM our chip at 2e
20 POKE 35,3 :  REM select serial port
30 a = PEEK(35) REM Get a serial Char (0 if none ready)
40 IF a = 0 THEN GOTO 30
50 PRINT CHR$(a);
55 IF a <> 13 THEN GOTO 60
56 POKE 35,5 : REM toggle port A1
57 POKE 35,3 : REM back to serial port
60 IF a <> 33 THEN 30
midge#

I2C Hardware

Here is the level shifter I’m using for the Router (3v) I2C interface (5v on Pic and other chips I have)

                 5v
                |
                |
                R
               4k7
                R
                |
SCL ---+--R220--+-----> 5v SCL
       |
     =====  Use the Same
      ZD\   For the Data
     /3.3\  Line
       |
       |
0v-----+---------------

The above has so far worked happily with an old philips 2048bit (256 bytes!) eeprom.

Pin Header (for breadboard)

1: 0v

2: 3v

3: 5v

4: KEY NC

5: TX (I/O Bus -> project)

6: RX (project <- I/O Bus)

7: LED3 GPIO8 I2C SDA

8: LED5 GPIO11 I2C SCL

I2C Software Settings

In the sunspot.co.uk Midge rom, the default I2C port uses different gpio lines.  To use gpio 8 and 11, the file “/etc/init.d/S99start_i2c” file needs changing:-

The line containing “insmod i2c-adm5128″ needs to read “insmod i2c-adm5120 scl=11 sda=8″

The Scart Connector Pins

+==============================+
| 1  3  5  7  9  11 13 15 17 19|(21) - - shield
|                               \
|  2  4  6  8  10 12 14 16 18 20 |
+================================+

Bus Connections & LED I/O Line Use.

I added extra power lines as the wire used is quite fine. The extra power and 0v lines are connected at the router, they are not linked on the Bus I/O board to avoid any ground loop.

I have been using the 5 port ‘scart socket’ I/O Bus simply as a passive backplane.  All of the lines are bussed together and using it simply involves hooking up the correct pins of a scart type plug to the corresponding pins on a circuit.

The I/O bus started life as a cheap breakout box for the Sweex/Edimax Router so that I could hook up different circuits to it without risking physical damage to the router itself – at least I won’t be able to break off a component whilst connecting a new circuit.

The Bus simply carries the router led, power (3v and 5v) and serial lines. I have been using a transistor based level converter to connect the router to a PC for uploading new ROM images.

Now that I’m going to add a PIC Processor and try a bit of communication between the PIC and the Router, it occured to me that it would be useful if I cut the serial lines somewhere on the bus so that I could hook up more than one serial device & converter.

However, there is just room for my level converter or one based on a MAX232 IC (a better idea if you have one handy) where the original scart lead exited the case.

I added the circuit, connecting it to the nearest socket and cut the traces between the serial pins and the rest of the I/O Bus.

Now, if I need to boot the router and upload a new ROM Image or work with the serial port, I plug the router into the first socket.  If I move the router to another socket, I can plug a PIC or whatever into the first socket and upload software to that.