Propeller GUI touchscreen and full color display



  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-18 - 17:45:55
    Ok, I've got one ordered. Gotta join in the fun!
  • average joeaverage joe Posts: 795
    edited 2013-02-18 - 19:24:27
    Igor_Rast wrote: »
    are there any boards for sale left ? if so how much would it cost me ( shiping to the netherlands).

    I have quite a few boards left. I have all parts, except displays and Propeller Chips. I still need to figure out an exact number but around $50usd. I'll pm further details.
    Igor_Rast wrote: »
    I prefeur a good scematic because i can easly make a proto pcb at scool ,I do have to drill the vias manualy .

    I need to fix the expansion schematic which it adds the second propeller. I have a wiznet hacked onto mine, but no time to do anything cool *like build a browser* You could set up the expansion board for your needs, ie sensors and such. It's best to keep the wiznet off the display controller *TOUCHBURGER* and give it it's own SD card. SD is so slow, separate cards are the way to go IMO.
    Igor_Rast wrote: »
    I also stil have to order a lcd
    had 4.3 inch in mind before . dont hear you mentioning it anywhere . maybe ill just go for the 3.2 inch . or both :p
    any suggestions ??
    so its going to be some time before ill be talking about that , but i realy look forward to it .
    Here's a 4.3 that appears compatible.

    This may actually be better than the 7" display I have since there's less pixels. It uses the same drivers I'm currently working on.
    Hope that answers some questions for now.

    The real limitation at this point is memory.

    320 px * 240 px = 76800 pixels full screen...
    800 px * 480 px = 384000 pixels full screen... that's 5x more pixels than the smaller displays! It looks really nice, but loads very slow and eats up all the memory. SO. Here's what I'm thinking...

    Connect P29 to counters Bit 19. *HighAddressBit* THEN. Stack ramchips. Should be able to double the memory, I'm just not sure how much work it will take. I will take lots of pics, since I can't seem to get around to editing video... Coding THAT should be fun...

    Do you still have an eagle schematic for the expansion board? The PDF I have is "Touchburger Expansion_2" and that's missing last revision. I also want to put the 74HC244 on schematic between boards. It seems to work well, I've only tested one channel at a time.

    Need to get datasheet to verify 100% compatibility with 4.3" display or what modification is needed. On the 7" display, it's disconnect LED-A by removing R8 on display board. and connect to internal 3v3 by solder jumper J1.

    Upon further inspection, I'm confused as to what I broke.
    PUB Testing   | DeskF, maskF
    '' The first PUB is run on boot, so strap all testing here for easy access
    '' For testing root-code changes and starting simple programs.
    '' If you're writing something of substance, much simpler to make this an object and call BeginProgram *or BeginDesktop*
       deskf := SDBMPtoRam(String("800.bmp"))    '$223c9
       text (String("RUNNING"))                         'never runs?? but runs LAST LINE of SDBMPtoRam?
      maskF := SDBMPtoRam(string("mask.bmp"))                   ' file 2, load this here - if load after the strings get a white line on the icons
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-19 - 05:14:50
    @ Dr_ A & average joe . thank you again with the support , I really appreciate it

    i think im gonna dig into some of the scematics to understand it completly and then make my own pcb at scool .
    this way i can make it with the smd propellers and other components that I already have.
    maybe we could make it all fit underneath the 4.3 inch display .

    as for the pin connector , it doesnt really matter which one comes attached, as long as I can make it work . i am printing my own pcb anyway.

    i think i wil be making a first , as large as its needs to be PCB to get everything working together and making sure that it works .
    and after knowing everything is wired correctly like we want , then ill go to the fit it under the lcd PCB .

    and think the way to go is attach a 40 pin ribbon connector to it , and connect that to a pcb that i disign. that has all the rest of the hardware (2 props).this way I can attach the lcd inside a any casing/enclosure easy.

    @average joe
    *thanks for the link , think I wil be ordering exactly that one , just a bit worried about your edit , if it is 100% compatible. nothing a manual solder cant fix ?

    plan/idea is

    • eerprom (2p)
    • propplug interface (2p)
    • Prop to prop communication ( p??)
    • LCD (16p)
    • SD-card1 (4p)
    • Touchscreen (3p?)

    • eerprom (2p)
    • propplug interface (2p)
    • Prop to prop communication ( p??)
    • Wiznet(5p)
    • sd-card2 (4p)
    • CO2 sensor (2p)
    • Temp + Humidity (2p)
    • light (1p)
    • ph + Ec module (2P)
    • Solid state relays (4P)

    something like a webbrouwser runnig the show would be verry cool indeed . included with the wiznet , maybe the display and the webserver run by the same html code. . and that this same html page get served by the wiznet also to open it in other computer & smartphone . Aint that what html5 is all about ?, cross compatibility :smile: . . the lcd may come in a verry good handy for an GUI to setup the netwerk settings needed by the wiznet( ip, gateway. etc) I know , I know . let DHCP get them right ?. have been working on that for some time with mike G and that turns out to work verry good to . but a lcd to display wich settings it finaly got may come verry in handy . and sometime you just want to manualy set these settings . for this a touchscreen lcd would be the bom,

    only thing im not so sure about it yet about the wiznet is about its security, there is no encripted connection code yet(ssl), making a man in a middle atack or other types of attacks possible. dont want that thing getting hacked whiile its controlling things ( relays).have been tying some things out for some time, but not really with succes yet , Time just fly by

    just the idear for now :p going to start on it pretty soon, gotta find the time too

    just a couple of more things to figure out still..

    can i get a part number on the memory used in the schematic ? the rest seems to be labeld.
    i am going to make a new schematic to use , I am currently using KiCad to draw all my scematics

    before i used diptrace ( verry easy to understand ) but i kept hitting the 300 pin free licence version limitation .
    so now i went for the opensource version of things

    running Ubuntu 12.04 . using Simple IDE to program the props, KICAd to make my PCBs ,
    @joe Openshot video editor , an easy program to just cut and past a vid together . maybe just what you need
    No im not ever using windows again

    anyway. ill be asking questions about the schematic pretty soon when i have it all done . ill post

    Thnks Guys
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-19 - 15:17:53
    The memory is AS6C4008-55PCN

    If you are going to add a wiznet well then you are on the cutting edge already. It will be great to have a few more of these boards working.

    @averagejoe, I have an idea for a different schematic which uses less propeller pins. Essentially, if data is going from the ram to the display that needs to be fast. But if you are loading up the ram from the propeller, most likely that is ultimately coming from the SD card. So the data rate is limited to the SD card rate. And if that is slow, then one could send the data in 8 bits to the ram rather than 16 bits. I have an idea for using something like 12 propeller pins to talk to the ram chips, and that frees up about 8 propeller pins. Just an idea - not tested at the moment but I do have some boards made which I will solder up when I get some time.

    For expansion on the current board, we probably could do a lot more with the I2C bus. Have a board that does I2C to analog I/O and a board that does I2C to digital I/O, and then expand it from there.
  • average joeaverage joe Posts: 795
    edited 2013-02-19 - 18:45:08
    @ Dr.A. I think the 12 pin prop interface would work just fine. Using all 16 pins may be overkill, considering the SSD1963 only accepts 8-bit register transfers...

    I keep thinking about SPI-Flash now that I have the SSD1963. It would allow MUCH more memory, something that's just become an issue with the large display. I'm going to stack RAM chips in the next day or two. I'll let you know how it works.

    A ton of analysis with a Logic Analyzer indicates that the weak link is the SD card. I have some ideas how to speed things up, but they will require much work. On the top of the list is writing SRAM with image data DURING processing. This should save some buffer space *my earlier problem was due to buffer overrun over-writing program. Fixed this by doubling RAMBUFFER.*

    Touch.Spin is taking shape. I need to do MUCH more work still. Need to fix DrawFast, then I will post.

    Here's the current Touch.Spin
    BMPtoRAM is broken *if I could get this working, should speed up SDBMPtoRAM significantly.*
    DrawFAST is still broken...

    I just found these :
    8M (1M x 8) Quad SPI Flash!!! $5.52 for 10 from Digikey. I have this crazy idea of using 4-Quad SPI Flash chips to make up the 16 bit data bus. Then only need clock and /cs. That's what I was saving the i2c pins for. I THINK this would be a best of both worlds, super-fast SRAM AND 32M flash!

    *more edit*
    RE: Ribbon cables. Here's my thoughts... I've had quite a bit of trouble when using ribbon cables. The 40-pin cables I had for the displays eventually wore out. That cost me an hour of troubleshooting! I've also made the mistake of thinking an IDE cable will work. IT WON'T. *OKAY, one out of 100 will, maybe. They're also expensive and if they're TOO long, they will mangle the bus. In fact, when using the expansion board connected with a 7" ribbon cable and 2-SSD1289 displays directly to the board, I needed to add a NO-op just after enabling the RAM, otherwise the first bit was always corrupt.
    They work, but I like display plugged directly to board.

    *even more edit*
    Here's what I'm thinking. QUAD-SPI-Flash board.. 4 chips, 4 caps and 34 pin header. Schematic is attached...
    1024 x 768 - 132K
    1024 x 768 - 166K
    1024 x 768 - 84K
    1024 x 768 - 71K
    1024 x 768 - 35K
    1024 x 768 - 111K
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-20 - 03:22:00
    @Dr_A thanks for the memory info

    as i continue to read average joe , jumps in with a new sugestion for a faster SRAM , wich i like , faster always better :p . But confuses things for me a little.
    I think its best for me to follow you without asking too much questions yet , till I get the hardware in house so I can follow up . Kinda hard right now . dont really understand the hole system yet . and im still digging into the datasheets enso.

    I did start to make my schematic . gonna post it soon if I can find all the part needed :p

    cant those 16 data lines be controlled tru a 74hc595 shift register or is that to slow ,( wil take only 3 pins then ) bare with me if i just ask the wrong things not getting it

    how is the communication between the 2 propellers, if there was a second propeller attached , tru pin 28,29 ?

    does this ram stacking change the old schematic , or can i just add the ram together.?

    think im going just for 1 4,3inch display .

    @Dr_A , yes that wiznet is a pretty nice thing indeed, takes up all your time too :p hihi
    i used a Wizio820 Module (picture 1), that comes assembled already with the W5200 on it , just a dip socket swap in. But I always wanted to get the total pricing to the cheapest. if I ever get to build allot of them it will make the difference. anyway ,. I now have a PCB with the wiznet incorporated on it (picture2 + 3), but I havent orderd the part to populate it yet,used it without the wiznet for now. so that still needs to be done , but souldend expect any thing strang hopefully .

    picture 1 - Old wiznet wizio820
    picture 2,3 - new controller pcb . with wiznet etched to it
    picture 4 . My project . Controller. this verion reads the CO2 level. and triggers a relay . akkording, simple display . 2 buttons interface . and a 230VAC 7 Amp Solid state relay . wiznet remaind unpopulated .

    Here is where I hoped to replace , the simple 4 digit LCD , 2 bottons for interface, and leds that it used to have , and replace it with the touchescreen lcd , but back the wiznet . Add a bunch a more sensors and relays.

    2013-01-17 14.50.53.jpg
    2013-02-20 12.00.38.jpg
    2013-02-20 12.00.34.jpg

    @average joe
    Nice pictures by the way, gets me exited . and I agree with you about the ribbons, though it as a testing solution , but I also will go for the lcd in the board, just works better as a hole . the pic 2+ 3 I also did something like that , all components on one side of the pcb , and the lcd on the other side. ill figure gomething out , when I get the parts in my hand :P
    1024 x 768 - 90K
    1024 x 1365 - 144K
    1024 x 1365 - 163K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-20 - 04:13:21
    Hi averagejoe

    1) first attachment, fixed the bug with the second touchscreen touch part SPI pinout wrong
    2) Attached is a concept for a touchscreen addon board for the new Centimanes system. Split into a propeller motherboard and an addon board. Makes designing addon boards easier. Will need changing from 5V on pin 3 to 3V3. Let me know if you spot any errors.
    3) What is the general concept regarding faster ram? Do these 800x480 boards work in 8 bit or 16 bit mode?

    We have to get the wiznet into this. I have some half finished code for a html browser. Text is not to bad. Big issue is decoding .jpg files. .bmp is easy but .jpg is going to need some C code and that is going to need an implementation of C and for C, we need an external memory system that is asynchronous to the display. This is why I want a design that uses less pins to talk to the display, so we can free up at least 4 pins for talking to an SPI ram chip for the C code cache ram.
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-20 - 04:42:57

    Mike G has a google code repository going for the wiznet . Wel documented. but still working on it ,
    id say take a look

    Wiznet Page
  • average joeaverage joe Posts: 795
    edited 2013-02-20 - 12:00:40

    The NEW memory idea is faster than SD but slower than existing SRAM. It is much larger *the 64M chips I'm looking at would be 32x larger than SRAM and also Non-volatile. It could significantly speed loading the desktop. It's a bit of stop-gap solution for these LARGE displays *800x480 pixels*

    RE: connecting propeller chips. I'm attaching a schematic that shows the physical channel between the touchburger and expander. This uses 4 pin Asynchronous serial, *TX,RX,CTS,RTS* Not the best solution but seems to work. I had example code started, but broke somewhere along the way.

    RE: Stacking RAM. Using another set of SRAM chips changes the schematic slightly. Need 1 more propeller pin to connect to A18 (Bit4 IN IC14. Now connected to 3v3.) Q4 of IC14 would go to a 1-2 line demux. The 2 outs go to chip enables of BANKS of SRAM. I'll draw schematic soon, although I will probably use a 3-8 line DEMUX *74hc138* since I have quite a few around.

    RE: hc595. It's a nice thought, but won't quite work. We need to read data INTO the propeller, as well as output data from propeller. Dr.A is working on a solution using less propeller pins, may fit your needs better?

    RE: Display. If you order the 4.3" display I linked, it will work perfectly with this system. Just remove 1 resistor from display board *R4* and solder a bridge on J1-CON2. This
    fixes backlight *and I think it gives you PWM control of backlight!

    The schematic is a bit confusing at first, I admit. Here's a quick rundown. P0-P20 are "grouped" pins. These are shared by the 4 groups *groups are active low* driven by 74hc373.
    The 47hc161's are address counters for the SRAM. The idea is to pre-set these to the starting address of the SRAM, then just toggle P20 when in group to get the next word from SRAM. Group 1 is for loading the SRAM address and Group 2 is for transferring data to and from SRAM, as well as data to display. Group 3 is for getting touch data from displays as well as talking to expansion. Perhaps Dr.A can chime in with a better explanation?

    RE: revised touchburger schematic. Looks good!

    RE: Centimanes system. I will need to look over this a bit later..

    RE: Changing pin3 from 5v to 3v3. This is not necessary. The displays all SAY 3v3, but so far all have regulators on board and need 5v for SD. Leave 5v.

    RE: Faster RAM... The concept is this. The desktop is rarely changed. So it seems logical to store in non-volatile FLASH. This saves re-loading on every boot *SD being the weakest link* and should improve desktop boot times. It also frees up SRAM for other stuff. In theory, the FLASH will be slightly slower than SRAM, but still much faster than SD card. It also significantly increases onboard memory. Or at least that's my thought.

    RE: 800*480 displays... The SSD1963 is a bit strange IMO. Register settings are done in 8bit mode, but pixel data is transferred in 16 bit mode. See code below:
    ' register setting, done 8 bit mode
    PUB Draw(x1, y1, x2, y2)                                ' sets the pixel to x1,y1 and then fills the next (x2-x1)*(y2-y1) pixels
       if orientation                                   ' landscape mode so swap x and y
           result :=x1                                       ' swap x1 and y1
           x1 := y1
           y1 := result
           result := x2                                      ' swap x2 and y2
           x2 :=y2
           y2 := result
       DisplayEnable                                    ' enable one or both displays
    'pixel data done in 16 bit mode
    PUB Pixel(pixelcolor)               ' send out a pixel
         '' it is more efficent to send one Draw command then lots of pixels than sending individual pixels
         '' but of course, you can send draw x,y,x,y where x and y are the same and then send one pixel
    Lcd_Write_Fast_Data(pixelcolor)   ' need to set RS high at beginning of this group (ie call Draw first)

    The wiznet is super-cool! The Wiz812MJ fits on the expansion board quite well. I have connected using SPI mode, pins below:
      { Wiznet PIN IO }   
      SPI_MISO          = 10 ' SPI master in serial out from slave 
      SPI_MOSI          = 11 ' SPI master out serial in to slave
      SPI_CS            = 8 ' SPI chip select (active low)
      SPI_SCK           = 9  ' SPI clock from master to all slaves
      WIZ_INT           = -1
      WIZ_RESET         = 12
      WIZ_SPI_MODE      = -1
    BTW, MikeG's wiznet code is awesome! I spent WAY too much time playing around with this!
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-20 - 17:46:10
    4.3 inch TFT 480*272 LCD Display Module 16M colors Touch Panel Screen SSD1963

    I just couldent hold it any more , so i orderd the 4.3 inch lcd . Its up to the mail man now :p

    @ joe . great explination . that deffinitly helps allot to understand whats going on
    read it about 10 times already , but its gonna take more than that. :P so I will be busy for now

    TX,RX,CTS,RTS , at wich pin numbers ?, in your last schematic I see 8 pins from both propellers going back and forth . souldend it be 4. or was it 4 each way ?. kinda confusing stil :blank:

    ill try to finish my schematic tomorrow or the day after and post to get any sugestions
  • average joeaverage joe Posts: 795
    edited 2013-02-20 - 18:23:51
    You are correct about the 8 pins between propeller chips. This allows 2 serial channels. Pins are as follows:
    CON ''Touchburger Two-Way Serial Port 1 - Slave
    '               Port 1
    ' //////////////////////////////////////////////////////////////////////
    ' /                                                                    /
    '               expansion pin config, tested 1 way.
    ' /                                                                    /
    ' //////////////////////////////////////////////////////////////////////
      ExpRX     = 16
      ExpTX     = 17    
      ExpCTS    = 14
      ExpRTS    = 15
      ExpMODE   = exp#OCTX
      EXP_BRATE = 115200
    CON ''Touchburger Two-Way Serial Port 2 - Slave
    '               Port 2
      Exp2RX     = 18     
      Exp2TX     = 19     
      Exp2CTS    = 12     
      Exp2RTS    = 13     
      Exp2MODE   = exp#OCTX
      EXP2_BRATE = 115200
    Note, if you use port 2, must disable displays otherwise draws garbage. (Took me forever to figure this out!)

    Just stacked the chips, wired everything up. Now for code!

    Got the code working. Using SDA.
    set161               mov     latchvalue,#%11111110   ' group 1, displays all off                     1                       1 
                            call    #set373                 ' send out to the latch                        2-1                      2 +7
                            and     outa,maskP0P20low       ' %11111111_11100000_00000000_00000000          2                       10
                            or      dira,maskP0P20P29       ' %00100000_11100000_00000000_00000000          3                       11
                            cmp     ramaddr,maskP19   wc    ' check if we have extended address             4                       12
                            muxnc   outa, maskP29           ' and !mux onto p29                             1                       13
                            andn    ramaddr,maskP0P18low    ' mask off the low 19 bits                      2                       14                         
                            or      outa,ramaddr            ' send out ramaddr                              3                       15
                            or      outa,maskP20            ' P20 clock high                                4                       16
                            or      outa,maskP16P20         ' P16-P20 high                                  1                       17
                            andn    dira,maskP29            ' %1101_1111_1111_1111_1111_1111_1111_1111      2                       18  
    set161_ret              ret 

    I can't believe this worked! 2MByte FastRAM!!!
    1024 x 768 - 100K
    1024 x 768 - 78K
    1024 x 768 - 116K
    1024 x 768 - 97K
    1024 x 768 - 127K
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-21 - 07:24:52
    Ok , trying to understand how the hole thing works . correct me please

    1. Propeller starts up.
    2. Because transfering data from the (sd card--prop--display) is slow , we want to put all data that will be transferd to the display in the SRAM.
    all data meaning ( fonts , settings , color data . etc )
    this way . if we want to display something , we just set the counters to the right adres. and toggle sram/display. wich is faster than getting it from the sd card
    so after power up .

    A- set group 3 active , then get data from sd card to prop , (1 byte at a time )
    B -set counter start adres at (p0-p15 +1 if stacked ram). toggle Group 1 to set adress into counter.
    C - set sd data on p0-p15 (2 x 1byte), then toggle group2. to set data in sram , and counter to next adress.
    after that loop til done.toggleing p20 to clock the counters and to go to next adress

    All data is now in sram. (2x4Mbit) . by stacking the ram it gets to ( 4x 4Mbit = 16 Mbit). wich is better because we now have more ram , so the chance we have to go get data from the sd card , while already running is getting smaller . that way we can display everything directly from sram.

    . to get the display to actualy show somthing ,
    A- we need to set the counters to the according SRAM adres that has the right data .
    B- then with group 2 active ,. enable the display . so its get the dat
    loop til finished

    its a verry rough idear of how i think the display works, please corret me where im wrong.
    those SRAM stack together do look very sexy , :p. let me know when it works how to wire it up , so I can fix the it in my schematic .

    if the display works the way im thinking now , where are those qspi flash gonna help us with. dont realy get that part yet .

    about the hc595.
    to set the counters we use p0-p17 (+1p if staked SRAM)
    to transfer data from prop to ram (or directly to display) we use p0-7 + p8-p15 , (this is where Dr_A is making the improvement ? cutting the pincount in half). But we wil still be needing p0-p17 to set the counters . ( also cutting them in half means we cannot drive the display the direct way anymore , just to get the idea right ? . anyway , where do we use all those pins as input to get data . only thing I can think off is the touch interface , wich i have no idea over yet . soryy for me asking stupid questions mayme , just trying to figure out how whis thing is going to work .

    idd attach my current , not finished schematic . tell me if you see anything wrong
    Dual Prop .pdf
  • average joeaverage joe Posts: 795
    edited 2013-02-21 - 09:34:28
    @ IGOR
    Not much time for comment, getting ready for work..

    A- set group 3 active , then get data from sd card to prop , (1 byte at a time ) - NO.
    SD card to prop can happen in any group. Dedicated pins.

    B -set counter start adres at (p0-p15 +1 if stacked ram). toggle Group 1 to set adress into counter. - CLOSE

    Select group 1, address at P0-P18 (P29 for Add bit 19) SET LOAD LOW (P19 OR Group1) Rising edge of COUNT (P20 OR Group1 (and Group2)) latches address then set LOAD HIGH.

    I think this could be changed by Group1 to LOAD (no OR with P19) Leave Group1 AND with Group2 for OR with P20 for COUNT. Then ADD bit 19 could go to PIN 19. *I THINK*

    B- then with group 2 active ,. enable the display . so its get the dat
    This is only for SRAM to DISPLAY. IF display enabled, P18 AND P19 low will clock data, regardless of group. Group2 Enables SRAM chips.

    Think of the FLASH drive like a Solid State drive in a computer. Then the SD would be a standard hard-disk and SRAM would be like RAM. We have more FLASH than RAM, and FLASH is SLIGHTLY slower than RAM. SD is larger, and slower than RAM or FLASH. Not only do we have more memory, but it's much faster than SD. I'm thinking this could make loading the desktop possible in a second or 2. NOT 10 seconds *currently*

    ALSO: I've been wanting to add 74HC138 for more groups. Group1 from latch goes to A, Group2 to B, Group3 to C. Always enabled. DO NOT USE O7. Out 0 goes to Group1, Out1 goes Group2, Out 2 goes Group3. Now we have 4 extra groups of P0-P20!!!

    You're close, I'd put WIZNET on 2nd prop. Either that or Group3... More later!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-21 - 15:13:10
    @averagejoe, what is the high capacity ram chip you are proposing? Is it possible to toggle out data by toggling one pin?

    I'm taking another look at the serial sram chips since these appear to have a mode where they can transfer 4 bits per clock cycle

    Maybe then you wouldn't need the 161 counters? Ok, the setup for the address takes a little longer but the actual clocking in and out of data would be the same speed. ? 4 chips in so-called SQI mode. Or - 16 chips in SPI mode. Need to decode the /CS which would take some TTL glue.

  • average joeaverage joe Posts: 795
    edited 2013-02-21 - 18:57:36
    These are the chips I have on the way.

    I don't plan on replacing the SRAM with FLASH, just supplementing it.*All though you COULD replace RAM and counters* The address takes more setup time, finite write cycles... Just as a PC has RAM and DISK, I think the Touchburger could use SRAM and FLASH. You could replace the SRAM with flash, 2 chips for 8 bit, 4 for 16 bit. There's PDIP described in the datasheet, but couldn't find online.. Through-hole parts were small, 8 Mbit.

    My plan for wiring is simple. Use P20*CLOCK* then GROUP4 is /CS. If we need to strobe FLASH /CS, just hi-Z latch. Then each chip 4 pins to 4 pins on bus.

    *on a side note, I can't test code due to broken propPlug. Still need to calibrate TOUCH... I have some other ideas but they have to wait for a while...

    Found the wiki section I was looking for on FLASH.

    Block erasure

    One limitation of flash memory is that, although it can be read or programmed a byte or a word at a time in a random access fashion, it can only be erased a "block" at a time. This generally sets all bits in the block to 1. Starting with a freshly erased block, any location within that block can be programmed. However, once a bit has been set to 0, only by erasing the entire block can it be changed back to 1. In other words, flash memory (specifically NOR flash) offers random-access read and programming operations, but does not offer arbitrary random-access rewrite or erase operations.
    Memory wear

    Another limitation is that flash memory has a finite number of program-erase cycles (typically written as P/E cycles).
    Need to study these datasheets. I have an idea this should work quite well for storing desktop background(?s?) and icons. Maybe some config info, stuff that doesn't change too often. I wonder how hard it would be to modify KYE's FATE for this?

    Thinking about it, there are QUAD-SPI SRAM chips out there, maybe these:

    1M (128K x 8), that would make 4MBit, you could use 8 chips in 2 banks, or more on the bus. Still less than we have now.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-22 - 14:59:58
    Yes I was thinking the same thing.

    I've never quite understood where flash ram is useful once you have an SD card. Flash wears out, and at least with an SD card which also wears out, you can replace the SD card.

    SRAM on the other hand...

    Well, say you are happy with 512 kilobytes of ram (half the touchblade value). That is four 8 pin sram chips in quad mode, and I have an idea we can talk to them using 7 propeller pins - 4 for data and three to drive a HC595 which then drives 4 74HC4016 chips. So 4 of the HC595 pins select which one of the ram chips to talk to (and/or you might want to talk to all 4 at once for clocking in address values). Then the other 4 HC595 pins drive the ram /CS lines.

    That gives us half the ram of the touchblade. Probably ok for the 320x240 display and for pacman and for fonts. Variations on the theme can be having 8 chips in 2 bit mode, or 16 chips in 1 bit mode.

    Just an idea. It might be possible to do this with 9 chips.
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-22 - 19:13:03
    I think this could be changed by Group1 to LOAD (no OR with P19) Leave Group1 AND with Group2 for OR with P20 for COUNT. Then ADD bit 19 could go to PIN 19. *I THINK*


    Ok . so i changed it and now it looks something like the foto above. .

    But now im puzzeld . where is the output of Q3 of the last counter connected to ?.

    from your pictures i could see that with stacking the SRAM you solderd all pins together exept for pin . 22 .
    so my gess would be that the Q3 goes to the pin 22 to enable it. (is now labeld Group_3 in schematic stacked SRAM) . . or there is some circuit that i am missing in between to get to these stacked ram . would love to see that circuit


    but if it works like i think now , does it mean adding another counter chip to the already 5 counters , gives us the possibility , to add 4 more pairs of SRAM ??
    but it wil cost 4 additional prop pins to set the adress for the counters . then maybe adding the hc595 like i had in mind is an idea ? or wil this result in an overkill of SRAM for the display

    HC595 idea.jpeg

    You're close, I'd put WIZNET on 2nd prop. Either that or Group3
    HU ? the wiznet is on a separate prop. only connected by the 8 wire interface , ok , maybe i sould a labeld them the other way around , but Prop1 is the one with the wiznet , and prop 2 is the one with the lcd and other stuff, or am I missing something ?

    think ill be having a hard time till the display arrives
    Dual Prop .pdf
    777 x 839 - 84K
    559 x 1020 - 80K
    420 x 769 - 57K
    781 x 840 - 111K
  • average joeaverage joe Posts: 795
    edited 2013-02-23 - 00:23:14
    O. Sorry, I get the wiznet and all is correct ;)

    Here's what I have wired up. Each pair of ram is a bank. You could extend this a few ways, but it's probably overkill. Almost 3 full screen images @800*480px= 384_000words :D
    Smaller screens are less demanding. 480*272px = 130_560 words per full screen. You can get 4 full-screen images on stock ram.

    Stacked ram is 1_048_576 words
    Stock ram is 524_288 words

    Here's a little idea I had that would allow for more groups, and upto 8 sets of ram chips. Or you could use the high order address bits for something else? Many possibilities.
    That many ram chips is total overkill though :D
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-25 - 11:37:42
    @joe . Ok I agree . its probably an overkill with 8 banks of SRAM .
    I think i will stick to 2 banks then , giving me a total of 4 x 4 = 16Mbit . sould be enough i hope , :p
    if i see 480 x 272px = 130_560Words , makes 8 full screen images . that gota be enough to start with

    I also added the 4 SPI_flash chips to the scematic , Sounds like the could work out pretty well ,
    but thats 4 x 1 = 4Mbit right ?? . but works faster ? i see they work at 20 mhz, and the other SRAM works at 18Mhz . or is this not the best conclusion to take .

    One other ting , where are the fonts etc stored . also in the SRAM , or are therse stored in the SPI_flash memory for another reason.?

    so at power up we , get all the data we need from the sd card, and put it on the SRAM( images) + SPI_Flash dives (fonts??).
    when thats done , we go run our aplication

    to display what is needed , the propeller only sets the adress (it knows where it put the data ), and the right hardware active , and toggles away to get the data displayed. Correct ?

    ? My K-30 Co2 sensor that I plan to also connect to this project runs off 6 volts. the suply i used only had 3.3v and 6 volt. worked out fine till now .
    I see all ic on the board use 3.3 volts . exept the LCD . that gets fed 5 volt. 5 volts that is needed for the SD card , after that a onboard regulator on the lcd transforms this 5 volts to a 3.3 volts wich the lcd runs off , so the 5 volts is actualy only for the sd card.
    the question is ,. Can i put 6 volts to this pin ??. or will it damage the SD card. or wil the onboad regulator release some magic smoke.
    this wil save me a voltage regulator and some caps. not allot . Just asking :P

    Mind taking a last look at my scematic, telling me whats missing . Hopefully ill get my display by fryday. or monday after that . but I still need to make my pcb . so I want to trace it to a pcb to try to make that at scool this fryday. Need a working schematic So i can also start with the coding to get stuff working ,

    Dual Prop .pdf

    help greatly appriciated . Thanks
  • average joeaverage joe Posts: 795
    edited 2013-02-25 - 21:41:37
    The FLASH is probably not necessary in your case. It's actually 64 x 4 = 256Mbit FLASH drive. Just finished wiring my prototype. It will be a few days before code is done.
    The FLASH *and SRAM* could be clocked faster than the P1 can accomplish. I'd need to work out the exact numbers, but I believe the FLASH is clocked @104MHZ. I think the fastest section of code *ASM Ram2Display* runs at 5mhz...

    Fonts, BMPs as well as strings and arrays can be stored in SRAM.

    6v to 5v will probably smoke the SD card.:(

    Schematic looks good. Like I said, I don't know if you need the FLASH, I'm just using it for the large display. I'd put headers for ins and out as appropriate.

    During testing, having P0-P20-Group3-Group4 pins was very nice.

    Here's a look at the finished *prototype* FLASH drive

    Just had time to work on touch recalibration. I can't say it's perfect, but at least a start.
    PRI TouchX                                                 '  S A0-A2  mode  S/D   PD1-PD '' should be compatible!!
          SPI.SHIFTOUT(PIN#Touch_DataIn, PIN#Touch_Clock, 5, 8 , %1__101____0_____0____00) ' reads x from 500 to 3700 (off < 500 )
          result := SPI.SHIFTIN(PIN#Touch_DataOut,PIN#Touch_Clock,2, 12)
    PRI TouchY      
          SPI.SHIFTOUT(PIN#Touch_DataIn, PIN#Touch_Clock, 5, 8 , %1001_0000) ' reads y from 400 to 3800 (off > 3800 )
          result := $FFF - SPI.SHIFTIN(PIN#Touch_DataOut,PIN#Touch_Clock,2, 12)
        ''touch x 80 to  $F88     0 is resting 128-3976
       ''touch y 111 to  $EBF    0 is resting  273-3775
    PRI TouchValue | xval,yval,x,y ' returns % values 0-100% (or 255 for no touch)
          xval := TouchX
          yval := TouchY
          if (xval => 128) and (yval =< 3976)                       ' both have to be valid for a touch
            pause1ms(2)                               ' tiny delay then read again as the first reads may not have the correct value
            xval := TouchX
            yval := TouchY
            ' need to change the scaling factors here for SSD1963
            if (xval => 128) and (yval =< 3976)              ' and if valid again, now more likely this value is correct
                x := xval - 28                               ' scale 100-3948
                x /=  38                                     ' scale 2-103
                x -= 3
                x <#= 100                                    ' max 100
                x #>=0                                       ' min 0
    '            x := 100 - x                                 ' so left edge on left
                y := yval -275                               ' scale 0-3482
                y /= 34                                      ' scale 0-100
                y <#= 100                                    ' max 100
                y #>=0                                       ' min 0
    '            y := 100-y                                   ' so 0 is top left     
                result := (y <<8) | x                       ' return 00000000_00000000_YYYYYYYY_XXXXXXXX   
          if (xval < 128) or (xval > 3976)
            result := $0000FFFF                             ' invalid number(s)
    @ Dr.A.
    Now thinking about the desktop... There's room for 8 icons wide by 13 icons high. I think this may be overkill and was planning on setting 8*10. This still uses a ton of RAM on-top of the desktop image. For strings for 80 icon slots, that's 325 strings for the desktop. Total usage 20,800 words for strings. Total usage for a desktop would be about 404,859 words *i think*

    The old displays used 4x5 for 20 icons. 85 strings for 5440 words. Total RAM usage for a desktop 82,299 words *I think*

    Do we want to scale the icon size up, and keep 4x5 icon desktop?
    1024 x 768 - 123K
    1024 x 768 - 122K
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-26 - 08:09:32
    On second though , after seeing you post about the icons ,

    sounds kinda thight, i think I also wil be needing a few pages and icons , soooo
    I think im gonna go with the overkill or the SRAM , wel just 4 banks then ,
    i will etch them to the pcb and populate if needed , starting with 2 banks .

    So i went to change the scematic again , but in your overkill schematic i had a few questions

    Group 1 and group 2 ,. its just a issue with coding it different so the pull ups not beeing there is not that bad ,. i think
    but at the group 3 and 4 , and the Display_Reset line . they were also pulled high before . but not anymore.
    so I think there are a few pull up resistors missing there right ??
    Group 5..7 also could use a pull up I think ?

    about the flash , i think ill add them anyway . some spoofing around cant do any harm :p . or ill just leave them unpoputalted. its gonna be a testing board anyway.

    and for the 5 volts, Ill just add an extra regulator then
  • average joeaverage joe Posts: 795
    edited 2013-02-26 - 13:32:13
    I have a bunch of things I want to implement. The first is "*.ili" file format. It's basically the raw pixel data from RAM after BMP conversion. Header would be 2 words.
        word[@rambuffer] [0] :=  width                      '
        word[@rambuffer] [1] :=  height                     '
        SpinHubToRam(@rambuffer,ramaddress,2)               ' store header to ram              
        ' pixel data starts word[@rambuffer][2] and each word is 1 pixel.
    Each file could live in RAM, SD, or FLASH. I'd like to make a conversion program to convert BMP and PNG to ILI. Maybe more formats later? It adds an extra step, but will be worth it IMO. Then, instead of SDBMPtoRAM, have SDimgToRam... which looks at the extension and runs the proper bit of code. For example, if BMP file, branch to SDBMPtoRAM. If PNG, SDPNGtoRAM *doesn't exist right now?* If ILI file, SDILItoRAM Then, another bit of code could be ILIRAMtoSD, which copies an ILI file in RAM to SD?


    I think what you're missing is the GROUP decoding logic. Using 74hc138 to decode GROUP1..GROUP3 to GROUP1..GROUP7 and DisplayReset. This means Group pins and DisplayReset will always be driven. By connecting the active low enable of `138 to output enable of 74hc373, we now have 7 groups, Display Reset always driven using 3 pins from the latch. This helps free up 2 pins on the latch for BankSelect B,C *giving us all 8 banks*

    Again, the pull-ups have been omitted since these pins are now always driven by 74hc138.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-26 - 14:10:27
    My little project is to be able to display .jpg files. For that, one needs a .jpg decompression routine, and that means C. And for C, one needs external ram that is independent of the touchscreen ram. And that means using less pins to free up at least 4 pins for external serial spi ram, and so that (for me at least) means a redesign of the circuit to use less pins (probably 12) to talk to the external parallel ram. Hopefully it will all work!

    Addit: big display arrived today. This will be fun. Agree we are going to need a lot more ram. Maybe 6 or 8 of the 512k sram chips?. The driver board is going need to be redesigned so all the ram chips and 161 counters run from 3V3 instead of 5V.
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-27 - 04:21:13
    Again, the pull-ups have been omitted since these pins are now always driven by 74hc138.

    Thanks for the extra explination. had a feeling that was the case , now I know for sure .

    @ Dr_A
    those SRAM bank may come in handy indeed, I think ill just etch all the 8 possible banks. and populate when needed

    Mind shining some light on the schematic to connect the ram via 12 pins
    and how the SPI_ Flash wil be connected then .
    the setup like Joe did it , connecting it to group 4 . wouldend it work ?. edit : needs to bee independend , so dedicated pins
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-27 - 04:44:46
    Everything is being redesigned at the moment. I'm going to break it down into pieces because a) it is easier to understand and b) I might change some bits and not others and c) the 10 pin header system allows designs to be rebuilt quickly.

    So - this board has 8x512k ram chips giving 4 megabytes, configured as 2 megawords.

    Now, this is 40 pins so obviously can't be run directly by a single propeller chip.

    So - 16 pins for data. /RD and /WR and /CS = 3 control pins.

    For the address pins I have several ideas:

    i) Latch in 161 chips using a common 4 bit bus (?6-7 pins)
    ii) Latch in 161 chips using a SPI expander chip (4 pins)
    iii) Latch in 161 chips using an I2C expander chip (no pins, uses common I2C bus)
    iv) Latch in 161 chips using a series of 595 chips (3 pins)
    v) Use a second propeller chip and load that chip via this loader
    vi) Use a 12 pin loader system to do data and address (untested - schematic below)

    Some of these might need another cog driver eg I2C. Ideally the driver is simple so it fits in existing cogs. Option iv) is tempting. Option i) is similar to Option vi).

    I'd like to explore option v) a little more. With all the support chips and the PCB real estate needed, another propeller (even if just used as a counter) might work out cheapest. Esp as it doesn't even need an eeprom.
  • average joeaverage joe Posts: 795
    edited 2013-02-27 - 05:11:17
    Just spent a bunch of time coding... Realized using the GROUP4 to directly select chip meant all other SPI engines could send and receive, but not just send. Well it could be done, but would require a bunch of work either way. So I decided to build the specialized Quad bus into the PASM cog driver *why not, there's room and only 1 task of this can run at a time anyway*

    The first problem is knowing what mode the chips are in. SPI *power-on* or QPI *any other time*... Simple as reading Status Register, since pins have pull-ups. High nibble of both status registers will always be 0! Clock in 2 nibbles, switch to input mode. falling clock will make all 4 pins outputs *low* on FLASH. If there's a high-pin, do init in SPI. *WriteEnable, QPIEnable*

    Then the problem of addressing 4 chips with the same commands, but individual data. I think it's close. Still not ready to test on actual hardware. Need to run more sims in GEAR.
    hubtoflash             ' variable length allows stop write and resume mid page *I think*
                            mov     ilihigh, #$02 ' PAGEPROGRAM QPI, 2 dummy clocks
                            shl     ilihigh, #24 ' move command to bits 31-24
                            mov     temp, ramaddr ' copy ramaddr
                            shl     temp, #8      ' offset by page address         bute            {          ram address   - word-                                       }   ' this will be all 0's
                            or      temp, ilihigh ' build PAGEPFROGRAM command, (B31-B24=Command)  (B23-B20= A23-A20) (B19-B16= A19-A16) (B15-B12= A15-A12) (B11-B8= A11-A8) (B7-B4= A7-A4) (B3-B0= A3-A0)
                            mov     pasm_n, #32   ' 32 bits to send command
                            mov     flashcommand, temp  ' copy to command
                            call    #qpicmdout       'send command
                            or      dira, maskP0P15 ' set pins as outputs again
                            rdword  ililow, hubaddr         ' get word from hub     1-2
                            add     hubaddr, #2             ' next word              3
                            andn    outa, maskP0P15         ' clear for output       4
                            rdword  ilihigh, hubaddr        ' get word from hub     1-2
                            andn    outa, maskP16           ' clock low              3
                            or      outa, ilihigh           ' write MSW              4
                            or      outa, maskP16           ' clock high             1 
                            add     hubaddr, #2             ' next word              2
                            andn    outa, maskP16           ' clock low              3
                            andn    outa, maskP0P15         ' clear for output       4
                            or      outa, ililow            ' write LSW              1
                            or      outa, maskP16           ' clock high             2
                            djnz    len, #:loop                                    ' 3
                            jmp     #done                   ' finish up
    flashtohub 'might want to make the length set to page?
                            mov     ilihigh, #$0B ' FASTREAD QPI, 2 dummy clocks
                            shl     ilihigh, #24 ' move  command to bits 31-24
                            mov     temp, ramaddr ' copy ramaddr
                            shl     temp, #8      ' offset by page address     bute            {          ram address   - word-                                       }   ' this will be all 0's
                            or      temp, ilihigh ' build fastRead command, (B31-B24=Command)  (B23-B20= A23-A20) (B19-B16= A19-A16) (B15-B12= A15-A12) (B11-B8= A11-A8) (B7-B4= A7-A4) (B3-B0= A3-A0)
                            mov     pasm_n, #32   ' 32 bits to send command
                            mov     flashcommand, temp  ' copy to command
                            call    #qpicmdout       'send command
                            'now we need 2 dummy clocks
                            andn    outa, maskP16           ' clock low       1                       
                            or      outa, maskP16           ' clock high      2                      
                            andn    outa, maskP16           ' clock low       3                       
                            or      outa, maskP16           ' clock high      4                      
                            ''should do it !
                            andn    outa, maskP16           ' clock low         1                       
                            mov     ina, ilihigh            ' get first word    2
                            and     ilihigh, maskP0P15      ' mask to word      3
                            or      outa, maskP16           ' clock high        4   
                            andn    outa, maskP16           ' clock low         1                       
                            mov     ina, ililow             ' get first word    2
                            and     ililow, maskP0P15       ' mask to word      3
                            or      outa, maskP16           ' clock high        4   
                            wrword  ililow, hubaddr                           '1-2
                            add     hubaddr, #2                               ' 3
                            and     ilihigh, maskP0P15      ' mask to word    ' 4
                            wrword  ilihigh, hubaddr                          '1-2
                            add     hubaddr, #2                               ' 3   
                            djnz    len, #:loop             ' length in longs ' 4
                            jmp     #done                 ' finish up       
    qpicmdout           '' send command in flashcommand,   pasm_n = 8, 16, 24, 32 - number of bits   returns to caller with clock high - pins input
                            andn    outa, maskP16           ' make clock pin low for mode 0                       
                            and     latchvalue, #%1111_0111 ' CS low, enable chip
                            call    #set373                 ' and set latch
                            or      dira,maskP0P15          ' set data pins P0-P15 as outputs                                       
    :nibble                 andn    outa, maskP16           ' clock low                             
                            mov     temp, flashcommand      ' copy flashcommand to temp                        
                            sub     pasm_n, #4              ' subtract 4 from number of bits to get shift factor
                            mov     mask, #$F               ' prepare mask
                            shl     mask, pasm_n            ' shift mask left to first nibble
                            or      temp, mask              ' mask off first nibble
                            shr     temp, pasm_n            ' shift right by shift factor, moves to bits 0-3 for copy
                            mov     data_16, temp           ' first chip                            
                            mov     ilihigh, #3             ' do loop 3 times                       
    :copy                   shl     temp, #4                ' shift to next chip
                            or      data_16, temp           ' or into data
                            djnz    ilihigh, #:copy                                                 
                            andn    outa, maskP0P15         ' prepare bus for transfer
                            or      outa, data_16           ' copy high nibble to outs              
                            or      outa, maskP16           ' clock high                            
                            cmp     zero, pasm_n   wc       ' if pasm is greater than 0
            if_c            jmp     #:nibble                ' do 4 more bits
                            andn    dira, maskP0P15         ' make pins 0-15 input
    qpicmdout_ret         ret
    initflash               mov     flashcommand, #$05      ' read SR1 in QPI $05. First nibble should be low     1
                            mov     pasm_n, #8              ' 8 bits out                                          2
                            call    #qpicmdout              ' send command                                        3
                            andn    outa, maskP16           ' clock low                                           4
                            test    ina,maskP0P15    wz     ' if any pins are high, we're not in QPI mode yet     5
                            or      latchvalue, #%0000_1000 ' CS high                                             6
                            call    #set373                 ' and set latch                                       7
          if_nz             call    #quadenable             ' so start QPI                                        8
    initflash_ret           ret                                                                                  '25
    quadenable              mov     flashcommand, #$06      ' write enable                                        9
                            mov     pasm_n, #8              ' send 8 bits                                         10
                            call    #spiout                 ' send command                                        11
                            or      latchvalue, #%0000_1000 ' CS high                                             12
                            call    #set373                 ' and set latch                                       13
                            mov     flashcommand, qebit     ' SR2 QE bit                                          14
                            mov     pasm_n, #24             ' send 24 bits                                        15
                            call    #spiout                 ' send command                                        16
                            or      latchvalue, #%0000_1000 ' CS high                                             17
                            call    #set373                 ' and set latch                                       18
                            mov     flashcommand, $38       ' Quad Enable                                         19
                            mov     pasm_n, #8              ' send 24 bits                                        20
                            call    #spiout                 ' send command                                        21
                            or      latchvalue, #%0000_1000 ' CS high                                             22
                            call    #set373                 ' and set latch                                       23
    quadenable_ret          ret                                                                                  '24
     '' this is for init, WE, SR-QE, QE, flashcommand, pasm_n is number of bits, 8-24?                      
    spiout                  andn    outa, maskP16           ' make clock pin low for mode 0               '27        
                            and     latchvalue, #%1111_0111 ' CS low, enable chip                          28
                            call    #set373                 ' and set latch                                29
                            or      dira,maskspi            ' P0, P4, P8, P12 outputs                      30
                            mov     mask, #1                ' prep mask                                    31
                            shl     mask, pasm_n            ' move mask bit to MSB, now 1 too far          32
                            shr     mask, #1                ' now mask on right bit                        33
    :loop                   andn    outa, maskP16           ' make clock low                               34
                            test    flashcommand, mask  wz  ' test bit,                                    35
                            muxnz   outa, maskspi           ' move first bit to 4 chip DI                  36
                            andn    flashcommand, mask      ' mask out bit                                 37
                            or      outa, maskP16           ' clock high                                   38
                            shr     mask, #1                ' move mask to next bit                        39
                            djnz    pasm_n, #:loop                                                        '40
                            andn    dira,maskspi            ' P0, P4, P8, P12 inputs                       41
    spiout_ret              ret         '44
    maskspi                 long    %00000000_00000000_00010001_00010001                                    '26
    qebit                   long    $00_01_00_02                                                            '42
    flashcommand            res
    temp                    res
    mask                    res

    I think the 12-pin thing can be done using the 7-group mod and a few OR gates. I you probably need 2x 74hc245..

    I still think C could be run on current hardware. In fact, looking at current code on logic analyzer, compared to old code... WOW, all I can say. Here's the problem as I see it...
    To decode a jpeg... use a chain program... have a set interface... ie ramaddress0 = ptr to source, ramaddress1 = ptr to destination. The C program only needs Ram2hub and HUB2ram..
    Make it so THIS chaining of the program doesn't completely reboot- just start new cog(s) * I was reading this could be done...* When all is done, you have decoded jpeg in RAM!

    Sharing RAM between C and display will work, I'd bet good money on it... I just have no time right now. The key is using locks...
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-27 - 15:19:13
    Sharing RAM between C and display will work, I'd bet good money on it... I just have no time right now. The key is using locks...

    I'm sure it can. But I'm not sure it is the best solution. Consider a game, like Pacman, where lots of sprites are being moved from ram to the screen all the time. Any delays in this due to caching read/writes for the program are going to cause the display to pause.

    I'm thinking of playing to the strengths of the propeller, which is multitasking. Devote cogs to the display, and devote a cog to the C cache, and let them run in parallel. It then becomes a matter of using the pins in the most efficient way. 4 pins for a SPI ram, and possibly 6 if you want to use qaud SPI. That means less pins for the propeller to ram. I guess the 12 pin solution is one of the better ones But I keep thinking there must be a solution where one can have two or three propeller chips running in parallel and do away with all the glue logic chips. Maybe using 4 pins for an SPI master/slave arrangement (there is some code for this in the obex) as this will be faster than RS232/serial.

    I've got some parts of a web browser working in Spin but it is going to run out of code memory, plus the jpeg decoder only exists in C. So a web browser for this display is going to probably have to be done in C. I think it is entirely possible to do and would look good on this big display.
  • Igor_RastIgor_Rast Posts: 357
    edited 2013-02-27 - 15:46:05
    Ok , I give up . Have to ask still


    didnt knew the 10pin header system , and spend quite a wile trying to figure out how everything was actualy wired , But now , I like it :p .
    i think ill also make some lose parts so I can redesign the board if needed , especially because i plan to use smd components , verry hard to desolder. .

    option v
    using a second propeller to do it , im not verry crazy about , If i remember correct the wiznet running the server on a prop , takes about 5 cogs and allot of space , doesnt leave much room for more , hope to keep the second prop as free as possible from lcd chores , only sharing a set a variables that runs the hole show . (gota figure it out still).
    the sharing of the eerprom got me thinking if I cant let my 2 props share a single eerporm , and have them both load a different program , or master slave.

    Think ill be needing my PCB and some parts to start testing ASAP couse this is getting me hungry

    anyway . what has me confused about the 2 last chematics ,
    why is the SRAM bank on the touch, split in 2 (/CS_RAM_LOW + /CS_RAM_HIGH) and thats not with the other 4 on the centimanes, they are held active by the pair (/CS1 ../CS4 ) from the 138.

    A19 , where does it come from , is it from the Q3 pin from the last counter , or is it from P19 from the prop . bit confusing to me

    think I will move the 138 on the centimanes , to the touch board schematic ,
    and make a pcb housing only a the SRAM and a nice header , so I can just stack them on top of each other . but this is where I dont get it :p

    the single bank SRAM gets its data from the 2X 74hc245. ( no prop pin in between )
    the 8 other SRAMs get the data from p0..p15 .. or is this then the same WORD)..Word 15 from the 245

    12 pin system. Love it :p thats the one I wanna try first
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-02-27 - 22:58:53
    Hi Igor,

    Sorry to confuse you. Some of those schematics are not even tested yet. I'm still experimenting. Maybe get a large breadboard and start building things?

    We do have a stable working PCB for the 320x240 display and that is version 3 and works and averagejoe has some boards if you want them.

    But for the larger display, it is back to the drawing board! This display will work better with more external ram.

    The 138 is doing different things on those two schematics. But essentially it decodes 3 binary bits to one of 8 low outputs. If we add more ram chips we need to decode more address lines - eg A0-A18 to the display, A19 and A20 are decoded to one of 4 outputs. Or you could decode A19,A20 and A21 to one of 8 outputs.

    Addit: Crazy idea for a circuit - see attached. Three propeller chips, two ram chips. Simple rule - no glue chips. Prop 2 and 3 are programmed by prop 1 at bootup. Prop 3 is just an address counter which might seem a waste of a propeller, but it does take up less board space than all the 161 chips and glue chips. Each prop has spare pins so can expand the memory and add other peripherals (keyboard, cache serial ram for C, spare SPI bus, mouse, even VGA screen). Would it work?
  • average joeaverage joe Posts: 795
    edited 2013-02-28 - 17:22:37
    You know, that new schematic is pretty cool and I think it could totally work! It doesn't seem that crazy either. :D I love the fact it has the /RD on the display.

    With the big display, I had a bug with hub2display *might have existed on the other display as well* Seems the display was clocking incorrectly. I fixed it by clocking CS and WR together. As a byproduct, I also further optimized ram2display.
                            mov     latchvalue, dirb
                            call    #set373
                            or      dira,maskP0P15          '%00000000_00000000_11111111_11111111
                            andn    outa,maskP0P15          '%11111111_11111111_00000000_00000000       ' clear for output           4
                            rdword  data_16,hubaddr         ' get the word from hub                                                 1-2
                            or      outa,data_16            ' send out the byte to P0-P15                                            3
                            add     hubaddr,#2              ' one word                                                               4
                            andn    outa,maskP18P19         ' ILI write low                                                          1
                            or      outa,maskP18P19         ' ILI write high                                                         2
                            djnz    len,#:loop  ' do this many times                                                                 3
                            jmp     #done                   '      
    pasmramtodisplay        call    #set161
                            mov     latchvalue, dirb
                            call    #set373
                            andn    dira,maskP0P15          ' %11111111_11111111_00000000_00000000 so prop pins 0-15 HiZ
                            andn    outa,maskP19            ' CS low  
                            andn    outa,maskP16            ' ram /rd low
    ramtodisplay_loop       andn    outa,maskP18P20         ' ILI write low, clock 161 low                  1
                            or      outa,maskP18P20         ' ILI write high, clock 161 high                2
                            'andn    outa,maskP20            ' clock 161 low 
                            'or      outa,maskP20            ' clock 161 high                                
                            djnz    len,#ramtodisplay_loop  '                                               3
                            or      outa,maskP16            ' mem /rd high
                            or      outa,maskP19            ' CS high
                            jmp     #done
Sign In or Register to comment.