Shop OBEX P1 Docs P2 Docs Learn Events
Propeller GUI touchscreen and full color display - Page 16 — Parallax Forums

Propeller GUI touchscreen and full color display

1131416181924

Comments

  • average joeaverage joe Posts: 795
    edited 2012-08-05 03:26
    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
    
    edits in touch.spin
    PUB SetSwitch(data)
      outa[9]      := 1
      LatchGroup3
      dira[7..6]   := 0
      dira[9]      := 1
      SPI.Start(3,0)
      SPI.SHIFTOUT(7,6, 5, 8 , data)
      outa[9]      := 0
      dira[9]      := 0
    
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-05 16:30
    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?
  • average joeaverage joe Posts: 795
    edited 2012-08-05 16:36
    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
    
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-05 17:22
    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 
    
  • average joeaverage joe Posts: 795
    edited 2012-08-05 17:51
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-05 18:02
    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.
  • average joeaverage joe Posts: 795
    edited 2012-08-05 18:37
    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!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-05 20:12
    Searching microchip products at futurlec http://www.futurlec.com/ICSFMicrochip.shtml

    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.
  • average joeaverage joe Posts: 795
    edited 2012-08-05 21:06
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-05 21:56
    You mean the 100k pullups - they should work the same as 10k.
  • average joeaverage joe Posts: 795
    edited 2012-08-05 22:04
    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
    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 done
      
    
    Main 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!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-06 06:54
    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.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-08-10 12:43
    Dr_Acula wrote: »
    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.

    Can you connect it to a WizNet module?

    Old Computer Challenge
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-10 16:07
    Can you connect it to a WizNet module?

    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.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-08-10 16:34
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-10 16:42
    The HP is doing that via SLIP over 9600baud serial.

    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.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-08-10 17:37
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-10 18:17
    I thought you had one already.

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-11 02:27
    @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.

    I added flow control on the RS232.

    Your thoughts?
  • average joeaverage joe Posts: 795
    edited 2012-08-11 03:04
    @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.
    1024 x 768 - 58K
    1024 x 768 - 150K
    1024 x 768 - 126K
    1024 x 768 - 179K
    1024 x 768 - 112K
    1024 x 768 - 180K
    1024 x 768 - 116K
    1024 x 768 - 133K
    1024 x 768 - 147K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-11 18:26
    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.
  • average joeaverage joe Posts: 795
    edited 2012-08-12 03:36
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-12 04:38
    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.
    938 x 598 - 262K
  • average joeaverage joe Posts: 795
    edited 2012-08-12 05:11
    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.

    The expansion looks good :)
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-12 05:32
    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?

    Making the changes now...
  • average joeaverage joe Posts: 795
    edited 2012-08-13 03:26
    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!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-13 04:02
    Sounds good. I posted 27 boards to you today (30 minus three for me!)

    I'm working on the expansion board - I think it is getting close to doing a small run of boards.
  • average joeaverage joe Posts: 795
    edited 2012-08-13 21:41
    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!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-08-13 22:05
    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.
  • average joeaverage joe Posts: 795
    edited 2012-08-14 10:49
    Dr_Acula wrote: »
    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.
Sign In or Register to comment.