I added the pull ups(10k) to the 8-15 bus , changed enable 3 to enable 1 of the 138. E3-high , E2- Low. E1 - Load . Pulled High by 10k resistor ,
Droped the code as is inside , but its not working yet.
Think it got something to do with the latches , not fully understanding whats happening in the latch code you written , still struggeling with it
a latch wasnt set good before in your code that I got ealier , I changed it back but forgot where it was
latchvalue |= 1011_0000
latchvalue &= 1011_0101
why 8 bits , the latch uses 4 . is it data of botch latches at the same time, Or is it the toggle back data , So low is the first 4 , high is the other 4 . Not realy getting it yet
But the leds of the latch 1 show me that . there is more than 1 of the outputs thats low during the data transfer , But if I remember it should only be the LOW 245 , that should be low , the rest high right ??
at the second latch also , I only see the Display_RS blink low back high ,only once . It should to it more often , or its happening verry quicly that I cant see it , I can see the other leds blinking ( CS. and clock . so
UPDATE:
Testing out , first thing I came along
PUB Main |i
outa[RD_pin]~~
outa[WR_pin]~~
outa[WR_pin]~~
'outa[LOAD_pin]~~ ' connect load to enable 1 or 2, active low!!
dira[11..0]~~
latchALLhigh
waitcnt(clkfreq*5 + cnt)
' Start_SSD1963
repeat
latchALLhigh Doesnt set all output off the 2 latches High, So thats problem number 1
Another question .
PRI Lcd_Write_Com(adresslong)
LCD_RS_Low
LCD_write_bus(adresslong)
LCD_RS_High
PRI Lcd_Write_Data(adresslong)
LCD_CS_Low
LCD_write_bus(adresslong)
the RS and CS are both on the same 74hc75 meaning , they both are set at the same time ,
and assuming that PRI LCD_RS_Low and PRI LCD_CS_Low both toggle just 1 pin at the time respectivly RS(Q0) & CS(Q1), the other 3 are turned the opposite of the toggled pin , . ( CS is or with clock , so, at lcd side the cs wil go low when clock goes low )
they work echother back .
at Lcd_Write_Com LCD_RS_Low will make CS high , thats not what we needed right ??
or does the (latchvalue |= %0001_0000) 2 x 4 bits , take care of not touching the state of the other pins when toggled and leaves them like they were set. Still not understanding that part
I see this is happening at the end of the ini too
LCD_RS_High
LCD_CS_High
maybe the problem ?
maybe we could just use a new pin to toggle one of them , still got p22 up free . plus 12+13.
EDIT . AGAIn
PRI Start_SSD1963
HUB2LCD_ACTIVE
LCD_Reset_High 'RS + CS also on 74hc75 , are the held high ??? all latch outputs High ?
pause1ms(5)
LCD_Reset_Low 'RS + CS also on 74hc75 , are the held high , while only Reset goes LOW ?
pause1ms(5)
LCD_Reset_High
LCD_CS_High 'RS + Reset also on 74hc75 , should we combine the 2 to toggle at the same time ?
LCD_WR_High ' WR is another pin so thats no problem
pause1ms(5)
If the latching thig was working not disturbing the other pins than it would work out fine , but now the simple way I hade the code before I m not sure which state the pins should be , because the changing effecting the others , think ill have to dig in that latching.
There's probably lots of issues with the code I posted. Not much time but..
Latchvalue is both latches, latch 1 is least significant nibble.
the AND / OR of latchvalue is to not disturb other bits. I prefer to keep CS, RS separate. Only enable/disable CS at the beginning and end of transfers. The pin will toggle when D/WR is toggled anyway.
Like I said, I'm sure there's problems. Should be close though...
Ok . Im started thinking all those loose wires runnig around on the breadbord is causing it not to work ,
Ive just use aa new pin for the RS, and LCD reset . ( only cs is stil on the lach , ) count disabled for the momen
changed the bank selecting to the old working one , but still no action on the display .
So im gonna dig in the data sheets to look exactly what the ini data is saying ,
else Im out of clue,s the rest looks to be working fine , but doesnt
:frown:
eventualy I think i will be breaking up this board to connect the lcd to the prop at the simples possible way , without any other circuit , just to get the INI done , and make sure theres nothing wrong with it , cause im seriously doubting that now
bye any chance you already made that code ??
CON
_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000 ' 5Mhz crystal
_1ms = 1_000_000 / 1_000 ' Divisor for 1 ms
CON
load_pin = 8
clock_pin = 9
RD_pin = 10
WR_pin = 11
Display_RS_PIN = 12
Display_Reset_PIN = 13
CS_PIN = 22
' Selector
LATCH1 = 5
LATCH2 = 6
'latch 1
DispRS = 0
DispCS = 1
DispRST = 2
'latch 2
RamCSlow = 0
RamCShigh = 1
Low245 = 2
High245 = 3
VAR byte latchvalue 'latch1 {Count, Display_/Reset, Display_/CS, Display_RS }
'latch2 {/High 245, /Low 245, Ram/CShigh, Ram/CSlow}
PUB Main |i
outa[RD_pin]~~
outa[WR_pin]~~ 'exclusive for SRAM WR Pin .. LCD Shares Clock_pin with Counters
outa[clock_pin]~ ' Clock Counters/LCD CS
outa[Display_RS_PIN]~~
outa[Display_Reset_PIN]~
outa[LOAD_pin]~~ ' connect load to enable 1 or 2, active low!!
outa[CS_PIN]~~
dira[CS_PIN]~~
dira[13..0]~~
LCD_CS_Low
'LCD_CS_High
' latchALLhigh
waitcnt(clkfreq*2 + cnt)
' UpperHUB2RAM_ACTIVE
' LowerHUB2RAM_ACTIVE
' RAM2LCD_ACTIVE
'HUB2LCD_ACTIVE
'LCD_CS_High
' waitcnt(clkfreq*5 + cnt)
Start_SSD1963
repeat
PUB UpperHUB2RAM_ACTIVE {set 245L (D0..D7) LOW } { needs to be fixed }
latchvalue |= 0101_0000
latchvalue &= 0101_1111
SetLatch(2)
'latch1{CLOCK_EN, Display_/Reset, Display_/CS, Display_RS }
'latch2 {High 245, Low 245, RamCShigh, RamCSlow}
PUB LowerHUB2RAM_ACTIVE {set 245H (D08..D15) LOW } { needs to be fixed }
latchvalue |= 1010_0000
latchvalue &= 1010_1111
SetLatch(2)
'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS }
'latch2 {High 245, Low 245, RamCShigh, RamCSlow}
PUB RAM2LCD_ACTIVE {8Bit Mode} 'probably not needed anymore. HUB2LCD_ACtive replacing it
latchvalue |= 1100_0000
latchvalue &= 1100_1101
SetLatch(2)
'RD_LOW
'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS }
'latch2 {High 245, Low 245, RamCShigh, RamCSlow}
PRI SetLatch(n) ' n is latch 1 or 2, value is new nibble to set
if n == 1
SendLatch(latchvalue &$F , Latch1)
elseif n== 2
SendLatch(((latchvalue >> 4) &$F), Latch2)
elseif n==3
SendLatch(latchvalue &$F , Latch1)
SendLatch(((latchvalue >> 4) &$F), Latch2)
PRI SendLatch(d,s)
outa[3..0] := d
outa[6..4] := s
outa[load_pin]~
outa[load_pin]~~
PUB HUB2LCD_ACTIVE {8Bit Mode}
Bus4bit (11)
Selector138 (6)
outa[load_pin]~
outa[load_pin]~~
'latchvalue |= 1011_0000
'latchvalue &= 1011_0101
'RD_HIGH
'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS }
'latch2 {High 245, Low 245, RamCShigh, RamCSlow}
'----------------------------------------TEMP PUB TILL LATCH FIXED ---------------------------------------
PUB Selector138 (load_n)
outa[6..4]:= load_n
PUB Bus4bit(data)
outa[3..0] := data
'----------------------------------------TEMP PUB TILL LATCH FIXED ---------------------------------------
PUB pause1ms(period) | clkcycles
'' Pause execution for period (in units of 1 ms).
clkcycles := ((clkfreq / _1ms * period) - 4296) #> 381 ' Calculate 1 ms time unit
waitcnt(clkcycles + cnt) ' Wait for designated time
PRI SetCounter (address) | i
repeat i from 4 to 0
outa[6..4] := i
outa[load_pin]~
outa[3..0]:= address >> (4 * i)
outa[clock_pin]~
outa[clock_pin]~~
outa[load_pin]~~
PRI LatchAllHigh {Display }
Bus4bit (15) { 1.1.1.1 - High 245, Low 245, RamCShigh, RamCSlow}
Selector138 (5)
outa[load_pin]~
outa[load_pin]~~
Selector138 (6)
outa[load_pin]~
outa[load_pin]~~
'latchvalue := $FF
'SetLatch(3)
PRI LatchAlllow {Display }
Bus4bit (0) { 1.1.1.1 - High 245, Low 245, RamCShigh, RamCSlow}
Selector138 (5)
outa[load_pin]~
outa[load_pin]~~
PRI RD_LOW
outa[RD_pin]~
PRI RD_High
outa[RD_pin]~~
PRI Bus8bit(data)
outa[7..0] := data
PRI LCD_RS_High
' latchvalue |= %0001_0000
outa[Display_RS_PIN]~~
PRI LCD_RS_Low
'latchvalue &= %1110_1111
outa[Display_RS_PIN]~
PRI LCD_CS_High
outa[CS_PIN]~~
' latchvalue |= %0010_0000
' Bus4bit (15) { 1.1.1.1: Notused output, Display_/Reset, Display_/CS, Display_RS }
' Selector138 (5)
' outa[load_pin]~
' outa[load_pin]~~
PRI LCD_CS_Low
outa[CS_PIN]~~
' latchvalue &= %1101_1111
' Bus4bit (13) { 1.1.0.1: Notused output, Display_/Reset, Display_/CS, Display_RS }
' Selector138 (5)
' outa[load_pin]~
' outa[load_pin]~~
PRI LCD_RESET_High
' latchvalue |= %0100_0000
outa[Display_Reset_PIN]~~
PRI LCD_RESET_Low
'latchvalue &= %1011_1111
outa[Display_Reset_PIN]~
PRI LCD_WR_Low
outa[clock_pin]~
PRI LCD_WR_High
outa[clock_pin]~~
PRI Lcd_Write_Com(adresslong)
LCD_RS_Low
LCD_write_bus(adresslong)
PRI Lcd_Write_Data(adresslong)
LCD_RS_High
LCD_write_bus(adresslong) ' send out the data
PRI Displaycmd(c,d) ' instruction in one method
Lcd_Write_Com(c) ' send out a word
Lcd_Write_Data(d)
PRI LCD_write_bus(lcdbyte)
bus8bit(lcdbyte)
LCD_WR_Low
pause1ms(5)
LCD_WR_High
'' DISPLAY SETTINGS
DAT
VDP long 271
HDP long 479
HT long 531
HPS long 43
LPS long 8
VT long 288
VPS long 12
FPS long 4
HPW long 10
VPW long 10
PRI Start_SSD1963
HUB2LCD_ACTIVE
LCD_Reset_High 'RS + CS also on 74hc75 , are the held high ??? all latch outputs High ?
pause1ms(5)
LCD_Reset_Low 'RS + CS also on 74hc75 , are the held high , while only Reset goes LOW ?
pause1ms(5)
LCD_Reset_High
LCD_CS_High ' WR aleady pull it Hi (OR-logic) 'RS + Reset also on 74hc75 , should we combine the 2 to toggle at the same time ?
LCD_WR_High ' WR is another pin so thats no problem
pause1ms(5)
LCD_CS_Low
Lcd_Write_Com ($E2) '($00E2) ' //PLL multiplier, set PLL clock to 120M
Lcd_Write_Data($2d) '($0023) ' //N=0x36 for 6.5M, 0x23 for 10M crystal ' $21??
Lcd_Write_Data($02) '($0002) '
Lcd_Write_Data($04) '($0054) ' dummy byte?
Lcd_Write_Com ($E0) '($00E0) ' // PLL enable
Lcd_Write_Data($01) '($0001) ' set pll '
pause1ms(1) '
Lcd_Write_Com ($E0) '($00E0) ' pll '
Lcd_Write_Data($03) '($0003) ' lock
pause1ms(5)
Lcd_Write_Com ($01) '($0001) ' // software reset
pause1ms(5)
Lcd_Write_Com ($E6) '($00E6) ' //PLL setting for PCLK, depends on resolution
Lcd_Write_Data($00) '($0003) '
Lcd_Write_Data($FF) '($00ff) '
Lcd_Write_Data($BE) '($00ff) '
Lcd_Write_Com ($B0) '($00B0) ' //LCD SPECIFICATION
Lcd_Write_Data($20) '($0000) '
Lcd_Write_Data($00) '($0000) '
Lcd_Write_Data($01) '((HDP>>8)&$00FF) ' //Set HDP 'hps??
Lcd_Write_Data($DF) '(HDP&$00FF)
Lcd_Write_Data($01) '((VDP>>8)&$00FF) ' //Set VDP 'vps??
Lcd_Write_Data($15) '(VDP&$00FF)
Lcd_Write_Data($00) '($0000)
pause1ms(5)
Lcd_Write_Com ($B4) '($00B4) ' //HSYNC
Lcd_Write_Data($02) '((HT>>8)&$00FF) ' //Set HT
Lcd_Write_Data($13) '(HT&$00FF)
Lcd_Write_Data($00) '((HPS>>8)&$00FF) ' //Set HPS
Lcd_Write_Data($2B) '(HPS&$00FF)
Lcd_Write_Data($0A) '(HPW) ' //Set HPW
Lcd_Write_Data($00) '((LPS>>8)&$00FF) ' //Set HPS
Lcd_Write_Data($08) '(LPS&$00FF) '
Lcd_Write_Data($00) '($0000) '
Lcd_Write_Com ($B6) '($00B6) ' //VSYNC
Lcd_Write_Data($01) '((VT>>8)&$00FF) ' //Set VT
Lcd_Write_Data($20) '(VT&$00FF)
Lcd_Write_Data($00) '((VPS>>8)&$00FF) ' //Set VPS
Lcd_Write_Data($0C) '(VPS&$00FF)
Lcd_Write_Data($0A) '(VPW) ' //Set VPW
Lcd_Write_Data($00) '((FPS>>8)&$00FF) ' //Set FPS
Lcd_Write_Data($04) '(FPS&$00FF) '
Lcd_Write_Com ($36) '($0036) ' //rotation
Lcd_Write_Data($00) '($0021) ' 3 is 180
Lcd_Write_Com ($F0) '($00F0) ' //pixel data interface
Lcd_Write_Data($03) '($0003) ' 16 bit / 565
pause1ms(5)
Lcd_Write_Com ($29) '($0029) ' //display on
Lcd_Write_Com ($BE) '($00BE) ' //SET PWM FOR B/L
Lcd_Write_Data($06) '
Lcd_Write_Data($F0) '
Lcd_Write_Data($01) '
Lcd_Write_Data($F0) '
Lcd_Write_Data($00) '
Lcd_Write_Data($00) '
Lcd_Write_Com ($D0) '($00d0) ' //dynamic backlight
Lcd_Write_Data($0D) '($000d)
'''''''''''''''''''''LCD RESET ---- GPIO0-----------------------------------------------------
waitcnt(clkfreq /4 + cnt)' pause1ms(50)
Lcd_Write_Com ($B8) '($00B8) '
Lcd_Write_Data($00) '($0000) ' //GPIO3=input, GPIO[2:0]=output
Lcd_Write_Data($01) '($00B8) '//GPIO0 normal
Lcd_Write_Com ($BA) '($0007) ' //
Lcd_Write_Data(00) '($0001) ' //
waitcnt(clkfreq /4 + cnt)' pause1ms(5)
Lcd_Write_Com ($29)
Lcd_Write_Com ($2C) '($002c) start image transfer
'LCD_RS_High ' LCD_RS_High
'LCD_CS_High
All dedicated pins for control , . the R4 resistor from the lcd , is now grounded . to not have it be sensitive to my touching it , j1 , bridged . what about the PWM line , J2? leave it , or does it have to be bridged too ?
But now I have a completly black screen .And still no Inni
when the lcd is just powerd On , but theres no code send to it yet , and the resistor removed , meaning dynamic backlight . do you get a black screen with power on the lcd . or is it already lid.
Any way to check if the controller is still alive ?
the data in the inni i also figure I better write it in number , because not having a 16bus code ,
so ((HDP>>8)&$00FF) went to be first $01 theb $DF . should fix that
The board can be flipped over and plugged into female DIL headers sockets, so you can treat it as a large socketable chip with 112 pins.
I have schematics working on the screen so you can draw a schematic and turn it into something in the chip within a minute or so. There are two headers on the board for programming - quick volatile programming and slower permanent programming.
Over on Seed studios they keep changing their prices of PCBs, and right now the sweet spot for price per sq cm seems to be 10x10cm. So I have been working on a hybrid board with a propeller, FPGA and some ram suitable for a touchscreen.
Some things are not on the board - the regulators and download circuit, and the touchscreen socket. But this can all be plugged together in various ways to do other things too - eg a propeller with heaps of sram via an 8 bit wide bus.
This is an attempt to use the propeller and fpga to their strengths. The propeller can do SD card access and I2C and SPI, and the fpga can handle the interface to the ram and touchscreen so very few other chips will be needed. Hopefully no other chips!
I've done some work on synthesizing the support chips into a CPLD. I chose Xlinx -XC2C64-7QG100C. These are 1v6 core and 1v6 or 3v3 interface with 64 I/Os. Digikey @3.05. Also using different SRAM. IS62WV51216BLL-55TLI Digikey @$9.06 These are surface mount so adapters were needed (and the expensive part). I have verified they work, although it's only partially tested. Breadboard required dropping the clock frequency significantly... Hopefully I'll be able to print some boards soon! That should allow me to bring the clock frequency back up. I can share source code if anyone is interested. I've been meaning to release this for a while now, just been busy with moving and my new job!
I still have to dig in that hole CPLD programming thing still , but count me in
Wondering if you are willing to sell me one of the boards , not sure if you already made them , or still need to .
maybe populated , or i will order the parts myself no problem there ,
and sure am intrested in the source code , Think now its about the right time for you to start a github , so you can get some nice things going with your work as backbone :P
Looking forward
I was wondering , what happend to the second prop ? wasnt it also part of your design
In my effort to let the hole world run on the propeller over here im running short of everything
an extra prop to take over a few of those tasks would make it a more than fantastic ting
I still have not printed boards for this design. I have some optimizations I plan on making that I have not had time to implement. I'm hoping to have this done by December but everything is taking longer than expected, so we'll see. I plan on making fully populated boards available when finished. As soon as something is ready, I'll be posting here. Just thought I'd give you guys a sneek-peek!
I still have not printed boards for this design. I have some optimizations I plan on making that I have not had time to implement. I'm hoping to have this done by December but everything is taking longer than expected, so we'll see. I plan on making fully populated boards available when finished. As soon as something is ready, I'll be posting here. Just thought I'd give you guys a sneek-peek!
Awch . dec is indeed a long time , espesialy if your super busy
but mind sharing the code you have that works ,
I already orderd the parts , so I think I will be making my own board over here , need that second prop to
nos sure if thats still possible , but still want to try .
Mind giving a hint in the programs used to open these source files
Cant find any spin file in them either , or is that only for the xlin ?
would love to try to get it working some time in the future , I have bought the chips .nou i need to understand it all before I can make the board that works :P
The current design uses two parallel sram chips and five 161 counters to move pixels quickly from ram to the display in order to do things like fast text where fonts are stored as bitmaps.
I wonder if this can be done another way? I've been looking at the 23LC1024 sram chips. These have a burst mode where once it is all set up, just toggling the clock pin on the chip will send out data. That saves on having counters. The chips also have a quad mode, so you can transfer 4 bits at a time. So for dumping out 16 bits at a time (one pixel is 16 bits), that would be four 23LC1024 chips.
Moving the data from the propeller into the ram chips needs some way of multiplexing 4 propeller pins, and isolating those pins when the data is being moved from ram to the display. Two 4052 chips (or 74HC4052) should work. There might be other solutions with other chips too.
Overall, I think this would use a lot less propeller pins, less peripheral chips and a smaller board size.
This could certainly work. It would be very interesting to see how well this could translate to the FLASH chips I was planning on using. Multiplexing the pins could save a lot of pins, although I assume we would need to dump the draw commands to SRAM first?
considerations to the operating frequencies involved? with the buffers/mux's? nice design.
Side query if i may - Can you program the LCD to reverse/flip the displayed data as indicated in the datasheet of the SSD1289? I believe it's the Driver Output Control register 0x01h, bits 9,11,14 depending on mounting method. ie- you could use it as a HUD in your car.
Can you program the LCD to reverse/flip the displayed data as indicated in the datasheet of the SSD1289? I believe it's the Driver Output Control register 0x01h, bits 9,11,14 depending on mounting method. ie- you could use it as a HUD in your car.
I'm pretty sure there is a command for that. But if not, it is pretty easy to feed data through a cog and change a bitmap into anything you want. We have code to take 24 bit RGB bitmap data and turn it into 16 bit data so flipping could be done too.
Actually, if we did build something with 4 bit serial sram chips, some preprocessing of images might be needed anyway. eg - to conserve precious propeller pins, have the concept of 'fast' prop pins which are real pins, and 'slow' pins which are on the I2C bus and a MCP23017 or two. So you would logically use fast pins to do things like clock the ram chip, and to clock the /wr pin on the display. But things like changing ram chips, ie the /cs pins could be slow pins. So for dumping data from a bitmap on an SD card out to the ram chips, it might make more sense to send all the data in blocks, first to one ram chip, then do the next one. So maybe you read a few kilobytes of a bitmap into hub ram off the SD card, then have a little bit of pasm code to mask out each nibble and send it out to the ram chips in the most time efficient way.
The original propeller demo board has 8 pins for VGA, so many of my boards have 8 prop pins devoted to the display, whether it is TV or VGA. So maybe there is a cunning solution that can talk to a touchscreen using just 8 propeller pins (and then some slow I2C pins as needed). Something like 4 pins for data, one for the /wr pin on the touchscreen, one for the sram clock (join all the clocks together), and that is 6 pins so 2 spare for whatever is the most efficient solution. And things like the sram /cs pins, the touchscreen reset pin, the control pins for the 4052 chips and maybe the touchscreen RS pin are all slow pins off the MCP23017. In software, setup is slow, but dumping data is fast, and that is what you want for updating text and for moving sprites around.
Back of an envelope design and count down from prop pin 31 - 2 pins for programming, 2 for I2C, 2 for audio, 2 for keyboard, 8 for display (combo touchscreen, VGA and TV), 4 for SD card, and 4 to run the finger sensor SPI on the display. That leaves 8 propeller pins free and free propeller pins are always a Good Thing
So the chips would be propeller, eeprom, MCP23017 I2C expander, 4 sram chips, two 4052 chips.
Need to read the sram chip data sheet more - can you set up a sram chip ready for burst mode, then deselect it by making its /cs pin high, then talk to other chips on the same 4 pins bus to set them all up for burst mode, then select all /cs pins low and start clocking?
The more I think about this, the more I think we have to give it a try!
Just wired up a prop to the display, after all data pins were connected, i have ONE free prop pin left lol (not touching the SDA/SCL for EEPROM. I think you guys are on the right track with additional interface IC's). -but then I bet you already came to that conclusion. I'm not aiming to have 30+FPS, 2-8FPS would be sufficient for my project, which is why i'm omitting the SRAMs if i can.
BTW - where the heck is Prop2? Or how about just a Prop P8X64A? We could really use more than 32 pins -j/k -not really
I like the idea James. You are on the right path. I wish I had time to work on this!
FYI, just wired up the slave serial port on the expansion and realized the pins are flipped on the DB-9 connection I ordered. Had to install on the underside of board. Might want to check your library?
SD card speed improvement idea - has anyone actually tried 4bit bus mode? Obviously on some older cards this mode would be useless, but on the HC,XC, & Ultra spec cards, 4bit bus mode can transfer up to 100+MB/s. Couldn't the prop do this in a bit banged PASM driver even at like 4MB/s on a multi page read?
I suppose with needing CRC16 the end solution would be something like an FPGA dumping data from an ULTRA I SD card in 4bit mode down a 16bit bus to a bank of SRAMS, then out to the LCD, but I bet the FPS could be significant.
Couldn't the prop do this in a bit banged PASM driver even at like 4MB/s on a multi page read?
Great idea! The reason we haven't looked at this is that the design with parallel sram uses up pretty much all the propeller pins. But with serial sram there are lots of pins free, and faster SD access would be a really cool use for those pins. Hmm - if those ultra spec speeds really are possible, for some applications maybe we don't need the ram chips at all?!
Was doing a bit more reading on SD specs. It seems that with the U1 class its SD ver 3.0 which says that for the ultra speed cards to be put in 1v8 mode and can then be clocked to over 200MHz. Might it be worth it to get a decent USB SD reader and have the prop integrated with it that way or is this just a silly idea due top the prop being only able to use USB @115200 baud? It would free up a few pins I think but then you have to deal with USB stack overhead I suppose.
Please forgive me if it seems as if I'm standing on your feet, I'm more just curious than anything. It does seem like you have covered your bases on this subject.
SD card speed improvement idea - has anyone actually tried 4bit bus mode? Obviously on some older cards this mode would be useless, but on the HC,XC, & Ultra spec cards, 4bit bus mode can transfer up to 100+MB/s. Couldn't the prop do this in a bit banged PASM driver even at like 4MB/s on a multi page read?
I suppose with needing CRC16 the end solution would be something like an FPGA dumping data from an ULTRA I SD card in 4bit mode down a 16bit bus to a bank of SRAMS, then out to the LCD, but I bet the FPS could be significant.
From what I understand, the problem with using 4bit mode is the CRC16. IIRC the computation would actually reduce throughput, or possibly a SLIGHT performance increase. In my mind, the best way to get around this would be to do CRC16 in CPLD/FPGA. It's trivial to implement in hardware, but software is slow. To start, something like this might be helpful? http://www.ebay.com/itm/like/251289219686?lpid=82
This is the chip I'm working with currently.
A side note, I feel bad I have not had time to work on this project lately. I have a schematic and sample layout for my earlier post with the CPLD. Just need to finish routing. Without power supply, the board comes out about the same size as the 3.2" display. It's all surface mount though.
*Edit. Sorry, I'm actually using the 64, not the 256 (although I do have a 256 on adapter board). The 64 is minimum to replace all the Shift-registers. Both chips are VQFP-100 and have 64 i/o.
Attached is a schematic idea using the 23LC1024 serial ram chips in quad mode.
I've designed it using 8 propeller pins as then one can use the same 8 pins to drive a VGA display. P26 and P27 are for a keyboard and for a touchscreen they are not connected but it means one can have a board that could run VGA and Keyboard or you could run a touchscreen, just by installing different components.
P24-P25 are audio. P16-P23 are display. P12-P15 = SD card. P8-P11 are the touchscreen SPI interface to detect the finger position. P0-P7 are free.
In the parallel ram design we were multiplexing the finger position SPI interface in and out very quickly. It seemed to work, but this design has dedicated propeller pins.
Speed - moving bitmaps from SD to Sram is limited by the SD card speed so the sram in serial mode is the same speed (or 4x, given it is a quad interface).
Dumping data out from the sram to the display is as fast as the propeller can go - toggle clock, toggle the touchscreen /wr line, repeat, and do that in pasm.
One slightly complicated bit is setting up the display. Would need to move data into the ram chips, then clock once on the clock to output all 16 bits at the same time, then toggle the /wr line on the display. So the setup would involve lots of writes to address zero, then moving the data out.
I count 8 chips. Four ram chips, two 244 chips and two 374 chips. One could replace the two 374 chips with one 595 chip but the 595 would be slower.
The board layout is ending up a lot smaller than the parallel solution. There are a lot less traces and so chips can end up closer to each other.
There are other solutions, including MCP23017 chips on the I2C bus. Or you could use P0-P7 and save some chips, but I am inclined to leave some propeller pins unused and bring them out to a header for any purpose you want (eg using 4 for another serial sram so you can run big C programs).
One could make a good case for saying that if one is building the touchscreen version, one does not need a real keyboard, so therefore P26 and P27 are not being used, so therefore these two pins are spare too. And thus if there are 10 pins instead of 8 to talk to the touchscreen, that could well save some of the chips. I'll think about that some more.
had a look at this page while waiting for the Mrs after work in the parking lot of Walmart: circuitsathome.com/category/mcu/arduino/usb-shield
Mind you it's written for arduino, but probably not difficult to implement on something much faster like the Prop since simple ide is here amongst other C IDE's for prop. Particularly the ability to interface to USB mass storage like a TB HDD (high res data logging for months?)
Sticking to the SD card, how wild is this? WiFi SD card?!
Id wish the same thing , came to take a peep
@ agerage joe , what happend to the CPLD design , did you find it not working out ? , just curious
I havent had a slightest chance to continue with the touchscreen , i had the lcd it in my hand today when cleaning and thouth let me take a look at the tread ,
and you guys are like up on it again
damm we have to make this work ,
I had to stop with my previous attempts cause i was getting all sorts of noise on my growing beadbord design
and thouth a pcb would be a best thing to go for , but havent had a chance to make one yet ,
Ive been fixing my toolsets and expect to be having a small etching station at home , so i can experiment with different designs easier ,
but the time is just not at my side. i did buy all the parts needed to buld a CPLD design with 2 props , and a wiznet , but nothing of a schematic or pcb yet , to be continued
Guys ???
Cause we all love to do what we are doing here but barly get the time to dive in , shouldednt we kinda setup a design that we all work on
and cut it up in a few sections orso , cause now we all do something different , and still were trying , Lets go for an opensource design that we all work on .
we start with some specs that it need to have ,and go from there till an end design ,
I think kicad to make the schematic / partslist / pcb is the best software, opensource and free for anybody , so we all can open the same/latest files of the project and work from there
we will have to agree with one design , (maybe one with a slight extro orso) to make it work
Should include ( i Think )
* 2 propellers ( or 1 ?)
* full communication between the 2 propellers
* LCD
* Touchscreen
* CPLD design or counters etc. + SRAM
* sd card
* wiznet W5200 ( This is what i want, this thins workings as a server is just awesome)
Github uploads so we can all agree what design changes are made , or make a fork
should work i guess . what you guys think ?
Comments
Droped the code as is inside , but its not working yet.
Think it got something to do with the latches , not fully understanding whats happening in the latch code you written , still struggeling with it
a latch wasnt set good before in your code that I got ealier , I changed it back but forgot where it was
latchvalue |= 1011_0000
latchvalue &= 1011_0101
why 8 bits , the latch uses 4 . is it data of botch latches at the same time, Or is it the toggle back data , So low is the first 4 , high is the other 4 . Not realy getting it yet
But the leds of the latch 1 show me that . there is more than 1 of the outputs thats low during the data transfer , But if I remember it should only be the LOW 245 , that should be low , the rest high right ??
at the second latch also , I only see the Display_RS blink low back high ,only once . It should to it more often , or its happening verry quicly that I cant see it , I can see the other leds blinking ( CS. and clock . so
UPDATE:
Testing out , first thing I came along
PUB Main |i outa[RD_pin]~~ outa[WR_pin]~~ outa[WR_pin]~~ 'outa[LOAD_pin]~~ ' connect load to enable 1 or 2, active low!! dira[11..0]~~ latchALLhigh waitcnt(clkfreq*5 + cnt) ' Start_SSD1963 repeatlatchALLhigh Doesnt set all output off the 2 latches High, So thats problem number 1
Another question .
PRI Lcd_Write_Com(adresslong) LCD_RS_Low LCD_write_bus(adresslong) LCD_RS_High PRI Lcd_Write_Data(adresslong) LCD_CS_Low LCD_write_bus(adresslong)Lcd_Write_Com - RS=LOW . CS=LOW??
Lcd_Write_Data RS = High ?? CS=Low
the RS and CS are both on the same 74hc75 meaning , they both are set at the same time ,
and assuming that PRI LCD_RS_Low and PRI LCD_CS_Low both toggle just 1 pin at the time respectivly RS(Q0) & CS(Q1), the other 3 are turned the opposite of the toggled pin , . ( CS is or with clock , so, at lcd side the cs wil go low when clock goes low )
they work echother back .
at Lcd_Write_Com LCD_RS_Low will make CS high , thats not what we needed right ??
or does the (latchvalue |= %0001_0000) 2 x 4 bits , take care of not touching the state of the other pins when toggled and leaves them like they were set. Still not understanding that part
I see this is happening at the end of the ini too
LCD_RS_High
LCD_CS_High
maybe the problem ?
maybe we could just use a new pin to toggle one of them , still got p22 up free . plus 12+13.
EDIT . AGAIn
PRI Start_SSD1963 HUB2LCD_ACTIVE LCD_Reset_High 'RS + CS also on 74hc75 , are the held high ??? all latch outputs High ? pause1ms(5) LCD_Reset_Low 'RS + CS also on 74hc75 , are the held high , while only Reset goes LOW ? pause1ms(5) LCD_Reset_High LCD_CS_High 'RS + Reset also on 74hc75 , should we combine the 2 to toggle at the same time ? LCD_WR_High ' WR is another pin so thats no problem pause1ms(5)If the latching thig was working not disturbing the other pins than it would work out fine , but now the simple way I hade the code before I m not sure which state the pins should be , because the changing effecting the others , think ill have to dig in that latching.
Latchvalue is both latches, latch 1 is least significant nibble.
the AND / OR of latchvalue is to not disturb other bits. I prefer to keep CS, RS separate. Only enable/disable CS at the beginning and end of transfers. The pin will toggle when D/WR is toggled anyway.
Like I said, I'm sure there's problems. Should be close though...
Ive just use aa new pin for the RS, and LCD reset . ( only cs is stil on the lach , ) count disabled for the momen
changed the bank selecting to the old working one , but still no action on the display .
So im gonna dig in the data sheets to look exactly what the ini data is saying ,
else Im out of clue,s the rest looks to be working fine , but doesnt
:frown:
eventualy I think i will be breaking up this board to connect the lcd to the prop at the simples possible way , without any other circuit , just to get the INI done , and make sure theres nothing wrong with it , cause im seriously doubting that now
bye any chance you already made that code ??
CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 ' 5Mhz crystal _1ms = 1_000_000 / 1_000 ' Divisor for 1 ms CON load_pin = 8 clock_pin = 9 RD_pin = 10 WR_pin = 11 Display_RS_PIN = 12 Display_Reset_PIN = 13 CS_PIN = 22 ' Selector LATCH1 = 5 LATCH2 = 6 'latch 1 DispRS = 0 DispCS = 1 DispRST = 2 'latch 2 RamCSlow = 0 RamCShigh = 1 Low245 = 2 High245 = 3 VAR byte latchvalue 'latch1 {Count, Display_/Reset, Display_/CS, Display_RS } 'latch2 {/High 245, /Low 245, Ram/CShigh, Ram/CSlow} PUB Main |i outa[RD_pin]~~ outa[WR_pin]~~ 'exclusive for SRAM WR Pin .. LCD Shares Clock_pin with Counters outa[clock_pin]~ ' Clock Counters/LCD CS outa[Display_RS_PIN]~~ outa[Display_Reset_PIN]~ outa[LOAD_pin]~~ ' connect load to enable 1 or 2, active low!! outa[CS_PIN]~~ dira[CS_PIN]~~ dira[13..0]~~ LCD_CS_Low 'LCD_CS_High ' latchALLhigh waitcnt(clkfreq*2 + cnt) ' UpperHUB2RAM_ACTIVE ' LowerHUB2RAM_ACTIVE ' RAM2LCD_ACTIVE 'HUB2LCD_ACTIVE 'LCD_CS_High ' waitcnt(clkfreq*5 + cnt) Start_SSD1963 repeat PUB UpperHUB2RAM_ACTIVE {set 245L (D0..D7) LOW } { needs to be fixed } latchvalue |= 0101_0000 latchvalue &= 0101_1111 SetLatch(2) 'latch1{CLOCK_EN, Display_/Reset, Display_/CS, Display_RS } 'latch2 {High 245, Low 245, RamCShigh, RamCSlow} PUB LowerHUB2RAM_ACTIVE {set 245H (D08..D15) LOW } { needs to be fixed } latchvalue |= 1010_0000 latchvalue &= 1010_1111 SetLatch(2) 'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS } 'latch2 {High 245, Low 245, RamCShigh, RamCSlow} PUB RAM2LCD_ACTIVE {8Bit Mode} 'probably not needed anymore. HUB2LCD_ACtive replacing it latchvalue |= 1100_0000 latchvalue &= 1100_1101 SetLatch(2) 'RD_LOW 'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS } 'latch2 {High 245, Low 245, RamCShigh, RamCSlow} PRI SetLatch(n) ' n is latch 1 or 2, value is new nibble to set if n == 1 SendLatch(latchvalue &$F , Latch1) elseif n== 2 SendLatch(((latchvalue >> 4) &$F), Latch2) elseif n==3 SendLatch(latchvalue &$F , Latch1) SendLatch(((latchvalue >> 4) &$F), Latch2) PRI SendLatch(d,s) outa[3..0] := d outa[6..4] := s outa[load_pin]~ outa[load_pin]~~ PUB HUB2LCD_ACTIVE {8Bit Mode} Bus4bit (11) Selector138 (6) outa[load_pin]~ outa[load_pin]~~ 'latchvalue |= 1011_0000 'latchvalue &= 1011_0101 'RD_HIGH 'latch1 {CLOCK_EN, Display_/Reset, Display_/CS, Display_RS } 'latch2 {High 245, Low 245, RamCShigh, RamCSlow} '----------------------------------------TEMP PUB TILL LATCH FIXED --------------------------------------- PUB Selector138 (load_n) outa[6..4]:= load_n PUB Bus4bit(data) outa[3..0] := data '----------------------------------------TEMP PUB TILL LATCH FIXED --------------------------------------- PUB pause1ms(period) | clkcycles '' Pause execution for period (in units of 1 ms). clkcycles := ((clkfreq / _1ms * period) - 4296) #> 381 ' Calculate 1 ms time unit waitcnt(clkcycles + cnt) ' Wait for designated time PRI SetCounter (address) | i repeat i from 4 to 0 outa[6..4] := i outa[load_pin]~ outa[3..0]:= address >> (4 * i) outa[clock_pin]~ outa[clock_pin]~~ outa[load_pin]~~ PRI LatchAllHigh {Display } Bus4bit (15) { 1.1.1.1 - High 245, Low 245, RamCShigh, RamCSlow} Selector138 (5) outa[load_pin]~ outa[load_pin]~~ Selector138 (6) outa[load_pin]~ outa[load_pin]~~ 'latchvalue := $FF 'SetLatch(3) PRI LatchAlllow {Display } Bus4bit (0) { 1.1.1.1 - High 245, Low 245, RamCShigh, RamCSlow} Selector138 (5) outa[load_pin]~ outa[load_pin]~~ PRI RD_LOW outa[RD_pin]~ PRI RD_High outa[RD_pin]~~ PRI Bus8bit(data) outa[7..0] := data PRI LCD_RS_High ' latchvalue |= %0001_0000 outa[Display_RS_PIN]~~ PRI LCD_RS_Low 'latchvalue &= %1110_1111 outa[Display_RS_PIN]~ PRI LCD_CS_High outa[CS_PIN]~~ ' latchvalue |= %0010_0000 ' Bus4bit (15) { 1.1.1.1: Notused output, Display_/Reset, Display_/CS, Display_RS } ' Selector138 (5) ' outa[load_pin]~ ' outa[load_pin]~~ PRI LCD_CS_Low outa[CS_PIN]~~ ' latchvalue &= %1101_1111 ' Bus4bit (13) { 1.1.0.1: Notused output, Display_/Reset, Display_/CS, Display_RS } ' Selector138 (5) ' outa[load_pin]~ ' outa[load_pin]~~ PRI LCD_RESET_High ' latchvalue |= %0100_0000 outa[Display_Reset_PIN]~~ PRI LCD_RESET_Low 'latchvalue &= %1011_1111 outa[Display_Reset_PIN]~ PRI LCD_WR_Low outa[clock_pin]~ PRI LCD_WR_High outa[clock_pin]~~ PRI Lcd_Write_Com(adresslong) LCD_RS_Low LCD_write_bus(adresslong) PRI Lcd_Write_Data(adresslong) LCD_RS_High LCD_write_bus(adresslong) ' send out the data PRI Displaycmd(c,d) ' instruction in one method Lcd_Write_Com(c) ' send out a word Lcd_Write_Data(d) PRI LCD_write_bus(lcdbyte) bus8bit(lcdbyte) LCD_WR_Low pause1ms(5) LCD_WR_High '' DISPLAY SETTINGS DAT VDP long 271 HDP long 479 HT long 531 HPS long 43 LPS long 8 VT long 288 VPS long 12 FPS long 4 HPW long 10 VPW long 10 PRI Start_SSD1963 HUB2LCD_ACTIVE LCD_Reset_High 'RS + CS also on 74hc75 , are the held high ??? all latch outputs High ? pause1ms(5) LCD_Reset_Low 'RS + CS also on 74hc75 , are the held high , while only Reset goes LOW ? pause1ms(5) LCD_Reset_High LCD_CS_High ' WR aleady pull it Hi (OR-logic) 'RS + Reset also on 74hc75 , should we combine the 2 to toggle at the same time ? LCD_WR_High ' WR is another pin so thats no problem pause1ms(5) LCD_CS_Low Lcd_Write_Com ($E2) '($00E2) ' //PLL multiplier, set PLL clock to 120M Lcd_Write_Data($2d) '($0023) ' //N=0x36 for 6.5M, 0x23 for 10M crystal ' $21?? Lcd_Write_Data($02) '($0002) ' Lcd_Write_Data($04) '($0054) ' dummy byte? Lcd_Write_Com ($E0) '($00E0) ' // PLL enable Lcd_Write_Data($01) '($0001) ' set pll ' pause1ms(1) ' Lcd_Write_Com ($E0) '($00E0) ' pll ' Lcd_Write_Data($03) '($0003) ' lock pause1ms(5) Lcd_Write_Com ($01) '($0001) ' // software reset pause1ms(5) Lcd_Write_Com ($E6) '($00E6) ' //PLL setting for PCLK, depends on resolution Lcd_Write_Data($00) '($0003) ' Lcd_Write_Data($FF) '($00ff) ' Lcd_Write_Data($BE) '($00ff) ' Lcd_Write_Com ($B0) '($00B0) ' //LCD SPECIFICATION Lcd_Write_Data($20) '($0000) ' Lcd_Write_Data($00) '($0000) ' Lcd_Write_Data($01) '((HDP>>8)&$00FF) ' //Set HDP 'hps?? Lcd_Write_Data($DF) '(HDP&$00FF) Lcd_Write_Data($01) '((VDP>>8)&$00FF) ' //Set VDP 'vps?? Lcd_Write_Data($15) '(VDP&$00FF) Lcd_Write_Data($00) '($0000) pause1ms(5) Lcd_Write_Com ($B4) '($00B4) ' //HSYNC Lcd_Write_Data($02) '((HT>>8)&$00FF) ' //Set HT Lcd_Write_Data($13) '(HT&$00FF) Lcd_Write_Data($00) '((HPS>>8)&$00FF) ' //Set HPS Lcd_Write_Data($2B) '(HPS&$00FF) Lcd_Write_Data($0A) '(HPW) ' //Set HPW Lcd_Write_Data($00) '((LPS>>8)&$00FF) ' //Set HPS Lcd_Write_Data($08) '(LPS&$00FF) ' Lcd_Write_Data($00) '($0000) ' Lcd_Write_Com ($B6) '($00B6) ' //VSYNC Lcd_Write_Data($01) '((VT>>8)&$00FF) ' //Set VT Lcd_Write_Data($20) '(VT&$00FF) Lcd_Write_Data($00) '((VPS>>8)&$00FF) ' //Set VPS Lcd_Write_Data($0C) '(VPS&$00FF) Lcd_Write_Data($0A) '(VPW) ' //Set VPW Lcd_Write_Data($00) '((FPS>>8)&$00FF) ' //Set FPS Lcd_Write_Data($04) '(FPS&$00FF) ' Lcd_Write_Com ($36) '($0036) ' //rotation Lcd_Write_Data($00) '($0021) ' 3 is 180 Lcd_Write_Com ($F0) '($00F0) ' //pixel data interface Lcd_Write_Data($03) '($0003) ' 16 bit / 565 pause1ms(5) Lcd_Write_Com ($29) '($0029) ' //display on Lcd_Write_Com ($BE) '($00BE) ' //SET PWM FOR B/L Lcd_Write_Data($06) ' Lcd_Write_Data($F0) ' Lcd_Write_Data($01) ' Lcd_Write_Data($F0) ' Lcd_Write_Data($00) ' Lcd_Write_Data($00) ' Lcd_Write_Com ($D0) '($00d0) ' //dynamic backlight Lcd_Write_Data($0D) '($000d) '''''''''''''''''''''LCD RESET ---- GPIO0----------------------------------------------------- waitcnt(clkfreq /4 + cnt)' pause1ms(50) Lcd_Write_Com ($B8) '($00B8) ' Lcd_Write_Data($00) '($0000) ' //GPIO3=input, GPIO[2:0]=output Lcd_Write_Data($01) '($00B8) '//GPIO0 normal Lcd_Write_Com ($BA) '($0007) ' // Lcd_Write_Data(00) '($0001) ' // waitcnt(clkfreq /4 + cnt)' pause1ms(5) Lcd_Write_Com ($29) Lcd_Write_Com ($2C) '($002c) start image transfer 'LCD_RS_High ' LCD_RS_High 'LCD_CS_HighAll dedicated pins for control , . the R4 resistor from the lcd , is now grounded . to not have it be sensitive to my touching it , j1 , bridged . what about the PWM line , J2? leave it , or does it have to be bridged too ?
But now I have a completly black screen .And still no Inni
when the lcd is just powerd On , but theres no code send to it yet , and the resistor removed , meaning dynamic backlight . do you get a black screen with power on the lcd . or is it already lid.
Any way to check if the controller is still alive ?
the data in the inni i also figure I better write it in number , because not having a 16bus code ,
so ((HDP>>8)&$00FF) went to be first $01 theb $DF . should fix that
So im assuming the LCD got to be broken orso ??
contacting the suplier to see what he got to say
Seeing anything wrong in de code, ive copied all the settings from the LCD.c to it correctly I think .
Running out of options to test . any idea ???
CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 ' 5Mhz crystal _1ms = 1_000_000 / 1_000 ' Divisor for 1 ms CON CS_PIN = 10 WR_pin = 11 RS_PIN = 12 REST_PIN = 13 PUB Main |i outa[CS_PIN]~~ outa[WR_pin]~~ 'exclusive for SRAM WR Pin .. LCD Shares Clock_pin with Counters outa[RS_PIN]~~ outa[REST_PIN]~ outa[7..0]~~ dira[CS_PIN]~~ dira[7..0]~~ LCD_CS_Low waitcnt(clkfreq*2 + cnt) Start_SSD1963 repeat PRI Bus8bit(data) outa[7..0] := data PRI LCD_RS_High outa[RS_PIN]~~ PRI LCD_CS_High outa[CS_PIN]~~ PRI LCD_RESET_High outa[REST_PIN]~~ PRI LCD_WR_High outa[WR_PIN]~~ PRI LCD_RS_Low outa[RS_PIN]~ PRI LCD_CS_Low outa[CS_PIN]~ PRI LCD_RESET_Low outa[REST_PIN]~ PRI LCD_WR_Low outa[WR_PIN]~ PRI Lcd_Write_Com(adresslong) LCD_RS_Low LCD_write_bus(adresslong) PRI Lcd_Write_Data(adresslong) LCD_RS_High LCD_write_bus(adresslong) ' send out the data PRI Displaycmd(c,d) ' instruction in one method Lcd_Write_Com(c) ' send out a word Lcd_Write_Data(d) PRI LCD_write_bus(lcdbyte) bus8bit(lcdbyte) LCD_WR_Low pause1ms(1) LCD_WR_High PUB pause1ms(period) | clkcycles '' Pause execution for period (in units of 1 ms). clkcycles := ((clkfreq / _1ms * period) - 4296) #> 381 ' Calculate 1 ms time unit waitcnt(clkcycles + cnt) ' Wait for designated time '' DISPLAY SETTINGS DAT VDP long 271 HDP long 479 HT long 531 HPS long 43 LPS long 8 VT long 288 VPS long 12 FPS long 4 HPW long 10 VPW long 10 PRI Start_SSD1963 LCD_Reset_High 'RS + CS also on 74hc75 , are the held high ??? all latch outputs High ? pause1ms(10) LCD_Reset_Low 'RS + CS also on 74hc75 , are the held high , while only Reset goes LOW ? pause1ms(10) LCD_Reset_High LCD_CS_High ' WR aleady pull it Hi (OR-logic) 'RS + Reset also on 74hc75 , should we combine the 2 to toggle at the same time ? LCD_WR_High ' WR is another pin so thats no problem pause1ms(10) Lcd_Write_Com ($E2) '($00E2) ' //PLL multiplier, set PLL clock to 120M Lcd_Write_Data($2D) '($0023) ' //N=0x36 for 6.5M, 0x23 for 10M crystal ' $21?? Lcd_Write_Data($02) '($0002) ' Lcd_Write_Data($04) '($0054) ' dummy byte? Lcd_Write_Com ($E0) '($00E0) ' // PLL enable Lcd_Write_Data($01) '($0001) ' set pll pause1ms(1) Lcd_Write_Com ($E0) '($00E0) ' pll ' Lcd_Write_Data($03) '($0003) pause1ms(5) Lcd_Write_Com ($01) '($0001) ' // software reset pause1ms(5) Lcd_Write_Com ($E6) '($00E6) ' //PLL setting for PCLK, depends on resolution Lcd_Write_Data($00) '($0003) ' Lcd_Write_Data($FF) '($00ff) ' Lcd_Write_Data($BE) '($00ff) ' Lcd_Write_Com ($B0) '($00B0) ' //LCD SPECIFICATION Lcd_Write_Data($20) '($0000) ' Lcd_Write_Data($00) '($0000) ' Lcd_Write_Data($01) '((HDP>>8)&$00FF) ' //Set HDP 'hps?? Lcd_Write_Data($DF) '(HDP&$00FF) Lcd_Write_Data($01) '((VDP>>8)&$00FF) ' //Set VDP 'vps?? Lcd_Write_Data($15) '(VDP&$00FF) Lcd_Write_Data($00) '($0000) pause1ms(5) Lcd_Write_Com ($B4) '($00B4) ' //HSYNC Lcd_Write_Data($02) '((HT>>8)&$00FF) ' //Set HT Lcd_Write_Data($13) '(HT&$00FF) Lcd_Write_Data($00) '((HPS>>8)&$00FF) ' //Set HPS Lcd_Write_Data($2B) '(HPS&$00FF) Lcd_Write_Data($0A) '(HPW) ' //Set HPW Lcd_Write_Data($00) '((LPS>>8)&$00FF) ' //Set HPS Lcd_Write_Data($08) '(LPS&$00FF) ' Lcd_Write_Data($00) '($0000) ' Lcd_Write_Com ($B6) '($00B6) ' //VSYNC Lcd_Write_Data($01) '((VT>>8)&$00FF) ' //Set VT Lcd_Write_Data($20) '(VT&$00FF) Lcd_Write_Data($00) '((VPS>>8)&$00FF) ' //Set VPS Lcd_Write_Data($0C) '(VPS&$00FF) Lcd_Write_Data($0A) '(VPW) ' //Set VPW Lcd_Write_Data($00) '((FPS>>8)&$00FF) ' //Set FPS Lcd_Write_Data($04) '(FPS&$00FF) ' Lcd_Write_Com ($36) '($0036) ' //rotation Lcd_Write_Data($00) '($0021) ' 3 is 180 Lcd_Write_Com ($F0) '($00F0) ' //pixel data interface Lcd_Write_Data($03) '($0003) ' 16 bit / 565 pause1ms(5) Lcd_Write_Com ($BE) '($00BE) ' //SET PWM FOR B/L Lcd_Write_Data($06) ' Lcd_Write_Data($F0) ' Lcd_Write_Data($01) ' Lcd_Write_Data($F0) ' Lcd_Write_Data($00) ' Lcd_Write_Data($00) ' Lcd_Write_Com ($D0) '($00d0) ' //dynamic backlight Lcd_Write_Data($0D) '($000d) '''''''''''''''''''''LCD RESET ---- GPIO0----------------------------------------------------- pause1ms(5) Lcd_Write_Com ($B8) '($00B8) ' Lcd_Write_Data($00) '($0000) ' //GPIO3=input, GPIO[2:0]=output Lcd_Write_Data($01) '($00B8) '//GPIO0 normal Lcd_Write_Com ($BA) '($0007) ' // Lcd_Write_Data($00) '($0001) ' // pause1ms(5) Lcd_Write_Com ($29) '($0029) ' //display on Lcd_Write_Com ($D0) '($00d0) ' //dynamic backlight Lcd_Write_Data($0D) '($000d) Lcd_Write_Com ($2C) LCD_CS_HighUPDATE :
Assuming the SSD1963 is dead. I contacted the supplier . and im getting a new one shiped
So there will be another 2 weeks of doing nothing with it
The board can be flipped over and plugged into female DIL headers sockets, so you can treat it as a large socketable chip with 112 pins.
I have schematics working on the screen so you can draw a schematic and turn it into something in the chip within a minute or so. There are two headers on the board for programming - quick volatile programming and slower permanent programming.
Over on Seed studios they keep changing their prices of PCBs, and right now the sweet spot for price per sq cm seems to be 10x10cm. So I have been working on a hybrid board with a propeller, FPGA and some ram suitable for a touchscreen.
Some things are not on the board - the regulators and download circuit, and the touchscreen socket. But this can all be plugged together in various ways to do other things too - eg a propeller with heaps of sram via an 8 bit wide bus.
This is an attempt to use the propeller and fpga to their strengths. The propeller can do SD card access and I2C and SPI, and the fpga can handle the interface to the ram and touchscreen so very few other chips will be needed. Hopefully no other chips!
Had not done anything with it in a wile , was a bit too busy , but still wanted to get things working :P
I still have to dig in that hole CPLD programming thing still , but count me in
Wondering if you are willing to sell me one of the boards , not sure if you already made them , or still need to .
maybe populated , or i will order the parts myself no problem there ,
and sure am intrested in the source code , Think now its about the right time for you to start a github , so you can get some nice things going with your work as backbone :P
Looking forward
I was wondering , what happend to the second prop ? wasnt it also part of your design
In my effort to let the hole world run on the propeller over here
an extra prop to take over a few of those tasks would make it a more than fantastic ting
Awch . dec is indeed a long time , espesialy if your super busy
but mind sharing the code you have that works ,
I already orderd the parts , so I think I will be making my own board over here , need that second prop to
nos sure if thats still possible , but still want to try .
any help would be greatly apriciated
Cant find any spin file in them either , or is that only for the xlin ?
would love to try to get it working some time in the future , I have bought the chips .nou i need to understand it all before I can make the board that works :P
Found here:
http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html
You will need to register to gain access but it's free.
I wonder if this can be done another way? I've been looking at the 23LC1024 sram chips. These have a burst mode where once it is all set up, just toggling the clock pin on the chip will send out data. That saves on having counters. The chips also have a quad mode, so you can transfer 4 bits at a time. So for dumping out 16 bits at a time (one pixel is 16 bits), that would be four 23LC1024 chips.
Moving the data from the propeller into the ram chips needs some way of multiplexing 4 propeller pins, and isolating those pins when the data is being moved from ram to the display. Two 4052 chips (or 74HC4052) should work. There might be other solutions with other chips too.
Overall, I think this would use a lot less propeller pins, less peripheral chips and a smaller board size.
Thoughts would be most appreciated!
Side query if i may - Can you program the LCD to reverse/flip the displayed data as indicated in the datasheet of the SSD1289? I believe it's the Driver Output Control register 0x01h, bits 9,11,14 depending on mounting method. ie- you could use it as a HUD in your car.
I'm pretty sure there is a command for that. But if not, it is pretty easy to feed data through a cog and change a bitmap into anything you want. We have code to take 24 bit RGB bitmap data and turn it into 16 bit data so flipping could be done too.
Actually, if we did build something with 4 bit serial sram chips, some preprocessing of images might be needed anyway. eg - to conserve precious propeller pins, have the concept of 'fast' prop pins which are real pins, and 'slow' pins which are on the I2C bus and a MCP23017 or two. So you would logically use fast pins to do things like clock the ram chip, and to clock the /wr pin on the display. But things like changing ram chips, ie the /cs pins could be slow pins. So for dumping data from a bitmap on an SD card out to the ram chips, it might make more sense to send all the data in blocks, first to one ram chip, then do the next one. So maybe you read a few kilobytes of a bitmap into hub ram off the SD card, then have a little bit of pasm code to mask out each nibble and send it out to the ram chips in the most time efficient way.
The original propeller demo board has 8 pins for VGA, so many of my boards have 8 prop pins devoted to the display, whether it is TV or VGA. So maybe there is a cunning solution that can talk to a touchscreen using just 8 propeller pins (and then some slow I2C pins as needed). Something like 4 pins for data, one for the /wr pin on the touchscreen, one for the sram clock (join all the clocks together), and that is 6 pins so 2 spare for whatever is the most efficient solution. And things like the sram /cs pins, the touchscreen reset pin, the control pins for the 4052 chips and maybe the touchscreen RS pin are all slow pins off the MCP23017. In software, setup is slow, but dumping data is fast, and that is what you want for updating text and for moving sprites around.
Back of an envelope design and count down from prop pin 31 - 2 pins for programming, 2 for I2C, 2 for audio, 2 for keyboard, 8 for display (combo touchscreen, VGA and TV), 4 for SD card, and 4 to run the finger sensor SPI on the display. That leaves 8 propeller pins free and free propeller pins are always a Good Thing
So the chips would be propeller, eeprom, MCP23017 I2C expander, 4 sram chips, two 4052 chips.
Need to read the sram chip data sheet more - can you set up a sram chip ready for burst mode, then deselect it by making its /cs pin high, then talk to other chips on the same 4 pins bus to set them all up for burst mode, then select all /cs pins low and start clocking?
The more I think about this, the more I think we have to give it a try!
BTW - where the heck is Prop2? Or how about just a Prop P8X64A? We could really use more than 32 pins -j/k -not really
FYI, just wired up the slave serial port on the expansion and realized the pins are flipped on the DB-9 connection I ordered. Had to install on the underside of board. Might want to check your library?
Oops. My bad. Sorry.
Agree. Conceptually, I like to think of a Prop plus two MCP23017 chips as a P8X64A.
No worries! I just thought I'd let you know to check the library.
I've seen this thread http://forums.parallax.com/showthread.php/129698-SDCARD-in-4-bit-mode
this one is a good read with coffee http://electronics.stackexchange.com/questions/10675/is-it-possible-to-use-4-pin-mode-for-an-sd-card-with-a-microcontroller-instead-o
I suppose with needing CRC16 the end solution would be something like an FPGA dumping data from an ULTRA I SD card in 4bit mode down a 16bit bus to a bank of SRAMS, then out to the LCD, but I bet the FPS could be significant.
EDIT: "Belay that Belay!" -Johnny Dep (I just came across this - http://forums.parallax.com/showthread.php/143639-RAID-of-SD-cards)
Great idea! The reason we haven't looked at this is that the design with parallel sram uses up pretty much all the propeller pins. But with serial sram there are lots of pins free, and faster SD access would be a really cool use for those pins. Hmm - if those ultra spec speeds really are possible, for some applications maybe we don't need the ram chips at all?!
Please forgive me if it seems as if I'm standing on your feet, I'm more just curious than anything. It does seem like you have covered your bases on this subject.
From what I understand, the problem with using 4bit mode is the CRC16. IIRC the computation would actually reduce throughput, or possibly a SLIGHT performance increase. In my mind, the best way to get around this would be to do CRC16 in CPLD/FPGA. It's trivial to implement in hardware, but software is slow. To start, something like this might be helpful? http://www.ebay.com/itm/like/251289219686?lpid=82
This is the chip I'm working with currently.
A side note, I feel bad I have not had time to work on this project lately. I have a schematic and sample layout for my earlier post with the CPLD. Just need to finish routing. Without power supply, the board comes out about the same size as the 3.2" display. It's all surface mount though.
*Edit. Sorry, I'm actually using the 64, not the 256 (although I do have a 256 on adapter board). The 64 is minimum to replace all the Shift-registers. Both chips are VQFP-100 and have 64 i/o.
I've designed it using 8 propeller pins as then one can use the same 8 pins to drive a VGA display. P26 and P27 are for a keyboard and for a touchscreen they are not connected but it means one can have a board that could run VGA and Keyboard or you could run a touchscreen, just by installing different components.
P24-P25 are audio. P16-P23 are display. P12-P15 = SD card. P8-P11 are the touchscreen SPI interface to detect the finger position. P0-P7 are free.
In the parallel ram design we were multiplexing the finger position SPI interface in and out very quickly. It seemed to work, but this design has dedicated propeller pins.
Speed - moving bitmaps from SD to Sram is limited by the SD card speed so the sram in serial mode is the same speed (or 4x, given it is a quad interface).
Dumping data out from the sram to the display is as fast as the propeller can go - toggle clock, toggle the touchscreen /wr line, repeat, and do that in pasm.
One slightly complicated bit is setting up the display. Would need to move data into the ram chips, then clock once on the clock to output all 16 bits at the same time, then toggle the /wr line on the display. So the setup would involve lots of writes to address zero, then moving the data out.
I count 8 chips. Four ram chips, two 244 chips and two 374 chips. One could replace the two 374 chips with one 595 chip but the 595 would be slower.
The board layout is ending up a lot smaller than the parallel solution. There are a lot less traces and so chips can end up closer to each other.
There are other solutions, including MCP23017 chips on the I2C bus. Or you could use P0-P7 and save some chips, but I am inclined to leave some propeller pins unused and bring them out to a header for any purpose you want (eg using 4 for another serial sram so you can run big C programs).
One could make a good case for saying that if one is building the touchscreen version, one does not need a real keyboard, so therefore P26 and P27 are not being used, so therefore these two pins are spare too. And thus if there are 10 pins instead of 8 to talk to the touchscreen, that could well save some of the chips. I'll think about that some more.
I like the separate latch chips. You could breakout the remaining 4 pins on each for GPIO use. That gives you 8 propeller pins and 8 GPIO's!!!
I bet the 4 chip SRAM design routes much better than 2 chip
circuitsathome.com/category/mcu/arduino/usb-shield
Mind you it's written for arduino, but probably not difficult to implement on something much faster like the Prop since simple ide is here amongst other C IDE's for prop. Particularly the ability to interface to USB mass storage like a TB HDD (high res data logging for months?)
Sticking to the SD card, how wild is this?
WiFi SD card?!
Id wish the same thing
@ agerage joe , what happend to the CPLD design , did you find it not working out ? , just curious
I havent had a slightest chance to continue with the touchscreen , i had the lcd it in my hand today when cleaning and thouth let me take a look at the tread ,
and you guys are like up on it again
damm we have to make this work ,
I had to stop with my previous attempts cause i was getting all sorts of noise on my growing beadbord design
and thouth a pcb would be a best thing to go for , but havent had a chance to make one yet ,
Ive been fixing my toolsets and expect to be having a small etching station at home , so i can experiment with different designs easier ,
but the time is just not at my side. i did buy all the parts needed to buld a CPLD design with 2 props , and a wiznet , but nothing of a schematic or pcb yet , to be continued
Guys ???
Cause we all love to do what we are doing here but barly get the time to dive in , shouldednt we kinda setup a design that we all work on
and cut it up in a few sections orso , cause now we all do something different , and still were trying , Lets go for an opensource design that we all work on .
we start with some specs that it need to have ,and go from there till an end design ,
I think kicad to make the schematic / partslist / pcb is the best software, opensource and free for anybody , so we all can open the same/latest files of the project and work from there
we will have to agree with one design , (maybe one with a slight extro orso) to make it work
Should include ( i Think )
* 2 propellers ( or 1 ?)
* full communication between the 2 propellers
* LCD
* Touchscreen
* CPLD design or counters etc. + SRAM
* sd card
* wiznet W5200 ( This is what i want, this thins workings as a server is just awesome)
Github uploads so we can all agree what design changes are made , or make a fork
should work i guess . what you guys think ?