OK, I got my kit, and I assembled it with no trouble. But this is just step one, I have a few more hurdles. I have no experience with microcontrollers, and though I think I am pretty clever, I am still on unfamiliar territory when dealing with hex and binary data, shift registers, etc.
Anyway, the goal of this post is to figure out if the board is properly assembled so I can advance to the next stage of the project.
After studying the data sheet, I sent a few commands to the Interface 1 and got some LEDs to come on. I can keep hacking at it, but I am wondering if there is a more definitive way to test the board, and (more interesting) I am interested in learning the basics of sending data to the board so I can write some more interesting applications. I don't know any C yet, but I have some programming experience.
If I missed something in the documentation please let me know.
Thanks!
watts
Newby question for IOWarrior 40
Moderator: Guido Körber
Oh duh
I forgot to add that I am using a Mac with OS X 10.4.8 and the latest SDK download.
watts
watts
Still more!
In the grand tradition of newbie users answering their own questions, I am beginning to figure it out!
I wrote this applescript, and from the result I surmise that the IOWarrior is properly assembled:
tell application "IOWarriorAppleScriptGateway"
--display dialog (IsIOWarriorPresent)
set xCount to 1
repeat while xCount ≤ 256
WriteInterface0 port3 xCount
set xCount to xCount + 1
end repeat
end tell
I guess I will build the next circuit now!
I wrote this applescript, and from the result I surmise that the IOWarrior is properly assembled:
tell application "IOWarriorAppleScriptGateway"
--display dialog (IsIOWarriorPresent)
set xCount to 1
repeat while xCount ≤ 256
WriteInterface0 port3 xCount
set xCount to xCount + 1
end repeat
end tell
I guess I will build the next circuit now!
If anyone cares, here is a pretty good script to test out your IOWarrior construction (if you use a Mac, anyway)
Can anyone tell me why I need to write data backwards from 255 to make the LEDs count forward in binary? If I send the value of xCount, the LEDs light up as follows:
255-> 0 0 0 0 0 0 0 0
254-> 1 0 0 0 0 0 0 0
253-> 0 1 0 0 0 0 0 0
252-> 1 1 0 0 0 0 0 0
003-> 0 0 1 1 1 1 1 1
002-> 1 0 1 1 1 1 1 1
001-> 0 1 1 1 1 1 1 1
000-> 1 1 1 1 1 1 1 1
etc
This is the opposite of what I would have expected.
Paste this into Script Editor, and run it!
--BEGIN APPLESCRIPT
tell application "IOWarriorAppleScriptGateway"
activate
if IsIOWarriorPresent then
--display dialog (IsIOWarriorPresent)
set xCount to 0
repeat while xCount ? 255
say xCount using "Victoria"
WriteInterface0 port3 255 - xCount
--you need to use the inverse value to make the pins
--light up as expected
--I don't know why this is, exactly
delay 1
set xCount to xCount + 1
end repeat
end if
end tell
--END APPLESCRIPT
Can anyone tell me why I need to write data backwards from 255 to make the LEDs count forward in binary? If I send the value of xCount, the LEDs light up as follows:
255-> 0 0 0 0 0 0 0 0
254-> 1 0 0 0 0 0 0 0
253-> 0 1 0 0 0 0 0 0
252-> 1 1 0 0 0 0 0 0
003-> 0 0 1 1 1 1 1 1
002-> 1 0 1 1 1 1 1 1
001-> 0 1 1 1 1 1 1 1
000-> 1 1 1 1 1 1 1 1
etc
This is the opposite of what I would have expected.
Paste this into Script Editor, and run it!
--BEGIN APPLESCRIPT
tell application "IOWarriorAppleScriptGateway"
activate
if IsIOWarriorPresent then
--display dialog (IsIOWarriorPresent)
set xCount to 0
repeat while xCount ? 255
say xCount using "Victoria"
WriteInterface0 port3 255 - xCount
--you need to use the inverse value to make the pins
--light up as expected
--I don't know why this is, exactly
delay 1
set xCount to xCount + 1
end repeat
end if
end tell
--END APPLESCRIPT
Thank you
That makes perfect sense, and I am glad I asked. Too much education and not enough experience had me confused about the actual voltage of high and low pins.
I would have certainly designed something stupid if I hadn't questioned the issue.
This week I am building the LCD interface, hi ho.
I would have certainly designed something stupid if I hadn't questioned the issue.
This week I am building the LCD interface, hi ho.
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Actually this kind of behaviour is very common in digital logic: Active Low Outputs or also called "negative logic".
The reason for this is that it is quite simple to work with output drivers that pull to low and a pull up register to make sure you get a proper high level if the driver is not active.
The reason for this is that it is quite simple to work with output drivers that pull to low and a pull up register to make sure you get a proper high level if the driver is not active.