Wow! There's a lot of things to digest there.. I see an inconsistency with the I2C bus? RTC has SDA on p28, 16i/o SDA on 29? Also, hardware flow control would be nice on RS232, maybe a jumper to connect Group4 to ?CTS? *I'm not sure which one I'm thinking of, or if the logic would be correct...* Not sure about midi, still concerned with "stuck notes" and such.
Everything else looks great!
I'm currently using the pins I have since the SPI breakouts make them easy to get to.
re:4316 Looks like it would save me a bit of trouble. The 4066 works, just takes more effort and an extra resistor.
I'll keep thinking about the expansion, now to try and figure out why I can't set the '595!
*edit*
I think I figured it out.. Must select group before anything else. I've revised things a bit.. Still figuring things out, think I need a 138 in the mix. I have the 6 checkboxes binding to the '595. Not the best code but it seems to work so far:
DAT
sysfont byte "times20.ifn"
logo byte "logo.bmp"
CON
_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000
OBJ
tch: "Touch" ' touchscreen driver
VAR
byte Slide1,Slide2,Slide3,Slide4,Slide5,Slide6,ButtonStates
PUB Main | wcboot,xval,yval,n ' warm or cold boot '
wcboot := tch.BeginDesktop("S") ' "I" = ILI9325, "S"= SSD1289
'tch.SelectMemGroup
'if wcboot == false ' erase ram chip, checks if a cold or warm boot, sets some variables
'tch.Clearscreen(tch.RGBtoWord(0,0,0)) ' clear screen to black - uses the display driver above
tch.SDBMPtoRam(@logo) ' file number 1, a 240x320 file called logo.bmp
tch.SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons
tch.LoadFont(@sysfont) 'file 3
tch.SetOrientation(false)
tch.DrawBMPRam(1,0,0) ' file number 1, location 0,0
tch.SetCursor(0,5)
tch.TextT(3,string("!!!New & Improved!!!"))
tch.SetCursor(0,220)
tch.TextT(3,string("Created by James Moxham & Joe Heinz"))
n:=0
tch.SelectSPIGroup ' talk to the spi touchscreen
tch.pause1ms(500)
repeat while n == 0
yval := tch.TouchYPercent ' decode yval 0-100%
xval := tch.TouchXPercent ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
n := 1
tch.SelectMemGroup
' deadend
tch.Clearscreen($FFFF_FFFF)
' tch.SelectSPIGroup ' talk to the spi touchscreen
' test2
Buttons
PUB test2 | x
repeat
repeat x from 0 to 255
tch.SetSwitch(x)
tch.pause1ms(250)
PUB Buttons | f,sredraw,bredraw, ck1x,ck2x,ck3x,ck4x,ck5x,ck6x, ck1y,ck2y,ck3y,ck4y,ck5y,ck6y, ck1s,ck2s,ck3s,ck4s,ck5s,ck6s, xval,yval
tch.ClearRam ' file 0 and 1 reserve
tch.LoadFont(@sysfont) 'file 2
f := tch.Loadfont(@sysfont) ' file 3 black on white font
tch.SDBMPtoRam(string("butn8430.bmp")) ' file 4 a button 84x30 in size
tch.SDBMPtoRam(string("Uncheckd.bmp")) ' file 5 unchecked checkbox pic3
tch.SDBMPtoRam(string("Checked.bmp")) ' file 6 checked checkbox pic4
tch.SDBMPtoRam(string("synknb.bmp")) ' file 7
tch.SDBMPtoRam(string("synslbk.bmp")) ' file 8
sredraw := 7
bredraw := 9
' set all the locations of the objects on the screen
ck1y := ck2y := ck3y := ck4y := 140
ck5y := ck6y := ck1y + 100 ' y coordinates all the same
ck5x := ck1x := 25 ' x
ck2x := ck1x + 54
ck3x := ck2x + 54
ck4x := ck3x + 54
ck6x := ck5x + 54
ck1s := true ' startup status
ck2s := true
ck3s := true
ck4s := true
ck5s := true
ck6s := true
' now wait for touch
tch.SelectSPIGroup ' talk to the spi touchscreen
repeat
if sredraw <> 0
RefreshSliders(sredraw)
sredraw := 0
tch.SelectSPIGroup ' talk to the spi touchscreen
if bredraw <> 0 ' if redraw true then redraw all the objects
tch.SelectMemGroup ' display mode
DrawCheckbox(ck1x,ck1y,ck1s,string("Check1"),5,6,f) ' checkbox
DrawCheckbox(ck2x,ck2y,ck2s,string("Check2"),5,6,f) ' checkbox
DrawCheckbox(ck3x,ck3y,ck3s,string("Check3"),5,6,f) ' checkbox
DrawCheckbox(ck4x,ck4y,ck4s,string("Check4"),5,6,f) ' checkbox
DrawCheckbox(ck5x,ck5y,ck5s,string("Check5"),5,6,f) ' checkbox
DrawCheckbox(ck6x,ck6y,ck6s,string("Check6"),5,6,f) ' checkbox
' tch.SelectSPIGroup ' talk to the spi touchscreen
ButtonStates := 0
if ck1s == false
ButtonStates += $01
if ck2s == false
ButtonStates += $02
if ck3s == false
ButtonStates += $04
if ck4s == false
ButtonStates += $08
if ck5s == false
ButtonStates += $10
if ck6s == false
ButtonStates += $20
tch.SetSwitch(ButtonStates)
tch.pause1ms(250)
bredraw := 0
tch.SelectSPIGroup ' talk to the spi touchscreen
yval := tch.TouchYPercent ' decode yval 0-100%
xval := 100 - tch.TouchXPercent ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
xval := (xval * 24) / 10 ' scale to pi8xels as can measure from the picture in paintshop
yval := (yval * 32) / 10 ' scale to pixels
if yval < 100 ' one of the 5 sliders
case xval
2..2+34: Slide1 := ReadSlider(yval,1) ' move the slider and scale value
sredraw := 1
42..42+34: Slide2 := ReadSlider(yval,2)
sredraw := 2
82..82+34: Slide3 := ReadSlider(yval,3)
sredraw := 3
122..122+34:Slide4 := ReadSlider(yval,4)
sredraw := 4
162..162+34:Slide5 := ReadSlider(yval,5)
sredraw := 5
202..202+34:Slide6 := ReadSlider(yval,6)
sredraw := 6
ELSEif yval < 200
case xval
(ck1x-10)..(ck1x+25): !ck1s ' checkbox is small so active area bigger than the checkbox
bredraw := 1 ' redraw the screen
(ck2x-10)..(ck2x+25): !ck2s ' checkbox is small so active area bigger than the checkbox
bredraw := 2
(ck3x-10)..(ck3x+25): !ck3s ' checkbox is small so active area bigger than the checkbox
bredraw := 3 ' redraw the screen
(ck4x-10)..(ck4x+25): !ck4s ' checkbox is small so active area bigger than the checkbox
bredraw := 4 ' redraw the screen
ELSEif yval < 300
CASE xval
(ck5x-10)..(ck5x+25): !ck5s ' checkbox is small so active area bigger than the checkbox
bredraw := 5 ' redraw the screen
(ck6x-10)..(ck6x+25): !ck6s ' checkbox is small so active area bigger than the checkbox
bredraw := 6 ' redraw the screen
PUB DrawCheckbox(y,x,Checked,stringptr,c1,c2,f) | i ' draw a checkbox x,y,checked, string, file for checked, file for unchecked, font file
if checked
tch.DrawBMPRam(c1,x,y)
else
tch.DrawBMPRam(c2,x,y)
tch.setcurx(x+20) ' add 20 width
tch.setcury(y)
tch.TextT(f,stringptr)
PUB SynthSlider(x,y,value) ' value is 0-255. assumes bitmaps in ram
tch.DrawBMPRam(8,x,y) ' draw background
tch.DrawBMPRam(7,x+((value*100)/450),y+5) ' draw the knob
PUB RefreshSliders(s) | n
If s == 7
repeat n from 1 to 6
RedrawOneSlider(n)
ELSE
RedrawOneSlider(s)
PUB ReadSlider(y,n)
' y := y - 132 ' origin of the slider is 132
y := y*256 ' slider is 69 pixels so convert to 256
y := y / 69
if y < 0 ' check bounds
y := 0
if y > 255
y := 255
tch.SelectMemGroup
RedrawOneSlider(n) ' redraw this slider
tch.SelectSPIGroup
result := y
PUB RedrawOneSlider(n) ' n = 1,2,3,4,5,6
case n
1:SynthSlider(0,2,Slide1) ' decay
2:SynthSlider(0,42,Slide2) ' sustain
3:SynthSlider(0,82,Slide3) ' pwminit
4:SynthSlider(0,122,Slide4) ' pwmrate
5:SynthSlider(0,162,Slide5) ' filter (0-12 so multiply by 21)
6:SynthSlider(0,202,Slide6) ' portamento 0 - 16
I see an inconsistency with the I2C bus? RTC has SDA on p28, 16i/o SDA on 29? Also, hardware flow control would be nice on RS232, maybe a jumper to connect Group4 to ?CTS? *I'm not sure which one I'm thinking of, or if the logic would be correct...* Not sure about midi, still concerned with "stuck notes" and such.
Well spotted, thanks. Fixing it now. I'm sure there are other bugs but this board is very modular so on the first run most things should be ok.
Thinking about RS232, what we could do is have a third D9 socket and bring the 4 outputs from the max3232 to that socket - Tx Rx RTS and CTS. That will give us formal flow control. So there are three D9 sockets and you either solder up the two for two Tx/Rx ports or you solder up one socket with full flow control.
595 is a bit tricky - would you need an OR gate on the clock. Maybe an AND gate and inverter - I'll need to check the datasheet. In any case, something to prevent data clocking out when that group is not selected?
Or like you say a 138 selected with a group. Or MCP23008s. Or even use a MCP23008 to create another group and then another 20 pins to use?
Was there a bug with the landscape select on the larger display?
I did some lateral thinking trying to understand my issue connecting to the outside world... Here's what I've learned, hopefully it will save some "WTF" time....
When selecting groups, Pins 0-8 are NOT STABLE... I made the mistake of using "group-3 OR Pin8" for an enable line. So what the REALLY means is "Pins0-8 can be used in group3 or 4, but must be "released" before changing groups." Not sure that's the best way to say it, I'll draw a schematic of what I'm TRYING to do a bit later. I realized if I move the enable line to "group-3 OR Pin9" everything works fine, well almost.
As that applies to your expansion board, I see the POSSIBILITY of problems in group4. I would swap VGA with SD & Serial to be safe. Back to the breadboard to see if I can get the '595 AND the 5206 to work right. Then to figure out reading the guitar switch! I think a 137 is looking pretty nice right now.
*edit*
RE: rs232... I think that COULD be a possibility, but it would almost be easier to have jumpers to configure for 2-data only or 1 FULL port.
The '595 was fairly easy to control once I spotted my problem. With pins 6-8 changing in the group change, the OC was toggling during the group change. Since P6-7 are D/C and "P8 OR G3" are OC, A steady state is not achieved before group hand-off. Change P8 to P9 *and make sure software doesn't MESS with P9 during hand-off* and everything works fine!
*aedit* There are a number of solutions to my current problem and I've considered the MCP. It would work but the problem was my lack of understanding of "group pins"
The landscape "BUG" is 50/50, mostly poor understanding. Use "tch.SetOrientation(false)" not"tch.ChangeOrientation(false), the landscape commands were wrong. Fixed:
Displaycmd($0001,$6B3F) '$4B3F ' set SS and SM bit 0001 0000 landscape
Displaycmd($0011,$6838 ) '6838 ' landscape $1028 = original but 1038 is correct - not mirror image
As that applies to your expansion board, I see the POSSIBILITY of problems in group4. I would swap VGA with SD & Serial to be safe.
Yes good point. When we had the MCP23008 solution the changover was cleaner but much slower. So the downside for speed is the pins changing. Having said that though, there is some code to do the changover (at work and from memory) the first and last thing is P22 changing which should stop spurious toggling. In any case, to be sure, P0-P8 should be things where it does not matter, eg a VGA display rather than a serial port. But I'll have to check it again.
Thinking about that some more, if this does become an issue, the problem with speed was the loading of the 161 chips multiple times and for group 3,4,5 etc speed may not be such an issue. So maybe on the expansion board it might be better to add a MCP23008 and call the outputs "group 5-12".
Hmm - on the other hand, group 3 is the group waiting for the touchscreen to be touched so there is some logic in putting mission critical things in group 3. ie MIDI, serial, radio, analog inputs, possibly keyboard.
Another thing - if you want to experiment with ideas you could bring those 34 pins for the expansion port onto a breadboard and test a few of those ideas. If something works well we can put it on the expansion board.
Addit - re pins changing, at the moment it is P8 low then P22 high - I wonder what would happen if we changed that so P22 goes high first?
set373 or dira,maskP22 ' and pin 22
or dira,#%1_11111111 ' enable pins 0-7 and 8 as outputs
andn outa,maskP8 ' P8 low
or outa,maskP22 ' pin 22 high
and outa,maskP0P7low ' P0-P7 low
or outa,latchvalue ' send out the data
or outa,maskP8 ' P8 high, clocks out data
andn outa,maskP8 ' P8 low
andn outa,maskP22 ' pin 22 low
set373_ret ret
I really like this board. I like the fact it's not using i2c for groups. Will make XMM/XMMC much easier.
RE Pin22... Excellent point, Group OR P22 would probably solve the issue.
I'm re-wiring with a '245 as an isolator. P6..10 = A0..4, G3 = A7, G3 = /OC. This will give better fan-out *at 5v!* DIR is tied high. B outputs have 10k pullup. Now B0..1 = SPI - D/C. B0..2 = 137(C..A), 137(/LE)= B3, 137(/EN) =B4. Last, 137(O0) = 595 /oc, 137(O1) = 5206 /en. Should work better.
I haven't tested it, but if the very first thing in a group change is p22 going high that should put all the group pins into HiZ which is effectively high via the pullups. That should disable anything in that group so therefore P8 changes should no longer get through.
Re a 245 if you are going to 5V in theory I think HC245 is close to the logic threshold for a high at 3.3V and a HCT is more definite. Having said that, it is theory as I've used HC before with the 3.3 to 5V transition.
You're on the right track with the group change IMO. If this doesn't work it's not a huge deal. Stabilizing group changes is good for future use.
RE : 'HC's , I have some hct's floating around somewhere, but HC seems to be working fine. The only reason I REALLY need the translation is for debugging LEDs. The 5v chips were clocking fine from 3.3v until I stick an LED on the bus. Finishing test code right now!
The MCP3208 8 channel A to D is only a dollar more than the dual MCP2302. On the propeller board there wasn't room but for the expansion board it can't hurt to have some more inputs. Maybe 6 could be DC inputs and 2 could be AC with the signal conditioning?
jazzed has some thoughts on the cache driver over on the C thread. There is plenty of room in those ram chips for a big C program.
I have not even visited the c thread yet. Still trying to "learn" the board. Things are getting closer, but I'm not quite there yet.
re MCP3208 : Sounds like a great idea to me!
The one thing I'd LOVE to play with, but can't YET is:
Got the Ol BoeBot...Brand new servos, *no ping yet* and a full refresher kit. I'd love to use the board to "wireless" comms with the BoeBot. I'm missing the wireless component right now... I'd also love to get my hands on a PropBOE, that will have to wait. Still... there's gotta be a way to experiment without the Bluetooth packs... Any thoughts?
*edit*
Just had one of those DUH moments.... This time it wasn't even looking @code...
Screwed the pooch building the board because I was lazy and in a hurry.
Since I'm short on 10k R networks *need to desolder a bunch* I used 100k for Pins Resistors....
Works fine on 3.3v but @5v....
DUH.
Re pullups... They SHOULD, although I'm suspect on them pulling a 5v high off of 3.3v... Need to do the maths...
Finally drew up equivalent schematic. The second 595 is actually an AD5206... It's just another spi device, pull enable low, clock 13bits, enable high.
No labels on inputs BUT... 245(A7-/OE) is group 3, A0-5 is P6-10.
Now to watch Breaking BAD!!!
*edit*
Okay, so I got it... It's so simple it's stupid... Now to implement reading Guitarswitch... Blah. The ad5206 updates from the 6 sliders, the 595 clocks the 6 checkboxes *not using the last 2 bits right now* Now I know it can interact with the world in a TON of different ways... Need to find my Analog Devices 2chDAC. Can't remember the part number. ****AD7303**** Then I'll have the two 5v control voltages I'll be using with a "hacked" VCA.
The breadboard is filling up with my analog design. I think I'm missing a cap, and I think I know where it goes BUT. I need to check ALL of the points again. And I forgot the 5v to 15v logic transistors. But I'm VERY close to playing my guitar again! LOL
The one thing I know is this version is amazing. I "think" it's faster than the 137, no glitches *!!!change p22 first in group change!!! fixed my problem. Pix and vids to come!
Early *working* SPI/137 control methods
DAT
sysfont byte "times20.ifn"
logo byte "logo.bmp"
CON
_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000
OBJ
tch: "Touch" ' touchscreen driver
VAR
byte Slide1,Slide2,Slide3,Slide4,Slide5,Slide6,ButtonStates
PUB Main | wcboot,xval,yval,n ' warm or cold boot '
wcboot := tch.BeginDesktop("S") ' "I" = ILI9325, "S"= SSD1289
tch.SDBMPtoRam(@logo) ' file number 1, a 240x320 file called logo.bmp
tch.SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons
tch.LoadFont(@sysfont) 'file 3
tch.SetOrientation(false)
tch.DrawBMPRam(1,0,0) ' file number 1, location 0,0
tch.SetCursor(0,5)
tch.TextT(3,string("!!!New & Improved!!!"))
tch.SetCursor(0,220)
tch.TextT(3,string("Created by James Moxham & Joe Heinz"))
n:=0
tch.SelectSPIGroup ' talk to the spi touchscreen
tch.pause1ms(500)
repeat while n == 0
yval := tch.TouchYPercent ' decode yval 0-100%
xval := tch.TouchXPercent ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
n := 1
tch.SelectMemGroup
tch.Clearscreen($FFFF_FFFF)
Buttons
PUB Buttons | x,f,sredraw,bredraw, ck1x,ck2x,ck3x,ck4x,ck5x,ck6x, ck1y,ck2y,ck3y,ck4y,ck5y,ck6y, ck1s,ck2s,ck3s,ck4s,ck5s,ck6s, xval,yval
tch.ClearRam ' file 0 and 1 reserve
tch.LoadFont(@sysfont) 'file 2
f := tch.Loadfont(@sysfont) ' file 3 black on white font
tch.SDBMPtoRam(string("butn8430.bmp")) ' file 4 a button 84x30 in size
tch.SDBMPtoRam(string("Uncheckd.bmp")) ' file 5 unchecked checkbox pic3
tch.SDBMPtoRam(string("Checked.bmp")) ' file 6 checked checkbox pic4
tch.SDBMPtoRam(string("synknb.bmp")) ' file 7
tch.SDBMPtoRam(string("synslbk.bmp")) ' file 8
sredraw := 7
bredraw := 9
' set all the locations of the objects on the screen
Slide1 := Slide2 := Slide3 := Slide4 := Slide5 := Slide6 := 0
ck1y := ck2y := ck3y := ck4y := 140
ck5y := ck6y := ck1y + 100 ' y coordinates all the same
ck5x := ck1x := 25 ' x
ck2x := ck1x + 54
ck3x := ck2x + 54
ck4x := ck3x + 54
ck6x := ck5x + 54
ck1s := true ' startup status
ck2s := true
ck3s := true
ck4s := true
ck5s := true
ck6s := true
' now wait for touch
tch.SelectSPIGroup ' talk to the spi touchscreen
repeat
if sredraw <> 0
tch.SelectMemGroup ' display mode
RefreshSliders(sredraw)
CASE sredraw
1:tch.SetPot(1,Slide1)
2:tch.SetPot(2,Slide2)
3:tch.SetPot(3,Slide3)
4:tch.SetPot(4,Slide4)
5:tch.SetPot(5,Slide5)
6:tch.SetPot(6,Slide6)
7:tch.SetPot(1,Slide1)
tch.SetPot(2,Slide2)
tch.SetPot(3,Slide3)
tch.SetPot(4,Slide4)
tch.SetPot(5,Slide5)
tch.SetPot(6,Slide6)
sredraw := 0
tch.SelectSPIGroup ' talk to the spi touchscreen
if bredraw <> 0 ' if redraw true then redraw all the objects
tch.SelectMemGroup ' display mode
DrawCheckbox(ck1x,ck1y,ck1s,string("Check1"),5,6,f) ' checkbox
DrawCheckbox(ck2x,ck2y,ck2s,string("Check2"),5,6,f) ' checkbox
DrawCheckbox(ck3x,ck3y,ck3s,string("Check3"),5,6,f) ' checkbox
DrawCheckbox(ck4x,ck4y,ck4s,string("Check4"),5,6,f) ' checkbox
DrawCheckbox(ck5x,ck5y,ck5s,string("Check5"),5,6,f) ' checkbox
DrawCheckbox(ck6x,ck6y,ck6s,string("Check6"),5,6,f) ' checkbox
ButtonStates := 0
if ck1s == false
ButtonStates += $01
if ck2s == false
ButtonStates += $02
if ck3s == false
ButtonStates += $04
if ck4s == false
ButtonStates += $08
if ck5s == false
ButtonStates += $10
if ck6s == false
ButtonStates += $20
tch.SetSwitch(ButtonStates)
tch.pause1ms(250)
bredraw := 0
tch.SelectSPIGroup ' talk to the spi touchscreen
yval := tch.TouchYPercent ' decode yval 0-100%
xval := 100 - tch.TouchXPercent ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
xval := (xval * 24) / 10 ' scale to pi8xels as can measure from the picture in paintshop
yval := (yval * 32) / 10 ' scale to pixels
if yval < 100 ' one of the 5 sliders
case xval
2..2+34: Slide1 := ReadSlider(yval,1) ' move the slider and scale value
sredraw := 1
42..42+34: Slide2 := ReadSlider(yval,2)
sredraw := 2
82..82+34: Slide3 := ReadSlider(yval,3)
sredraw := 3
122..122+34:Slide4 := ReadSlider(yval,4)
sredraw := 4
162..162+34:Slide5 := ReadSlider(yval,5)
sredraw := 5
202..202+34:Slide6 := ReadSlider(yval,6)
sredraw := 6
ELSEif yval < 200
case xval
(ck1x-10)..(ck1x+25): !ck1s ' checkbox is small so active area bigger than the checkbox
bredraw := 1 ' redraw the screen
(ck2x-10)..(ck2x+25): !ck2s ' checkbox is small so active area bigger than the checkbox
bredraw := 2
(ck3x-10)..(ck3x+25): !ck3s ' checkbox is small so active area bigger than the checkbox
bredraw := 3 ' redraw the screen
(ck4x-10)..(ck4x+25): !ck4s ' checkbox is small so active area bigger than the checkbox
bredraw := 4 ' redraw the screen
ELSEif yval < 300
CASE xval
(ck5x-10)..(ck5x+25): !ck5s ' checkbox is small so active area bigger than the checkbox
bredraw := 5 ' redraw the screen
(ck6x-10)..(ck6x+25): !ck6s ' checkbox is small so active area bigger than the checkbox
bredraw := 6 ' redraw the screen
PUB DrawCheckbox(y,x,Checked,stringptr,c1,c2,f) | i ' draw a checkbox x,y,checked, string, file for checked, file for unchecked, font file
if checked
tch.DrawBMPRam(c1,x,y)
else
tch.DrawBMPRam(c2,x,y)
tch.setcurx(x+20) ' add 20 width
tch.setcury(y)
tch.TextT(f,stringptr)
PUB SynthSlider(x,y,value) ' value is 0-255. assumes bitmaps in ram
tch.DrawBMPRam(8,x,y) ' draw background
tch.DrawBMPRam(7,x+((value*100)/450),y+5) ' draw the knob
PUB RefreshSliders(s) | n
If s == 7
repeat n from 1 to 6
RedrawOneSlider(n)
ELSE
RedrawOneSlider(s)
PUB ReadSlider(y,n)
' y := y - 132 ' origin of the slider is 132
y := y*256 ' slider is 69 pixels so convert to 256
y := y / 69
if y < 0 ' check bounds
y := 0
if y > 255
y := 255
tch.SelectMemGroup
RedrawOneSlider(n) ' redraw this slider
tch.SelectSPIGroup
result := y
PUB RedrawOneSlider(n) ' n = 1,2,3,4,5,6
case n
1:SynthSlider(0,2,Slide1) ' decay
2:SynthSlider(0,42,Slide2) ' sustain
3:SynthSlider(0,82,Slide3) ' pwminit
4:SynthSlider(0,122,Slide4) ' pwmrate
5:SynthSlider(0,162,Slide5) ' filter (0-12 so multiply by 21)
6:SynthSlider(0,202,Slide6) ' portamento 0 - 16
*more edit*
Well, I've got the 5v to 15v level shifter done, tested and connected to analog board. Found the discrepancy in the analog board, fixed, primed and ready to hook up guitar. And now I'm completely exhausted! I'll hook things up in the AM and give it a test!
I'm clearly not keeping up here - real work keeps getting in the way. Anyway, back home and I can confirm that changing the order of pin 8 and 22 works fine
set373 or dira,maskP22 ' and pin 22
or dira,#%1_11111111 ' enable pins 0-7 and 8 as outputs
or outa,maskP22 ' pin 22 high
andn outa,maskP8 ' P8 low
and outa,maskP0P7low ' P0-P7 low
or outa,latchvalue ' send out the data
or outa,maskP8 ' P8 high, clocks out data
andn outa,maskP8 ' P8 low
andn outa,maskP22 ' pin 22 low
set373_ret ret
So what this means is that the handover between groups starts and ends with changing pin 22. Pin 22 is not used for anything else, so that means the group pins go from one being selected low, to all being high, to another being selected low. So that should avoid any possible glitches and it should mean any pins can be used in any group. Just have to remember in code to shut things down gracefully if they need to be when doing group changeovers.
As a side project I am hoping that with a 30ms full screen refresh it is possible to update portions of the screen quick enough that you can run multiple servos and slip in screen refreshes between servo pulses.
Yes I had a free day today. Amazing what you can do with a whole day of coding!
cluso, how can they lose your boards??
Got a little header for the browser - a back button, home button and a space to enter a URL.
Working on hyperlinks now - blue text and need to create a 'hot' area on the touchscreen based on the blue text. Then load up a new html file. There is also an html tag for making a picture a link as well.
html is a fantastic language. I spent a little time looking at vb scripts (which only work on internet explorer). If you can have simple vb scripts, why not simple spin scripts that can do things like change the state of a propeller pin? Then the html can start to be able to interact with the real world.
Working with local files on the SD card at the moment but with the spinneret, hopefully this can move to remote files as well.
The challenge: Take the oldest, most underpowered, decrepit piece of junk you can find, get it to load this thread, and take a picture of it (on a wooden table, if possible).
The rules: The computer must speak TCP and HTTP directly to the web server. No translating proxies, remote access intermediaries, etc. PPP and SLIP servers are fine, as are plain old HTTP proxies if that's necessary for the machine to get out on port 80. So no shitty old Nokia phones running Opera Mini or a built in WAP/WML browser with a translating gateway (but shitty old Nokia phones running real HTTP/HTML browsers are fine). Note that the browser doesn't have to render the page correctly, though if you can find a CP/M web browser with proper CSS3 support, great.
The goal: To get a good laugh, and make the web server logs bewilder Alex.
So far, least-powerful computer is an HP 200LX, 8Mhz 80186 w/2MB ram. Prop may have more horsepower, but a lot less ram.
Which wiznet module? If it speaks SPI, then yes. (or RS232, or I2C).
So far, least-powerful computer is an HP 200LX, 8Mhz 80186 w/2MB ram. Prop may have more horsepower, but a lot less ram.
That sounds interesting, because that is not too far off what we have here. You have 2mb ram, and we have 1mb. Clock speed probably works out about the same. What language was that coded in?
Graphics primitives for HTML are all possible and I have quite a number already working. We need to get this from Spin to C so we can tap into existing code for things like .jpg decompression (can only do .bmp at the moment and most of the web is .jpg) and also the TCP/IP program.
And we need some source code for the simplest web browser. Ideally in C. Size of the program doesn't matter - caching from an SD card means gigabyte sized programs will run. If that can be found, I'll look at how to hook it into the primitive GUI functions like 'draw a text box' and 'draw a picture'. I got some HTML decoded in spin so that bit is not hugely daunting, but spin is limited to the 32k of the propeller whereas C can be much bigger.
Someone mentioned wifi on another thread, and the way things are heading with all the devices my kids are buying, wifi is overtaking cat5 as the preferred network connection. First thing my kids say when they visit family and friends is 'what is your wifi password'. Brave new world!
We can simplify the challenge for the moment by taking a snapshot of the web page which will end up being a html text file and a bunch of pictures, and then cheat and turn the .jpgs into .bmps. Copy that to the SD card and then it is just a matter of putting text and pictures in the right place. ie a primitive web browser. Then come back to the TCP/IP and wiznet interface as a separate project. Does the wiznet do the TCP/IP onboard - looking at the module I think it might. That means it is SPI and much simpler to think about.
This is not crazy stuff. I think it is entirely doable. I'd like to get some boards out soon so others can start experimenting with these sorts of ideas.
The WizNet does include a TCP/IP stack on-chip. The picture of the HP 200LX appears to be running some dos-based browser without image support as I don't see any icons. So, load the page, display boxes where the images should be, take a picture, and post it. Keep in mind, the challenge requires your computer to request the web page itself. The HP is doing that via SLIP over 9600baud serial.
"I built this myself, with a 32-bit microcontroller, an external graphics chip with a meg of ram, and an ethernet controller with IP." That might just get you a lot of props on TDWTF forum.
Running out of code space in Spin, so need to move over to C anyway. Or maybe start to think about more cunning ways of doing things with Spin. You can chain programs using Kye's code, but it takes a few seconds. One could maybe put the jpg decompression into a separate program. Loading up a page would take longer though.
And then there is the problem of most websites being designed for larger screens. I guess that is a problem the mobile phone users are solving in other ways with specific apps like for facebook, designed for that screen.
@averagejoe, something you said a few months ago about whether the I/O is better with adding a second propeller? I've been thinking about that and with all the support chips needed to isolate group 4, another propeller may indeed be a better option. Things like the keyboard can be buffered into a propeller if that group is not selected. Plus if you wanted TV and VGA then there would be no screen blanking with memory access. Plus input from RS232 and MIDI and radio will never be missed as they can be buffered into a propeller.
I thought maybe devote 8 pins to a data bus, 1 for control and one to detect that group 4 is selected (group 4 can be data transfer). Transferring one byte at a time ought to be faster than anything coming into the board, so even 12 bit audio could be buffered.
Another thing I figured was that we shouldn't predetermine what pins should be used for what. So for all the I/O I have put in some jumper blocks and you can use the default pins just by using jumpers (or solder bridges), or you can your own wire links.
@Doc,
re:expansion board...
I completely agree with adding a second prop. Cost is negligible compared to support chips and it would allow MANY things not possible on the current board. I will need some additional time to think about the schematic, reason given later. I REALLY like the idea of using jumpers to select default pins, or wire for other options. Just curious, how many pins do we have left on the header?
re: web browser...
This is something I keep coming back to. I really think C will be the way to go, although it could probably be accomplished in Spin/PASM.The justification for using C is large portions of the code already exist, and thus should speed development. As far as screen resolution, I really think you hit the nail on the head. Even with both screens, we're still still short on pixels. I would like to look into mobile ready HTML since there are a number of sites using this. No time at the present moment.
@ Circuitsoft,
re: WizNet, After a quick peek, should be quite possible. Even probable. I feel wireless could be VERY useful and necessary for some projects. Bluetooth is my "preferred" method but since I don't have any wireless hardware ATM, experiments with this must wait.
Well that was my two cents worth.
On my end, I've started working on a cache driver for the new board. Should be fairly easy, except for the fact I'm a little loopy *the reason I was talking about earlier* I broke a tooth a couple days ago and can't see the dentist until next week. Very painful and over-the-counters are not helping. This has also slowed me down on school as well. I hope to have cache driver done late next week but no promises.
My guitar project has been placed on hold due to noise problems... It works, just WAY too noisy. Need to revisit the power rails I think.. Here's a few pictures of the progress!
*edit*
Had some more time to think about the expansion and I REALLY LIKE IT. Even by itself, it's quite useful. I'm loving the idea of the breadboard area as well as the ability to change pin layout. The only thing missing is the ability to compile a project on the expansion, then program the master... I think it's possible, but as far as I can remember, there is no Spin/PASM compiler running on the propeller yet... I hope I'm wrong.
Attached are the schematic and parts list for the Touchburger board (as per a PM request)
Re getting C running, it is tricky because wherever you put the program, the cache driver needs to be able to shut down other things using the pins. And that might change from time to time and you can't go changing the cache driver code all the time.
Part of the motivation with the expansion board is it greatly simplifies running C. You run the C program cached from the SD card on the main board and that code is all working now so no changes needed there. And you store pictures and other files on the expansion board SD card.
I'll keep thinking about it some more.
Those photos look great.
Hope the tooth gets fixed soon - hard to concentrate on anything with a toothache.
The expansion board is autorouting very quickly so I can experiment with different layouts. I'll post where it is up to tonight.
Got an email from the PCB manufacturers - the boards with the 34 way header have just been shipped.
I think the cache driver should be fairly transparent to the program if we use locks. Lock the bus and make sure the lock belongs to that "thread" before taking control. I believe the GCC guys already have this working. The locking does slow the bus slightly from my initial tests on the original cache driver, but seems like a fair trade. I think the big thing is remembering to release the bus after using it, along with the locking mechanism. I've also been wondering if the cache driver could handle ALL bus interaction. Maybe some hubram dedicated to accepting long command/data, running a circular buffer? Need to think a bit but seems the best way to handle this. At least in C. This means slower bus interaction, but will provide the cache driver exclusive control over the bus?
I think the real flexibility with the expansion board comes from the offloading of I/O operations on the second prop, leaving the master to worry about the display. There is the added complexity of prop2prom comms. I've been thinking about this a bit and still not sure of the best way to do this. I THINK another pin or two could solve some complications using the 8 bit bus. It goes 8bit data, 1 bit R/W, 1 bit clock and 1 /ChipSelect *group4* or add a data/command pin for more flexible command mapping. Maybe this is all unnecessary, still trying to wrap my head around it.
*edit*
After some thought I figured a way around using the 2 additional lines. There is some work necessary to make this possible but shouldn't be too bad. The best way to me is modify the way group 4 is selected. Instead of starting group4 active like the rest of the groups, I would latch group4 in disabled. Then change P0-7 to command, then bring group4 active. Then clock bytes until group4 is disabled. Command could be a structure like (b7= /rd,WR)(b6..4=OP)(b3..0=ADD) where OP is the operation and ADD is the address to perform the operation on. Example (b7=/rd)(b6..4=Buffer)(b3..0=keyboard), this would read the keyboard buffer until empty or group change. Another example (b7=WR)(b6..4=Start)(b3..0=ADC) this would start the ADC conversion with the settings passed as data. Saves the D/C, R/W pins in I mentioned before.
Attached is a preliminary layout of the expansion board.
Keyboard, VGA, TV, 4 servos, general I/O pins, analog inputs, RS232 with flow control, wireless RS232, MIDI in/out, two general purpose SPI ports, headers for all propeller pins, real time clock, SD card and a prototyping area.
We can always build more expansion boards with other things - the nice thing about IDC connectors is you can take a piece of ribbon cable and put as many connections as you have boards.
Re C, the problem I think is not about locks. I think it is more complex than that and the problem applies to both cache in the ram and cache in an SD card. Consider a program that is running and you have finished doing a display update and you change over to group 3 in your C program and open up an SPI link to an A to D chip, and you open a link to the second propeller, and you open a link to the touchscreen, and maybe you open several more links to other SPI chips. The C program moves along a line and suddenly it wants a cache update. To do that from sram you have to change to group 2. That breaks all the links you have established. But you can't do that without running some other C code to formally shut down those links. Hmm - maybe that formal shutdown requires a cache update in itself. The whole thing will crash.
From the point of view of an SPI A to D chip, suddenly its /CS line goes high at a random time. The A to D chip will be fine, but almost certainly data will be lost.
Caching from the SD card is a better solution and I think the C boffins have got the locks working there so your file you happen to have open does not crash. But I can't get the C SD card drivers to open a file in anything under about 4 seconds, and I know that Kye's driver does it almost instantaneously. I would like to translate Kye's spin code into C (which I think can be done with SpintoC) but it won't work if the cache driver is sharing this.
One very simple solution is to offload things to the expansion board. Run the C program from the SD card on the main board and that is completely independent of any other pins as those 4 pins are dedicated to the SD card only. Run Kye's SD driver on the expansion board in Spin, not C, and reduce the code to some simple functions - open file, get record, close file. Then transfer the data between the props, which will be fast - maybe even 8x faster than SD access as the data is in parallel.
Anyway, having said all that, if someone comes up with a clever C solution using just the one board, fine, leave out the SD card on the expansion board. So it is all backwards compatible.
Which brings us to inter prop comms. The 1k resistors are there in case both props try to talk at the same time. I think there must be a solution using just one line for control. There are 3 states each prop can put its end of the line - Low, High and HiZ. Default would be HiZ. Either prop can signal it wants to send by pulling the line low. It could then put it HiZ after a time and wait for an acknowledge Low from the other end. I think it is a similar system to the way I2C works. I2C is one clock, and one data line. This is one clock and 8 data lines.
That is the theory anyway. We have spare prop pins if we need them - give up one of the SPI ports for instance.
I understand what you are saying. Correct me if I'm wrong but, first off, the expansion is on group4 so you will need to change groups anyway to talk to this. Maybe we could stick it on group3... Still...
I think the locks could solve the problem of the catch trying to access the bus while others are using the bus. For example, use two locks(lock0)=busLock,(lock1)=cacheHit. One cog handles most bus control (similar to the ASM portion of the touch.spin). When the main program requests to change from group2 to group3, the cog grabs (Lock1) and if it gets it, just changes group. If it does not, the cache driver is waiting for data so release the bus to the cache driver, and unlock (lock0). The cache driver is stalled waiting to get the lock, and when it does it unlocks (lock1), locks(lock0), grabs the bus, fills the cache, releases the bus, and unlocks (lock0). It then happily waits for the next cache driver hit and locks (lock1) until it owns it, then locks (lock0) until it owns it. The whole process starts over.and over. As long as the "bus cog" does it's job right, everything should play happy. The code to change groups will always be in the cache driver, so this is not an issue.
I keep thinking the best way is to push the touch.spin ASM code into the cache driver so that it's always loaded. One cog handles "master" bus transactions such as group-change and memory read-writes, as well as caching. I think this is possible..
About the control lines, see edit. I think this works without the extra lines.
I understand what you are saying. Correct me if I'm wrong but, first off, the expansion is on group4 so you will need to change groups anyway to talk to this. Maybe we could stick it on group3... Still...
Still thinking about the other things. Meanwhile, yes, that is an idea. Maybe make group 3 pins 12-20 the comms to the expansion board? Then we can leave things in group 3 pretty much all the time?
re: expansion on group3. I had not even thought about what group the expansion was in until you brought up the previous example. Seems like a good idea. I'm still mulling around Prop2Prop comms.
re: cache driver. I started working on the modifications necessary for the new board about an hour ago. I think I'm close, but needed to take a break. I can't test until the morning anyway since I loaned the board to my brother-in-law for documentation purposes. I need to pick the GCC guys brains in the next few days to ensure I understand the cache implementation properly.
I have spent the last 2 weeks negotiating with suppliers and I'm pleased with the results. Need to run cost/profit analysis again but things are looking good. Preparing the "formal" announcement for the last week of August. A few quick updates:
3.2" displays priced under $20! (exact figure depending on quantity of course!)
Memory chips under $4 a piece (bulk order, minimum $50)
The possibility of a free 2GB SD card with full kit!
I've had some interest in kits and even sold one! I've also had some interest in partial kits/parts. I urge those reading this to keep in mind I'm not trying to get rich off selling these kits. I'm simply trying to make the necessary parts easy to order. Currently there are 6 different suppliers to order from. There is also the worry of fraud, buying the displays from China *I've already had this happen to me once.* For inquires, please PM me for more details.
*edit*
Need to finish running the numbers, but it looks like the production board kit will be priced about $35 without displays. Not too bad!
SWEET!!!!
Okay, so with the tooth out and feeling a bit better I started looking at the cache driver again. The version of touch.spin I have does not have set161 is PASM. I don't mind working this out, just wondering what the issues were. This is all I'm missing from the cache driver, I believe. If you have working code, that would be huge. If not I'll try to figure it out. I'm coding for a simple locking system like the GCC guys have working, then I'll try my 2 lock code. It SHOULD work with just 1 lock and I think it will be faster. I'm just wondering if using the 2 locks will help reduce the time the cache is waiting for the bus. Might not really help and actually slow things down. I'll keep you advised of my progress!
Sorry the set161 code beat me. I copied it exactly from the spin, one line at a time into pasm but it didn't work. So either my copying process missed something, or it was too fast in pasm and needed delays. I tried adding delays but no change. So I deliberately deleted that experiment in case an error got replicated if either me or someone else had another go.
I still am not sure how you are going to shut down everything that might be using group3 within the cache driver. It seems to add a layer of complexity to the cache driver that should really be in the program you are running. ie adding code in the cache driver to shut down things that might not even be connected like the A to D chip, every time you do a cache update. That slows things down for a start.
I've really scratched my head on this one and I think the only answer is that whatever pins are talking to the cache, those pins cannot be used for anything else. So on our board, that means the cache has to be either on the I2C bus or on the SD card. I can't see how we can use the sram for program memory with the layout we have.
Of course, with a redesign... Or with the new 128k SPI chips that have just been anounced on another thread.
For the moment I think the best solution is to run the cache from the SD card, and use the existing C drivers that handle reading from SD files and caching at the same time.
Sorry the set161 code beat me. I copied it exactly from the spin, one line at a time into pasm but it didn't work. So either my copying process missed something, or it was too fast in pasm and needed delays. I tried adding delays but no change. So I deliberately deleted that experiment in case an error got replicated if either me or someone else had another go.
I still am not sure how you are going to shut down everything that might be using group3 within the cache driver. It seems to add a layer of complexity to the cache driver that should really be in the program you are running. ie adding code in the cache driver to shut down things that might not even be connected like the A to D chip, every time you do a cache update. That slows things down for a start.
I've really scratched my head on this one and I think the only answer is that whatever pins are talking to the cache, those pins cannot be used for anything else. So on our board, that means the cache has to be either on the I2C bus or on the SD card. I can't see how we can use the sram for program memory with the layout we have.
Of course, with a redesign... Or with the new 128k SPI chips that have just been anounced on another thread.
For the moment I think the best solution is to run the cache from the SD card, and use the existing C drivers that handle reading from SD files and caching at the same time.
re: spi chips are interesting, do you have a proposed implementation?
I'm working on the 161 code now. Very interesting stuff. I'm wondering about possible pin conflicts between the PASM and Spin. Need more time, but I will keep working on this.
I have not been this "deep" on THIS version of the driver. I keep thinking about how to push all bus access to the "master" cog. SD is the exception here since the pins are not used for anything else.
Still need some time to think about this..
I think your proposed solution is acceptable. Maybe later we can look at improving the speed of the cache by sharing SRAM. Seems there's still a bit of work to be done first.
*edit*
This may be a dumb question but what would the impacts of replacing the '373 with a '374?
*aedit*
So I tried and it seems current code works with '374.. Which maybe the way to go. Coding around some issues, trying to figure out what's going on exactly.
Comments
Everything else looks great!
I'm currently using the pins I have since the SPI breakouts make them easy to get to.
re:4316 Looks like it would save me a bit of trouble. The 4066 works, just takes more effort and an extra resistor.
I'll keep thinking about the expansion, now to try and figure out why I can't set the '595!
*edit*
I think I figured it out.. Must select group before anything else. I've revised things a bit.. Still figuring things out, think I need a 138 in the mix. I have the 6 checkboxes binding to the '595. Not the best code but it seems to work so far:
DAT sysfont byte "times20.ifn" logo byte "logo.bmp" CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 OBJ tch: "Touch" ' touchscreen driver VAR byte Slide1,Slide2,Slide3,Slide4,Slide5,Slide6,ButtonStates PUB Main | wcboot,xval,yval,n ' warm or cold boot ' wcboot := tch.BeginDesktop("S") ' "I" = ILI9325, "S"= SSD1289 'tch.SelectMemGroup 'if wcboot == false ' erase ram chip, checks if a cold or warm boot, sets some variables 'tch.Clearscreen(tch.RGBtoWord(0,0,0)) ' clear screen to black - uses the display driver above tch.SDBMPtoRam(@logo) ' file number 1, a 240x320 file called logo.bmp tch.SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons tch.LoadFont(@sysfont) 'file 3 tch.SetOrientation(false) tch.DrawBMPRam(1,0,0) ' file number 1, location 0,0 tch.SetCursor(0,5) tch.TextT(3,string("!!!New & Improved!!!")) tch.SetCursor(0,220) tch.TextT(3,string("Created by James Moxham & Joe Heinz")) n:=0 tch.SelectSPIGroup ' talk to the spi touchscreen tch.pause1ms(500) repeat while n == 0 yval := tch.TouchYPercent ' decode yval 0-100% xval := tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress n := 1 tch.SelectMemGroup ' deadend tch.Clearscreen($FFFF_FFFF) ' tch.SelectSPIGroup ' talk to the spi touchscreen ' test2 Buttons PUB test2 | x repeat repeat x from 0 to 255 tch.SetSwitch(x) tch.pause1ms(250) PUB Buttons | f,sredraw,bredraw, ck1x,ck2x,ck3x,ck4x,ck5x,ck6x, ck1y,ck2y,ck3y,ck4y,ck5y,ck6y, ck1s,ck2s,ck3s,ck4s,ck5s,ck6s, xval,yval tch.ClearRam ' file 0 and 1 reserve tch.LoadFont(@sysfont) 'file 2 f := tch.Loadfont(@sysfont) ' file 3 black on white font tch.SDBMPtoRam(string("butn8430.bmp")) ' file 4 a button 84x30 in size tch.SDBMPtoRam(string("Uncheckd.bmp")) ' file 5 unchecked checkbox pic3 tch.SDBMPtoRam(string("Checked.bmp")) ' file 6 checked checkbox pic4 tch.SDBMPtoRam(string("synknb.bmp")) ' file 7 tch.SDBMPtoRam(string("synslbk.bmp")) ' file 8 sredraw := 7 bredraw := 9 ' set all the locations of the objects on the screen ck1y := ck2y := ck3y := ck4y := 140 ck5y := ck6y := ck1y + 100 ' y coordinates all the same ck5x := ck1x := 25 ' x ck2x := ck1x + 54 ck3x := ck2x + 54 ck4x := ck3x + 54 ck6x := ck5x + 54 ck1s := true ' startup status ck2s := true ck3s := true ck4s := true ck5s := true ck6s := true ' now wait for touch tch.SelectSPIGroup ' talk to the spi touchscreen repeat if sredraw <> 0 RefreshSliders(sredraw) sredraw := 0 tch.SelectSPIGroup ' talk to the spi touchscreen if bredraw <> 0 ' if redraw true then redraw all the objects tch.SelectMemGroup ' display mode DrawCheckbox(ck1x,ck1y,ck1s,string("Check1"),5,6,f) ' checkbox DrawCheckbox(ck2x,ck2y,ck2s,string("Check2"),5,6,f) ' checkbox DrawCheckbox(ck3x,ck3y,ck3s,string("Check3"),5,6,f) ' checkbox DrawCheckbox(ck4x,ck4y,ck4s,string("Check4"),5,6,f) ' checkbox DrawCheckbox(ck5x,ck5y,ck5s,string("Check5"),5,6,f) ' checkbox DrawCheckbox(ck6x,ck6y,ck6s,string("Check6"),5,6,f) ' checkbox ' tch.SelectSPIGroup ' talk to the spi touchscreen ButtonStates := 0 if ck1s == false ButtonStates += $01 if ck2s == false ButtonStates += $02 if ck3s == false ButtonStates += $04 if ck4s == false ButtonStates += $08 if ck5s == false ButtonStates += $10 if ck6s == false ButtonStates += $20 tch.SetSwitch(ButtonStates) tch.pause1ms(250) bredraw := 0 tch.SelectSPIGroup ' talk to the spi touchscreen yval := tch.TouchYPercent ' decode yval 0-100% xval := 100 - tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress xval := (xval * 24) / 10 ' scale to pi8xels as can measure from the picture in paintshop yval := (yval * 32) / 10 ' scale to pixels if yval < 100 ' one of the 5 sliders case xval 2..2+34: Slide1 := ReadSlider(yval,1) ' move the slider and scale value sredraw := 1 42..42+34: Slide2 := ReadSlider(yval,2) sredraw := 2 82..82+34: Slide3 := ReadSlider(yval,3) sredraw := 3 122..122+34:Slide4 := ReadSlider(yval,4) sredraw := 4 162..162+34:Slide5 := ReadSlider(yval,5) sredraw := 5 202..202+34:Slide6 := ReadSlider(yval,6) sredraw := 6 ELSEif yval < 200 case xval (ck1x-10)..(ck1x+25): !ck1s ' checkbox is small so active area bigger than the checkbox bredraw := 1 ' redraw the screen (ck2x-10)..(ck2x+25): !ck2s ' checkbox is small so active area bigger than the checkbox bredraw := 2 (ck3x-10)..(ck3x+25): !ck3s ' checkbox is small so active area bigger than the checkbox bredraw := 3 ' redraw the screen (ck4x-10)..(ck4x+25): !ck4s ' checkbox is small so active area bigger than the checkbox bredraw := 4 ' redraw the screen ELSEif yval < 300 CASE xval (ck5x-10)..(ck5x+25): !ck5s ' checkbox is small so active area bigger than the checkbox bredraw := 5 ' redraw the screen (ck6x-10)..(ck6x+25): !ck6s ' checkbox is small so active area bigger than the checkbox bredraw := 6 ' redraw the screen PUB DrawCheckbox(y,x,Checked,stringptr,c1,c2,f) | i ' draw a checkbox x,y,checked, string, file for checked, file for unchecked, font file if checked tch.DrawBMPRam(c1,x,y) else tch.DrawBMPRam(c2,x,y) tch.setcurx(x+20) ' add 20 width tch.setcury(y) tch.TextT(f,stringptr) PUB SynthSlider(x,y,value) ' value is 0-255. assumes bitmaps in ram tch.DrawBMPRam(8,x,y) ' draw background tch.DrawBMPRam(7,x+((value*100)/450),y+5) ' draw the knob PUB RefreshSliders(s) | n If s == 7 repeat n from 1 to 6 RedrawOneSlider(n) ELSE RedrawOneSlider(s) PUB ReadSlider(y,n) ' y := y - 132 ' origin of the slider is 132 y := y*256 ' slider is 69 pixels so convert to 256 y := y / 69 if y < 0 ' check bounds y := 0 if y > 255 y := 255 tch.SelectMemGroup RedrawOneSlider(n) ' redraw this slider tch.SelectSPIGroup result := y PUB RedrawOneSlider(n) ' n = 1,2,3,4,5,6 case n 1:SynthSlider(0,2,Slide1) ' decay 2:SynthSlider(0,42,Slide2) ' sustain 3:SynthSlider(0,82,Slide3) ' pwminit 4:SynthSlider(0,122,Slide4) ' pwmrate 5:SynthSlider(0,162,Slide5) ' filter (0-12 so multiply by 21) 6:SynthSlider(0,202,Slide6) ' portamento 0 - 16edits in touch.spinWell spotted, thanks. Fixing it now. I'm sure there are other bugs but this board is very modular so on the first run most things should be ok.
Thinking about RS232, what we could do is have a third D9 socket and bring the 4 outputs from the max3232 to that socket - Tx Rx RTS and CTS. That will give us formal flow control. So there are three D9 sockets and you either solder up the two for two Tx/Rx ports or you solder up one socket with full flow control.
595 is a bit tricky - would you need an OR gate on the clock. Maybe an AND gate and inverter - I'll need to check the datasheet. In any case, something to prevent data clocking out when that group is not selected?
Or like you say a 138 selected with a group. Or MCP23008s. Or even use a MCP23008 to create another group and then another 20 pins to use?
Was there a bug with the landscape select on the larger display?
When selecting groups, Pins 0-8 are NOT STABLE... I made the mistake of using "group-3 OR Pin8" for an enable line. So what the REALLY means is "Pins0-8 can be used in group3 or 4, but must be "released" before changing groups." Not sure that's the best way to say it, I'll draw a schematic of what I'm TRYING to do a bit later. I realized if I move the enable line to "group-3 OR Pin9" everything works fine, well almost.
As that applies to your expansion board, I see the POSSIBILITY of problems in group4. I would swap VGA with SD & Serial to be safe. Back to the breadboard to see if I can get the '595 AND the 5206 to work right. Then to figure out reading the guitar switch! I think a 137 is looking pretty nice right now.
*edit*
RE: rs232... I think that COULD be a possibility, but it would almost be easier to have jumpers to configure for 2-data only or 1 FULL port.
The '595 was fairly easy to control once I spotted my problem. With pins 6-8 changing in the group change, the OC was toggling during the group change. Since P6-7 are D/C and "P8 OR G3" are OC, A steady state is not achieved before group hand-off. Change P8 to P9 *and make sure software doesn't MESS with P9 during hand-off* and everything works fine!
*aedit* There are a number of solutions to my current problem and I've considered the MCP. It would work but the problem was my lack of understanding of "group pins"
The landscape "BUG" is 50/50, mostly poor understanding. Use "tch.SetOrientation(false)" not"tch.ChangeOrientation(false), the landscape commands were wrong. Fixed:
Displaycmd($0001,$6B3F) '$4B3F ' set SS and SM bit 0001 0000 landscape Displaycmd($0011,$6838 ) '6838 ' landscape $1028 = original but 1038 is correct - not mirror imageYes good point. When we had the MCP23008 solution the changover was cleaner but much slower. So the downside for speed is the pins changing. Having said that though, there is some code to do the changover (at work and from memory) the first and last thing is P22 changing which should stop spurious toggling. In any case, to be sure, P0-P8 should be things where it does not matter, eg a VGA display rather than a serial port. But I'll have to check it again.
Thinking about that some more, if this does become an issue, the problem with speed was the loading of the 161 chips multiple times and for group 3,4,5 etc speed may not be such an issue. So maybe on the expansion board it might be better to add a MCP23008 and call the outputs "group 5-12".
Hmm - on the other hand, group 3 is the group waiting for the touchscreen to be touched so there is some logic in putting mission critical things in group 3. ie MIDI, serial, radio, analog inputs, possibly keyboard.
Another thing - if you want to experiment with ideas you could bring those 34 pins for the expansion port onto a breadboard and test a few of those ideas. If something works well we can put it on the expansion board.
Addit - re pins changing, at the moment it is P8 low then P22 high - I wonder what would happen if we changed that so P22 goes high first?
set373 or dira,maskP22 ' and pin 22 or dira,#%1_11111111 ' enable pins 0-7 and 8 as outputs andn outa,maskP8 ' P8 low or outa,maskP22 ' pin 22 high and outa,maskP0P7low ' P0-P7 low or outa,latchvalue ' send out the data or outa,maskP8 ' P8 high, clocks out data andn outa,maskP8 ' P8 low andn outa,maskP22 ' pin 22 low set373_ret retRE Pin22... Excellent point, Group OR P22 would probably solve the issue.
I'm re-wiring with a '245 as an isolator. P6..10 = A0..4, G3 = A7, G3 = /OC. This will give better fan-out *at 5v!* DIR is tied high. B outputs have 10k pullup. Now B0..1 = SPI - D/C. B0..2 = 137(C..A), 137(/LE)= B3, 137(/EN) =B4. Last, 137(O0) = 595 /oc, 137(O1) = 5206 /en. Should work better.
Re a 245 if you are going to 5V in theory I think HC245 is close to the logic threshold for a high at 3.3V and a HCT is more definite. Having said that, it is theory as I've used HC before with the 3.3 to 5V transition.
RE : 'HC's , I have some hct's floating around somewhere, but HC seems to be working fine. The only reason I REALLY need the translation is for debugging LEDs. The 5v chips were clocking fine from 3.3v until I stick an LED on the bus. Finishing test code right now!
The MCP3208 8 channel A to D is only a dollar more than the dual MCP2302. On the propeller board there wasn't room but for the expansion board it can't hurt to have some more inputs. Maybe 6 could be DC inputs and 2 could be AC with the signal conditioning?
jazzed has some thoughts on the cache driver over on the C thread. There is plenty of room in those ram chips for a big C program.
re MCP3208 : Sounds like a great idea to me!
The one thing I'd LOVE to play with, but can't YET is:
Got the Ol BoeBot...Brand new servos, *no ping yet* and a full refresher kit. I'd love to use the board to "wireless" comms with the BoeBot. I'm missing the wireless component right now... I'd also love to get my hands on a PropBOE, that will have to wait. Still... there's gotta be a way to experiment without the Bluetooth packs... Any thoughts?
*edit*
Just had one of those DUH moments.... This time it wasn't even looking @code...
Screwed the pooch building the board because I was lazy and in a hurry.
Since I'm short on 10k R networks *need to desolder a bunch* I used 100k for Pins Resistors....
Works fine on 3.3v but @5v....
DUH.
Finally drew up equivalent schematic. The second 595 is actually an AD5206... It's just another spi device, pull enable low, clock 13bits, enable high.
No labels on inputs BUT... 245(A7-/OE) is group 3, A0-5 is P6-10.
Now to watch Breaking BAD!!!
*edit*
Okay, so I got it... It's so simple it's stupid... Now to implement reading Guitarswitch... Blah. The ad5206 updates from the 6 sliders, the 595 clocks the 6 checkboxes *not using the last 2 bits right now* Now I know it can interact with the world in a TON of different ways... Need to find my Analog Devices 2chDAC. Can't remember the part number. ****AD7303**** Then I'll have the two 5v control voltages I'll be using with a "hacked" VCA.
The breadboard is filling up with my analog design. I think I'm missing a cap, and I think I know where it goes BUT. I need to check ALL of the points again. And I forgot the 5v to 15v logic transistors. But I'm VERY close to playing my guitar again! LOL
The one thing I know is this version is amazing. I "think" it's faster than the 137, no glitches *!!!change p22 first in group change!!! fixed my problem. Pix and vids to come!
Early *working* SPI/137 control methods
PRI Set137(mode) outa[10..9] := 3 dira[10..9] := 3 LatchGroup3 outa[8..6] := mode dira[8..6] := 7 outa[10] := 0 outa[10] := 1 dira[8..6] := 0 PUB SetSwitch(data) Set137(1) SPI.Start(3,0) SPI.SHIFTOUT(7,6, 5, 8 , data) outa[9] := 0 outa[9] := 1 Set137(0) PUB SetPot(potNum,data) |dout Set137(2) dout := ((potNum -1) << 8) + data outa[9] := 0 SPI.Start(3,0) SPI.SHIFTOUT(7,6, 5, 16 , dout) outa[9] := 1 PUB GetGswitch 'not doneMain program:DAT sysfont byte "times20.ifn" logo byte "logo.bmp" CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 OBJ tch: "Touch" ' touchscreen driver VAR byte Slide1,Slide2,Slide3,Slide4,Slide5,Slide6,ButtonStates PUB Main | wcboot,xval,yval,n ' warm or cold boot ' wcboot := tch.BeginDesktop("S") ' "I" = ILI9325, "S"= SSD1289 tch.SDBMPtoRam(@logo) ' file number 1, a 240x320 file called logo.bmp tch.SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons tch.LoadFont(@sysfont) 'file 3 tch.SetOrientation(false) tch.DrawBMPRam(1,0,0) ' file number 1, location 0,0 tch.SetCursor(0,5) tch.TextT(3,string("!!!New & Improved!!!")) tch.SetCursor(0,220) tch.TextT(3,string("Created by James Moxham & Joe Heinz")) n:=0 tch.SelectSPIGroup ' talk to the spi touchscreen tch.pause1ms(500) repeat while n == 0 yval := tch.TouchYPercent ' decode yval 0-100% xval := tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress n := 1 tch.SelectMemGroup tch.Clearscreen($FFFF_FFFF) Buttons PUB Buttons | x,f,sredraw,bredraw, ck1x,ck2x,ck3x,ck4x,ck5x,ck6x, ck1y,ck2y,ck3y,ck4y,ck5y,ck6y, ck1s,ck2s,ck3s,ck4s,ck5s,ck6s, xval,yval tch.ClearRam ' file 0 and 1 reserve tch.LoadFont(@sysfont) 'file 2 f := tch.Loadfont(@sysfont) ' file 3 black on white font tch.SDBMPtoRam(string("butn8430.bmp")) ' file 4 a button 84x30 in size tch.SDBMPtoRam(string("Uncheckd.bmp")) ' file 5 unchecked checkbox pic3 tch.SDBMPtoRam(string("Checked.bmp")) ' file 6 checked checkbox pic4 tch.SDBMPtoRam(string("synknb.bmp")) ' file 7 tch.SDBMPtoRam(string("synslbk.bmp")) ' file 8 sredraw := 7 bredraw := 9 ' set all the locations of the objects on the screen Slide1 := Slide2 := Slide3 := Slide4 := Slide5 := Slide6 := 0 ck1y := ck2y := ck3y := ck4y := 140 ck5y := ck6y := ck1y + 100 ' y coordinates all the same ck5x := ck1x := 25 ' x ck2x := ck1x + 54 ck3x := ck2x + 54 ck4x := ck3x + 54 ck6x := ck5x + 54 ck1s := true ' startup status ck2s := true ck3s := true ck4s := true ck5s := true ck6s := true ' now wait for touch tch.SelectSPIGroup ' talk to the spi touchscreen repeat if sredraw <> 0 tch.SelectMemGroup ' display mode RefreshSliders(sredraw) CASE sredraw 1:tch.SetPot(1,Slide1) 2:tch.SetPot(2,Slide2) 3:tch.SetPot(3,Slide3) 4:tch.SetPot(4,Slide4) 5:tch.SetPot(5,Slide5) 6:tch.SetPot(6,Slide6) 7:tch.SetPot(1,Slide1) tch.SetPot(2,Slide2) tch.SetPot(3,Slide3) tch.SetPot(4,Slide4) tch.SetPot(5,Slide5) tch.SetPot(6,Slide6) sredraw := 0 tch.SelectSPIGroup ' talk to the spi touchscreen if bredraw <> 0 ' if redraw true then redraw all the objects tch.SelectMemGroup ' display mode DrawCheckbox(ck1x,ck1y,ck1s,string("Check1"),5,6,f) ' checkbox DrawCheckbox(ck2x,ck2y,ck2s,string("Check2"),5,6,f) ' checkbox DrawCheckbox(ck3x,ck3y,ck3s,string("Check3"),5,6,f) ' checkbox DrawCheckbox(ck4x,ck4y,ck4s,string("Check4"),5,6,f) ' checkbox DrawCheckbox(ck5x,ck5y,ck5s,string("Check5"),5,6,f) ' checkbox DrawCheckbox(ck6x,ck6y,ck6s,string("Check6"),5,6,f) ' checkbox ButtonStates := 0 if ck1s == false ButtonStates += $01 if ck2s == false ButtonStates += $02 if ck3s == false ButtonStates += $04 if ck4s == false ButtonStates += $08 if ck5s == false ButtonStates += $10 if ck6s == false ButtonStates += $20 tch.SetSwitch(ButtonStates) tch.pause1ms(250) bredraw := 0 tch.SelectSPIGroup ' talk to the spi touchscreen yval := tch.TouchYPercent ' decode yval 0-100% xval := 100 - tch.TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress xval := (xval * 24) / 10 ' scale to pi8xels as can measure from the picture in paintshop yval := (yval * 32) / 10 ' scale to pixels if yval < 100 ' one of the 5 sliders case xval 2..2+34: Slide1 := ReadSlider(yval,1) ' move the slider and scale value sredraw := 1 42..42+34: Slide2 := ReadSlider(yval,2) sredraw := 2 82..82+34: Slide3 := ReadSlider(yval,3) sredraw := 3 122..122+34:Slide4 := ReadSlider(yval,4) sredraw := 4 162..162+34:Slide5 := ReadSlider(yval,5) sredraw := 5 202..202+34:Slide6 := ReadSlider(yval,6) sredraw := 6 ELSEif yval < 200 case xval (ck1x-10)..(ck1x+25): !ck1s ' checkbox is small so active area bigger than the checkbox bredraw := 1 ' redraw the screen (ck2x-10)..(ck2x+25): !ck2s ' checkbox is small so active area bigger than the checkbox bredraw := 2 (ck3x-10)..(ck3x+25): !ck3s ' checkbox is small so active area bigger than the checkbox bredraw := 3 ' redraw the screen (ck4x-10)..(ck4x+25): !ck4s ' checkbox is small so active area bigger than the checkbox bredraw := 4 ' redraw the screen ELSEif yval < 300 CASE xval (ck5x-10)..(ck5x+25): !ck5s ' checkbox is small so active area bigger than the checkbox bredraw := 5 ' redraw the screen (ck6x-10)..(ck6x+25): !ck6s ' checkbox is small so active area bigger than the checkbox bredraw := 6 ' redraw the screen PUB DrawCheckbox(y,x,Checked,stringptr,c1,c2,f) | i ' draw a checkbox x,y,checked, string, file for checked, file for unchecked, font file if checked tch.DrawBMPRam(c1,x,y) else tch.DrawBMPRam(c2,x,y) tch.setcurx(x+20) ' add 20 width tch.setcury(y) tch.TextT(f,stringptr) PUB SynthSlider(x,y,value) ' value is 0-255. assumes bitmaps in ram tch.DrawBMPRam(8,x,y) ' draw background tch.DrawBMPRam(7,x+((value*100)/450),y+5) ' draw the knob PUB RefreshSliders(s) | n If s == 7 repeat n from 1 to 6 RedrawOneSlider(n) ELSE RedrawOneSlider(s) PUB ReadSlider(y,n) ' y := y - 132 ' origin of the slider is 132 y := y*256 ' slider is 69 pixels so convert to 256 y := y / 69 if y < 0 ' check bounds y := 0 if y > 255 y := 255 tch.SelectMemGroup RedrawOneSlider(n) ' redraw this slider tch.SelectSPIGroup result := y PUB RedrawOneSlider(n) ' n = 1,2,3,4,5,6 case n 1:SynthSlider(0,2,Slide1) ' decay 2:SynthSlider(0,42,Slide2) ' sustain 3:SynthSlider(0,82,Slide3) ' pwminit 4:SynthSlider(0,122,Slide4) ' pwmrate 5:SynthSlider(0,162,Slide5) ' filter (0-12 so multiply by 21) 6:SynthSlider(0,202,Slide6) ' portamento 0 - 16*more edit*
Well, I've got the 5v to 15v level shifter done, tested and connected to analog board. Found the discrepancy in the analog board, fixed, primed and ready to hook up guitar. And now I'm completely exhausted! I'll hook things up in the AM and give it a test!
set373 or dira,maskP22 ' and pin 22 or dira,#%1_11111111 ' enable pins 0-7 and 8 as outputs or outa,maskP22 ' pin 22 high andn outa,maskP8 ' P8 low and outa,maskP0P7low ' P0-P7 low or outa,latchvalue ' send out the data or outa,maskP8 ' P8 high, clocks out data andn outa,maskP8 ' P8 low andn outa,maskP22 ' pin 22 low set373_ret retSo what this means is that the handover between groups starts and ends with changing pin 22. Pin 22 is not used for anything else, so that means the group pins go from one being selected low, to all being high, to another being selected low. So that should avoid any possible glitches and it should mean any pins can be used in any group. Just have to remember in code to shut things down gracefully if they need to be when doing group changeovers.
As a side project I am hoping that with a 30ms full screen refresh it is possible to update portions of the screen quick enough that you can run multiple servos and slip in screen refreshes between servo pulses.
Can you connect it to a WizNet module?
Old Computer Challenge
So far, least-powerful computer is an HP 200LX, 8Mhz 80186 w/2MB ram. Prop may have more horsepower, but a lot less ram.
Which wiznet module? If it speaks SPI, then yes. (or RS232, or I2C).
That sounds interesting, because that is not too far off what we have here. You have 2mb ram, and we have 1mb. Clock speed probably works out about the same. What language was that coded in?
Graphics primitives for HTML are all possible and I have quite a number already working. We need to get this from Spin to C so we can tap into existing code for things like .jpg decompression (can only do .bmp at the moment and most of the web is .jpg) and also the TCP/IP program.
And we need some source code for the simplest web browser. Ideally in C. Size of the program doesn't matter - caching from an SD card means gigabyte sized programs will run. If that can be found, I'll look at how to hook it into the primitive GUI functions like 'draw a text box' and 'draw a picture'. I got some HTML decoded in spin so that bit is not hugely daunting, but spin is limited to the 32k of the propeller whereas C can be much bigger.
Someone mentioned wifi on another thread, and the way things are heading with all the devices my kids are buying, wifi is overtaking cat5 as the preferred network connection. First thing my kids say when they visit family and friends is 'what is your wifi password'. Brave new world!
We can simplify the challenge for the moment by taking a snapshot of the web page which will end up being a html text file and a bunch of pictures, and then cheat and turn the .jpgs into .bmps. Copy that to the SD card and then it is just a matter of putting text and pictures in the right place. ie a primitive web browser. Then come back to the TCP/IP and wiznet interface as a separate project. Does the wiznet do the TCP/IP onboard - looking at the module I think it might. That means it is SPI and much simpler to think about.
This is not crazy stuff. I think it is entirely doable. I'd like to get some boards out soon so others can start experimenting with these sorts of ideas.
"I built this myself, with a 32-bit microcontroller, an external graphics chip with a meg of ram, and an ethernet controller with IP." That might just get you a lot of props on TDWTF forum.
SLIP? http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol
Ah, we should be able to do that, this board has a serial port and it can go 115200 baud.
Need source code for a browser - something from years ago ideally back when things were simpler.
http://forums.parallax.com/showthread.php?137266-Propeller-GUI-touchscreen-and-full-color-display&p=1075043#post1075043
Anyway, go find Lynx or Links.
That was half a browser
Running out of code space in Spin, so need to move over to C anyway. Or maybe start to think about more cunning ways of doing things with Spin. You can chain programs using Kye's code, but it takes a few seconds. One could maybe put the jpg decompression into a separate program. Loading up a page would take longer though.
And then there is the problem of most websites being designed for larger screens. I guess that is a problem the mobile phone users are solving in other ways with specific apps like for facebook, designed for that screen.
Checking lynx now http://en.wikipedia.org/wiki/Lynx_(web_browser) and http://lynx.isc.org/lynx2.8.7/index.html
I thought maybe devote 8 pins to a data bus, 1 for control and one to detect that group 4 is selected (group 4 can be data transfer). Transferring one byte at a time ought to be faster than anything coming into the board, so even 12 bit audio could be buffered.
Another thing I figured was that we shouldn't predetermine what pins should be used for what. So for all the I/O I have put in some jumper blocks and you can use the default pins just by using jumpers (or solder bridges), or you can your own wire links.
I added flow control on the RS232.
Your thoughts?
re:expansion board...
I completely agree with adding a second prop. Cost is negligible compared to support chips and it would allow MANY things not possible on the current board. I will need some additional time to think about the schematic, reason given later. I REALLY like the idea of using jumpers to select default pins, or wire for other options. Just curious, how many pins do we have left on the header?
re: web browser...
This is something I keep coming back to. I really think C will be the way to go, although it could probably be accomplished in Spin/PASM.The justification for using C is large portions of the code already exist, and thus should speed development. As far as screen resolution, I really think you hit the nail on the head. Even with both screens, we're still still short on pixels. I would like to look into mobile ready HTML since there are a number of sites using this. No time at the present moment.
@ Circuitsoft,
re: WizNet, After a quick peek, should be quite possible. Even probable. I feel wireless could be VERY useful and necessary for some projects. Bluetooth is my "preferred" method but since I don't have any wireless hardware ATM, experiments with this must wait.
Well that was my two cents worth.
On my end, I've started working on a cache driver for the new board. Should be fairly easy, except for the fact I'm a little loopy *the reason I was talking about earlier* I broke a tooth a couple days ago and can't see the dentist until next week. Very painful and over-the-counters are not helping. This has also slowed me down on school as well. I hope to have cache driver done late next week but no promises.
My guitar project has been placed on hold due to noise problems... It works, just WAY too noisy. Need to revisit the power rails I think.. Here's a few pictures of the progress!
*edit*
Had some more time to think about the expansion and I REALLY LIKE IT. Even by itself, it's quite useful. I'm loving the idea of the breadboard area as well as the ability to change pin layout. The only thing missing is the ability to compile a project on the expansion, then program the master... I think it's possible, but as far as I can remember, there is no Spin/PASM compiler running on the propeller yet... I hope I'm wrong.
Re getting C running, it is tricky because wherever you put the program, the cache driver needs to be able to shut down other things using the pins. And that might change from time to time and you can't go changing the cache driver code all the time.
Part of the motivation with the expansion board is it greatly simplifies running C. You run the C program cached from the SD card on the main board and that code is all working now so no changes needed there. And you store pictures and other files on the expansion board SD card.
I'll keep thinking about it some more.
Those photos look great.
Hope the tooth gets fixed soon - hard to concentrate on anything with a toothache.
The expansion board is autorouting very quickly so I can experiment with different layouts. I'll post where it is up to tonight.
Got an email from the PCB manufacturers - the boards with the 34 way header have just been shipped.
I think the real flexibility with the expansion board comes from the offloading of I/O operations on the second prop, leaving the master to worry about the display. There is the added complexity of prop2prom comms. I've been thinking about this a bit and still not sure of the best way to do this. I THINK another pin or two could solve some complications using the 8 bit bus. It goes 8bit data, 1 bit R/W, 1 bit clock and 1 /ChipSelect *group4* or add a data/command pin for more flexible command mapping. Maybe this is all unnecessary, still trying to wrap my head around it.
*edit*
After some thought I figured a way around using the 2 additional lines. There is some work necessary to make this possible but shouldn't be too bad. The best way to me is modify the way group 4 is selected. Instead of starting group4 active like the rest of the groups, I would latch group4 in disabled. Then change P0-7 to command, then bring group4 active. Then clock bytes until group4 is disabled. Command could be a structure like (b7= /rd,WR)(b6..4=OP)(b3..0=ADD) where OP is the operation and ADD is the address to perform the operation on. Example (b7=/rd)(b6..4=Buffer)(b3..0=keyboard), this would read the keyboard buffer until empty or group change. Another example (b7=WR)(b6..4=Start)(b3..0=ADC) this would start the ADC conversion with the settings passed as data. Saves the D/C, R/W pins in I mentioned before.
Keyboard, VGA, TV, 4 servos, general I/O pins, analog inputs, RS232 with flow control, wireless RS232, MIDI in/out, two general purpose SPI ports, headers for all propeller pins, real time clock, SD card and a prototyping area.
We can always build more expansion boards with other things - the nice thing about IDC connectors is you can take a piece of ribbon cable and put as many connections as you have boards.
Re C, the problem I think is not about locks. I think it is more complex than that and the problem applies to both cache in the ram and cache in an SD card. Consider a program that is running and you have finished doing a display update and you change over to group 3 in your C program and open up an SPI link to an A to D chip, and you open a link to the second propeller, and you open a link to the touchscreen, and maybe you open several more links to other SPI chips. The C program moves along a line and suddenly it wants a cache update. To do that from sram you have to change to group 2. That breaks all the links you have established. But you can't do that without running some other C code to formally shut down those links. Hmm - maybe that formal shutdown requires a cache update in itself. The whole thing will crash.
From the point of view of an SPI A to D chip, suddenly its /CS line goes high at a random time. The A to D chip will be fine, but almost certainly data will be lost.
Caching from the SD card is a better solution and I think the C boffins have got the locks working there so your file you happen to have open does not crash. But I can't get the C SD card drivers to open a file in anything under about 4 seconds, and I know that Kye's driver does it almost instantaneously. I would like to translate Kye's spin code into C (which I think can be done with SpintoC) but it won't work if the cache driver is sharing this.
One very simple solution is to offload things to the expansion board. Run the C program from the SD card on the main board and that is completely independent of any other pins as those 4 pins are dedicated to the SD card only. Run Kye's SD driver on the expansion board in Spin, not C, and reduce the code to some simple functions - open file, get record, close file. Then transfer the data between the props, which will be fast - maybe even 8x faster than SD access as the data is in parallel.
Anyway, having said all that, if someone comes up with a clever C solution using just the one board, fine, leave out the SD card on the expansion board. So it is all backwards compatible.
Which brings us to inter prop comms. The 1k resistors are there in case both props try to talk at the same time. I think there must be a solution using just one line for control. There are 3 states each prop can put its end of the line - Low, High and HiZ. Default would be HiZ. Either prop can signal it wants to send by pulling the line low. It could then put it HiZ after a time and wait for an acknowledge Low from the other end. I think it is a similar system to the way I2C works. I2C is one clock, and one data line. This is one clock and 8 data lines.
That is the theory anyway. We have spare prop pins if we need them - give up one of the SPI ports for instance.
I think the locks could solve the problem of the catch trying to access the bus while others are using the bus. For example, use two locks(lock0)=busLock,(lock1)=cacheHit. One cog handles most bus control (similar to the ASM portion of the touch.spin). When the main program requests to change from group2 to group3, the cog grabs (Lock1) and if it gets it, just changes group. If it does not, the cache driver is waiting for data so release the bus to the cache driver, and unlock (lock0). The cache driver is stalled waiting to get the lock, and when it does it unlocks (lock1), locks(lock0), grabs the bus, fills the cache, releases the bus, and unlocks (lock0). It then happily waits for the next cache driver hit and locks (lock1) until it owns it, then locks (lock0) until it owns it. The whole process starts over.and over. As long as the "bus cog" does it's job right, everything should play happy. The code to change groups will always be in the cache driver, so this is not an issue.
I keep thinking the best way is to push the touch.spin ASM code into the cache driver so that it's always loaded. One cog handles "master" bus transactions such as group-change and memory read-writes, as well as caching. I think this is possible..
About the control lines, see edit. I think this works without the extra lines.
The expansion looks good
Still thinking about the other things. Meanwhile, yes, that is an idea. Maybe make group 3 pins 12-20 the comms to the expansion board? Then we can leave things in group 3 pretty much all the time?
Making the changes now...
re: cache driver. I started working on the modifications necessary for the new board about an hour ago. I think I'm close, but needed to take a break. I can't test until the morning anyway since I loaned the board to my brother-in-law for documentation purposes. I need to pick the GCC guys brains in the next few days to ensure I understand the cache implementation properly.
I have spent the last 2 weeks negotiating with suppliers and I'm pleased with the results. Need to run cost/profit analysis again but things are looking good. Preparing the "formal" announcement for the last week of August. A few quick updates:
3.2" displays priced under $20! (exact figure depending on quantity of course!)
Memory chips under $4 a piece (bulk order, minimum $50)
The possibility of a free 2GB SD card with full kit!
I've had some interest in kits and even sold one! I've also had some interest in partial kits/parts. I urge those reading this to keep in mind I'm not trying to get rich off selling these kits. I'm simply trying to make the necessary parts easy to order. Currently there are 6 different suppliers to order from. There is also the worry of fraud, buying the displays from China *I've already had this happen to me once.* For inquires, please PM me for more details.
*edit*
Need to finish running the numbers, but it looks like the production board kit will be priced about $35 without displays. Not too bad!
I'm working on the expansion board - I think it is getting close to doing a small run of boards.
Okay, so with the tooth out and feeling a bit better I started looking at the cache driver again. The version of touch.spin I have does not have set161 is PASM. I don't mind working this out, just wondering what the issues were. This is all I'm missing from the cache driver, I believe. If you have working code, that would be huge. If not I'll try to figure it out. I'm coding for a simple locking system like the GCC guys have working, then I'll try my 2 lock code. It SHOULD work with just 1 lock and I think it will be faster. I'm just wondering if using the 2 locks will help reduce the time the cache is waiting for the bus. Might not really help and actually slow things down. I'll keep you advised of my progress!
I still am not sure how you are going to shut down everything that might be using group3 within the cache driver. It seems to add a layer of complexity to the cache driver that should really be in the program you are running. ie adding code in the cache driver to shut down things that might not even be connected like the A to D chip, every time you do a cache update. That slows things down for a start.
I've really scratched my head on this one and I think the only answer is that whatever pins are talking to the cache, those pins cannot be used for anything else. So on our board, that means the cache has to be either on the I2C bus or on the SD card. I can't see how we can use the sram for program memory with the layout we have.
Of course, with a redesign... Or with the new 128k SPI chips that have just been anounced on another thread.
For the moment I think the best solution is to run the cache from the SD card, and use the existing C drivers that handle reading from SD files and caching at the same time.
re: spi chips are interesting, do you have a proposed implementation?
I'm working on the 161 code now. Very interesting stuff. I'm wondering about possible pin conflicts between the PASM and Spin. Need more time, but I will keep working on this.
I have not been this "deep" on THIS version of the driver. I keep thinking about how to push all bus access to the "master" cog. SD is the exception here since the pins are not used for anything else.
Still need some time to think about this..
I think your proposed solution is acceptable. Maybe later we can look at improving the speed of the cache by sharing SRAM. Seems there's still a bit of work to be done first.
*edit*
This may be a dumb question but what would the impacts of replacing the '373 with a '374?
*aedit*
So I tried and it seems current code works with '374.. Which maybe the way to go. Coding around some issues, trying to figure out what's going on exactly.