Final Project Final Post
Whoops, forgot to get this up by 10am today.

Annnnnnywho, last project, nicknamed Death Buttons by Prof. Jacobs, is an 8 button control pad which uses serial byte transmission to differentiate between the 8 different buttons. I had a few ideas for games to integrate the 8 buttons and their orientation on the game pad. The buttons are arranged in two columns to allow for two-player use without being cramped, as I was initially hoping to create a head to head game. One game idea was a sort of soccer-pong with 4 goals on each player's side, and the buttons would be used to move the goalies to a corresponding goal to defend/shoot a new ball. However, time constraints along with being way out of practice with Director eliminated the game from the equation.

The controller sends ASCII symbols as bytes for each button. Player 1 has buttons which send A through D, and player 2 gets lower case a-d. In this respect, the controller works properly, and gives discrete and distinguishable input to the CPU. Here's my code.

Public Const LeftA as Byte = 15
Public Const LeftB as Byte = 16
Public Const LeftC as Byte = 17
Public Const LeftD as Byte = 18
Public Const RightA as Byte = 10
Public Const RightB as Byte = 9
Public Const RightC as Byte = 8
Public Const RightD as Byte = 7

Option Explicit

Public Sub Main()

Dim button as byte
Dim outQ(1 to 40) as byte
Dim inQ(1 to 10) as byte
Dim outString as string
Dim state as boolean
Dim bNum as byte

call openqueue(inQ, 10)
call openqueue(outQ, 40)
call definecom3(11, 12, bx1000_1000)
call opencom(3, 9600, inQ, outQ)
do
for button =7 to 10
state = getpinvalue(button)
if state = true then
if(button = 7) then
'outstring = "Right D"
bNum = 100
call putqueue(outQ, bNum, 1)
end if
if(button = 8) then
'outstring = "Right C"
bNum = 99
call putqueue(outQ, bNum, 1)
end if
if(button = 9) then
'outstring = "Right B"
bNum = 98
call putqueue(outQ, bNum, 1)
end if
if(button = 10) then
'outstring = "Right A"
bNum = 97
call putqueue(outQ, bNum, 1)
end if
end if
next
for button =15 to 18
state = getpininvvalue(button)
if state = true then

if(button = 15) then
'outstring = "Left A"
bNum = 65
call putqueue(outQ, bNum, 1)
end if
if(button = 16) then
'outstring = "Left B"
bNum = 66
call putqueue(outQ, bNum, 1)
end if
if(button = 17) then
'outstring = "Left C"
bNum = 67
call putqueue(outQ, bNum, 1)
end if
if(button = 18) then
'outstring = "Left D"
bNum = 68
call putqueue(outQ, bNum, 1)
end if
end if
next
' delay 0.1
loop


End Sub

Public Function GetPinValue(ByVal button as Byte) as Boolean

if(GetPin(button)=0) Then
getpinvalue = false
else
getpinvalue = true
end if
end function

Public Function GetPinInvValue(ByVal button as Byte) as Boolean

if(GetPin(button)=1) Then
getpininvvalue = false
else
getpininvvalue = true
end if


At first I attempted to send the data as strings, but quickly switched back to bytes for the sake of simplicity and achieving function. The two functions define the 'pressed' state for each player. I did not realize until I got home that I had purchased a 4 pack of naturally-open buttons and one pack of naturally-closed. Breaking my code into two parts with inverted check functions quickly solved this and stopped player 2 from sending all 4 buttons all the time.

The device is housed in a project box from radio shack and has an integrated serial cable design. Power is supplied from the wall adapter and a mounted power jack on the box itself. Pictures will be up once they are uploaded to mycourses.

reboot and i can talk to the chip again. woot.

I have lost complete control over the Com ports, and I am unable to halt the processor, although i was halting it not even half an hour ago with the only changes in code being the addition of these lines:

l1 = cInt(getPin(left1))
l2 = cInt(getPin(left2))
l3 = cInt(getPin(left3))

debug.print "l1 = "; cstr(l1)
call delay(1.0)


This is literally all which has changed in my code and now I can not reset, halt, or download new code AT ALL. This is exactly what happens when I try to download new code.

turn power on
click halt processor
error: unable to halt processor
error: closing download port

i go to close the DL port manually
re-open DL port: com1
error: unable to open Com1

when i open and close it a few times, it works, but every second attempt it repeats that it is unable to open Com1. when it does not throw the error, i get crazy output which changes every time I attempt to stop the processor.

µµµµü««««mmmmmmm

are the three symbols i get before BasicX throws a runtime error and shuts itself down.


grr

4am

when attempting to compile my latest iteration of code, i have been receiving all kinds of weird errors. the BasicX editor and downloader are suddenly having trouble opening the Com1 port, which is leading the problems stopping the processor to download new code. Also, after the Com1 fails to open (even though it is open in the options, and I close and re-open it just to be sure), I get a runtime error which crashes BasicX so hard that it closes the program windows.

just another update to how much this isn't cooperating for me :-(

i'm getting more and more irritable and less patient as time goes by here. it feels like my mind is running at half power and i'm fighting off keyboard-napping.

It is now Wednesday afternoon. 2 of the past 3 days have been all-nighters to complete final work for other classes, and today when I went to the open lab session around 11:45 and found a note saying to go to Crossroads to find everyone. Did that and wasn't able to find anyone, so I went back home to BEGIN this project. Looks like a third all-nighter in 4 days. Can't wait to clear out my entire apartment and drive 5 hours home in my already sleep-deprived state tomorrow.

Updates as I progress, I shall probably be working right up til 8am tomorrow.

