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.
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.
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
any suggestions ??
so its going to be some time before ill be talking about that , but i realy look forward to it .
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...
@Dr.A.
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.
*edit*
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.
*Aedit*
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*
BeginDesktop(TRUE)
deskf := SDBMPtoRam(String("800.bmp")) '$223c9
text (String("RUNNING")) 'never runs?? but runs LAST LINE of SDBMPtoRam?
clearscreen(0)
DrawBMPRam(1,0,0)
maskF := SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons
MergeBackgroundIconRam(String("prop.bmp"),256,256,deskF,maskF)
DrawBMPRam(deskF,0,0)
@ 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
prop1
eerprom (2p)
propplug interface (2p)
Prop to prop communication ( p??)
LCD (16p)
SD-card1 (4p)
Touchscreen (3p?)
Prop2
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 . . 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 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
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.
@ 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.
*edit*
Here's the current Touch.Spin
BMPtoRAM is broken *if I could get this working, should speed up SDBMPtoRAM significantly.*
DrawFAST is still broken...
*aedit*
I just found these :http://www.digikey.com/product-detail/en/W25Q80BVDAIG/W25Q80BVDAIG-ND/2208452
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...
as i continue to read average joe , jumps in with a new sugestion for a faster SRAM , wich i like , faster always better . 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
question
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 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.
@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
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.
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: 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
Lcd_Write_Com($002A)
Lcd_Write_Data(x1>>8)
Lcd_Write_Data(x1&$ff)
Lcd_Write_Data(x2>>8)
Lcd_Write_Data(x2&$ff)
Lcd_Write_Com($002B)
Lcd_Write_Data(y1>>8)
Lcd_Write_Data(y1&$ff)
Lcd_Write_Data(y2>>8)
Lcd_Write_Data(y2&$ff)
Lcd_Write_Com($002c)
LCD_RS_High
'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!
I just couldent hold it any more , so i orderd the 4.3 inch lcd . Its up to the mail man now
@ 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
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!)
*edit*
Just stacked the chips, wired everything up. Now for code!
*aedit*
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
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.
@joe
those SRAM stack together do look very sexy , . 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
@ IGOR
Not much time for comment, getting ready for work..
RE:
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.
RE:
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*
RE:
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!
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.
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...
*edit*
Found the wiki section I was looking for on FLASH.
Limitations
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?
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.
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
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
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
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
*Edit*
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
@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 ,
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 ,
@IGOR
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
*edit
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?
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 . 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
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?
@Igor,
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.
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.
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
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 http://forums.parallax.com/showthread.php/86311-Propeller-Loader?p=591445&viewfull=1#post591445
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.
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
:loop
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 !
:loop
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
@IGOR
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..
@Dr.A.
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...
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.
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 .
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
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 thats the one I wanna try first
Sorry to confuse you. Some of those schematics are not even tested yet. I'm still experimenting. Maybe get a large breadboard http://www.futurlec.com/Breadboards.shtml 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?
You know, that new schematic is pretty cool and I think it could totally work! It doesn't seem that crazy either. 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.
pasmhubtodisplay
mov latchvalue, dirb
call #set373
or dira,maskP0P15 '%00000000_00000000_11111111_11111111
:loop
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
nop
nop
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
Comments
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.
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.
Here's a 4.3 that appears compatible. http://www.ebay.com/itm/4-3-inch-TFT-480-272-LCD-Display-Module-16M-colors-Touch-Panel-Screen-SSD1963-/181004141897?pt=LH_DefaultDomain_0&hash=item2a24b00549
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...
@Dr.A.
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.
*edit*
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.
*Aedit*
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* BeginDesktop(TRUE) deskf := SDBMPtoRam(String("800.bmp")) '$223c9 text (String("RUNNING")) 'never runs?? but runs LAST LINE of SDBMPtoRam? clearscreen(0) DrawBMPRam(1,0,0) maskF := SDBMPtoRam(string("mask.bmp")) ' file 2, load this here - if load after the strings get a white line on the icons MergeBackgroundIconRam(String("prop.bmp"),256,256,deskF,maskF) DrawBMPRam(deskF,0,0)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
prop1
- eerprom (2p)
- propplug interface (2p)
- Prop to prop communication ( p??)
- LCD (16p)
- SD-card1 (4p)
- Touchscreen (3p?)
Prop2something 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
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
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
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.
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.
*edit*
Here's the current Touch.Spin
BMPtoRAM is broken *if I could get this working, should speed up SDBMPtoRAM significantly.*
DrawFAST is still broken...
*aedit*
I just found these :http://www.digikey.com/product-detail/en/W25Q80BVDAIG/W25Q80BVDAIG-ND/2208452
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...
as i continue to read average joe , jumps in with a new sugestion for a faster SRAM , wich i like , faster always better
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
question
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
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.
@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
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.
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
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?
@Dr.A.
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 Lcd_Write_Com($002A) Lcd_Write_Data(x1>>8) Lcd_Write_Data(x1&$ff) Lcd_Write_Data(x2>>8) Lcd_Write_Data(x2&$ff) Lcd_Write_Com($002B) Lcd_Write_Data(y1>>8) Lcd_Write_Data(y1&$ff) Lcd_Write_Data(y2>>8) Lcd_Write_Data(y2&$ff) Lcd_Write_Com($002c) LCD_RS_High '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 = -1BTW, MikeG's wiznet code is awesome! I spent WAY too much time playing around with this!I just couldent hold it any more , so i orderd the 4.3 inch lcd . Its up to the mail man now
@ 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
*edit*
Just stacked the chips, wired everything up. Now for code!
*aedit*
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 retI can't believe this worked! 2MByte FastRAM!!!
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.
@joe
those SRAM stack together do look very sexy ,
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
Not much time for comment, getting ready for work..
RE:
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.
RE:
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*
RE:
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!
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 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2542¶m=en539030
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.
Thoughts?
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...
*edit*
Found the wiki section I was looking for on FLASH.
Limitations
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:
http://www.digikey.com/product-detail/en/23LC1024-I%2FSN/23LC1024-I%2FSN-ND/3543084
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.
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.
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
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
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
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
*Edit*
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
I think i will stick to 2 banks then , giving me a total of 4 x 4 = 16Mbit . sould be enough i hope ,
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
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
*edit
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?
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
and for the 5 volts, Ill just add an extra regulator then
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?@Igor,
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.
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.
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
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 http://forums.parallax.com/showthread.php/86311-Propeller-Loader?p=591445&viewfull=1#post591445
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.
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 :loop 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 ! :loop 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@IGOR
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..
@Dr.A.
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...
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.
@Dr_A
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
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
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
Sorry to confuse you. Some of those schematics are not even tested yet. I'm still experimenting. Maybe get a large breadboard http://www.futurlec.com/Breadboards.shtml 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?
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.
pasmhubtodisplay mov latchvalue, dirb call #set373 or dira,maskP0P15 '%00000000_00000000_11111111_11111111 :loop 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 nop nop 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