The car is now working to some degree. I programmed as much functionality as I could without constructing an H gate or some other kind of polarity-switching device, so it runs forwards but not reverse, and can turn left only. However, I have the car responding to all 4 types of radio input without errors when commands overlap. When the controller sends the signal to drive forward, the car drives forward until the stick is returned to the neutral position. The same goes for left hand turns. However, when you press down on the throttle stick, the brake lights illuminate, and a right turn actually switches on the headlights. All in all, I have managed to use the BX to cut the functions of a toy car in half, with the exception that I added some lights to the mix.

The most difficult aspect of this was interpreting the radio receiver's signals. I used LEDs connected to each of the 4 outputs to check where voltage was present. For the forward/reverse functions, up sends power to one pin, and down sends it to the other. For steering functions, the neutral position sends equal voltage to both pins, and when a direction is chosen, that side receives a higher voltage. Here is the code I used to make these unusual inputs usable. The Forwd and Leff functions control the longitudinal and lateral motor controls.

Option Explicit

Public Const radiorvs as Byte = 10
Public Const radiofwd as Byte = 11
Public Const fwd as Byte = 12
Public Const left as Byte = 13
Public Const radioright as Byte = 14
Public Const radioleft as Byte = 15
Public Const tails as Byte = 16
Public Const heads as Byte = 17

Dim reverse as integer
Dim forward as integer
Dim lft as integer
Dim rgt as integer

Sub Main()
do
call Forwd()
call Leff()
loop
end sub

Sub Forwd()
forward = cInt(getpin(radiofwd))
reverse = cInt(getpin(radiorvs))

if forward > reverse then
call putpin(fwd, 1)
call putpin(tails, 0)
debug.print "forward"
elseif forward < reverse then
call putpin(fwd, 0)
call putpin(tails, 1)
debug.print "not forward"
else
call putpin(fwd, 0)
end if
end sub

Sub Leff()
lft = cInt(getpin(radioleft))
rgt = cInt(getpin(radioright))

if lft > rgt then
call putpin(left, 1)
call putpin(heads, 0)
debug.print "left"
elseif lft < rgt then
call putpin(left, 0)
call putpin(heads, 1)
debug.print "right"
else
call putpin(left, 0)
end if
end sub


Interestingly, I am able to decipher the bizarre ADC values from these 4 inputs by casting them to integers and instead reading the getpin value. Because of the unusual method the radio uses to send voltages (both positive and negative switching) the ADC values were hard to read and all 4 fluctuated when any control command was sent by the transmitter. The if elseif else statements were more or less a short in the dark, but they work spectacularly well.

Today in class I was able to isolate the voltage bounce I was seeing last night. 8 drop-down resistors later, I wish I hadn't forgotten the radio controller at home, since I believe I'm now able to see usable input from the radio receiver. I added some code to show the ADC voltages of all 4 radio lines. With the transmitter nowhere in sight, these are the baseline voltages.

*** Downloading File

Writing internal EEPROM
Verifying internal EEPROM
Verify OK
Writing external EEPROM
Verifying external EEPROM
Verify OK

*** Finished Downloading
rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

rear1 ADC =0
rear2 ADC =0
front1 ADC =364
front2 ADC =1020

Gotta see how those are affected when I manipulate the controls...

My project has taken a totally new direction in the past 2 days. I have decided to use the BX chip as a replacement for the onboard logic in a small r/c car . After some creative destruction, the breadboard rides on top of the Lancer as gracefully as a mattress on a pickup truck. When hacking the car, I spliced the BX inline between each of the 4 main radio commands; forward, reverse, left, and right.

Here is some of the first output I saw when I plugged everything in. I have to determine what needs to be done to eliminate the voltage bounce so I can see what kind of input I need to interpret in my code. Here's what I'm lookin at...

*** Opening file: K:\bx\RCcar.bxb

*** Downloading File

Writing internal EEPROM
Verifying internal EEPROM
Verify OK
Writing external EEPROM
Verifying external EEPROM
Verify OK

*** Finished Downloading
rear1 ADC =438
rear1 ADC =129
rear1 ADC =0
rear1 ADC =10
rear1 ADC =124
rear1 ADC =251
rear1 ADC =82
rear1 ADC =0
rear1 ADC =0
rear1 ADC =0
rear1 ADC =10
rear1 ADC =128
rear1 ADC =263
rear1 ADC =65
rear1 ADC =0
rear1 ADC =0
rear1 ADC =11
rear1 ADC =135
rear1 ADC =253
rear1 ADC =64
rear1 ADC =0
rear1 ADC =0
rear1 ADC =10
rear1 ADC =152
rear1 ADC =290
rear1 ADC =67
rear1 ADC =0
rear1 ADC =0
rear1 ADC =15
rear1 ADC =155
rear1 ADC =291
rear1 ADC =64
rear1 ADC =0
rear1 ADC =0
rear1 ADC =11
rear1 ADC =151
rear1 ADC =292
rear1 ADC =69
rear1 ADC =0
rear1 ADC =0
rear1 ADC =4
rear1 ADC =37
rear1 ADC =185
rear1 ADC =277
rear1 ADC =40
rear1 ADC =0
rear1 ADC =2
rear1 ADC =37
rear1 ADC =184
rear1 ADC =276
rear1 ADC =35
rear1 ADC =0
rear1 ADC =1

I hope this will work the way I'm trying to do it. I'm attempting to use 2 separate pins sending alternating positive voltages to control a single motor in two directions (without PWM, this is my own 4 pin method) Going to see what I can do about that oscillation now...

Amazingly, today was a day where nothing went wrong. I hacked my null modem cable and made a sturdy, 5 foot long direct plug-into-the-breadboard module. Also fiddled with my wiring and got my motor to work from chip input. I am still working on the user experience chart for the motor assignment, that is being updated and stored as a draft on here, so once it is complete, it will appear with the time and date I first started it. Not too much else is new, feeling pretty good about a day without hangups :)