From my understanding, it's best to keep the RC filter as close to the prop as possible.
FYI, I have seen an additional cap for ac-coupling on some schematics. This is not a big deal b.c. most line-ins have ac-coupling on the input. If using headphones this will place quite a bit of dc-bias on their coils. I have also experienced pops and clicks when turning audio signals on and off. Still have tests to do on this.
re. resistor divider for spidif,. not sure about that. Read http://forums.parallax.com/showthread.php?133075-Polyphonic-SIDcog-synth-WIP&p=1090085&viewfull=1#post1090085
A couple jumpers would be handy to bypass cap, but I'm not sure that they are necessary. IF you REALLY wanted to, a 4066 could switch the cap out of circuit. Latch that in from a few of the extra group pins, just a thought
So I spent a couple hours today putting things together, and I believe all I'm short of is the LCD cable and a few resistors. I will try using a `138 and a `174 for now. When I'm in Reno tomorrow, I will check Sandy's for a `237, anything else I should grab if they have it?
The other thing I'm thinking about... @ the expo, I grabbed a few 8583 RTC's, and I thought one might come in handy. I also like the second 3232, although I won't be using that or the keyboard right now. I have a feeling the I2C breakout will be coming in VERY handy. Gotta run, just wanted to give an update.
This version sent off tonight (see below). There are three previous versions I have being made and on the way from China but they are all paths towards this board so may not end up being used. It probably is still not quite there but I think it is close enough. Same schematic as a few posts ago.
Re putting the RC filter near the prop or near the socket, that is an interesting question. I'd be inclined to think that the digital part is both discrete in terms of high and low, and also a lower impedance (whatever the prop pin impedance is ? a few hundred ohms) cf what comes out of the RC filter which is at least 1k impedance because that is the value of the resistor, and also more prone to interference from nearby pins as it is now analog vs digital so more prone to minor disturbances from nearby pins. So maybe I'm wrong but I put the RC components near the socket rather than near the propeller. I guess the proof will be in the audio testing.
Real time clock? Almost every board I build, I run out of room for a RTC. I've got to try harder!
My "out" is to stick it on the I2C bus that we now have formalised. Use a premade board from futurlec http://www.futurlec.com/Mini_DS1307.shtml or something we design ourselves.
AC coupling - hmm, probably on the amp board? Or at least I hope so. In software you should be able to program it to do a 1V Peak to Peak so it should work with most audio amps.
237's are hard to come by. I got mine from Farnell/Element14 but they are more UK/Australia. We might end up doubling the world market for these chips or something
I have some RS232 to wireless modules (multiple brands) and hope to use that port for interfacing wirelessly to other boards, albeit it at slower baud rates like 2400 or 9600.
LCD cable? Good point. I was thinking about that this morning too. So you have a board in a box but the display is on the front of the box. Use a couple of 40 pin headers and some cable. A standard IDE cable from a PC will do - $1 on ebay or probably free from your local computer store.
Re 4066s vs latches on the cap, well if I get a few extra boards made you can customise them as you want. I'll send you some free ones. I can afford a few extra boards. Today I just moved $20 billion dollars around in the Australian healthcare system, and just ensured that 4 million people will not lose access to their local family doctor. I'm on a high! None of the money comes to me but I don't care right now, this is about improving health and saving lives. It is a big picture thing about helping humanity. So the cost of a few boards here does not matter
I'm not sure about the SPDIF format and specifically, whether it is tolerant of voltages over about 0.7V. I've got to confess, it is a strange world what is easy to achieve (150 letters to local politicians = $20 billion) and what is uncertain (SPDIF voltage specifications). I'm sure those SPDIF specs are there for a reason, so at the worst, it can be done with a couple of resistors, or a LED. In general terms, SPDIF is a very "clean" digital format vs lossy analog. This is where talking to people who actually use synthesizers is really useful! So thanks++
If there are any mistakes on that board, hopefully they are fixable with a few wirelinks. I'll send you some freebies when they come through (? a couple of weeks).
Good question re pins. I think it is 62 propeller pins. Ah you say - there are not that many pins on a prop chip!
Common to all groups are:
P30-31 is serial download
P28-29 is I2C bus
P24-P27 is the SD card
P21 and 23 are audio
P22 selects which group
and P0-P20 are selected in groups.
Group 0 does the 161 latching
Group 1 does memory I/O eg hub to ram, ram to hub, ram to display, hub to display
Group 2 does keyboard, touch input to the touchscreen, second serial port (with handshaking so it can handle being disabled some of the time)
and the other groups are free for whatever you want.
Added checkboxes, radio buttons and standard buttons. (text input can be linked with the keyboard as shown earlier, and pictures have also been demonstrated, so these are the common objects used in a GUI)
spin code:
PUB Buttons | ck1x,ck1y,ck1s,ck2x,ck2y,ck2s,rd1x,rd1y,rd1s,rd2x, rd2y,rd2s,rd3x,rd3y,rd3s,bu1x,bu1y,xval,yval,redra w ' test out buttons, radio buttons, checkboxes
SetOrientation(true) ' portrait view
clearscreen(RGBtoWord(212,208,200)) ' background color determined from paintshop
ILIloadfont(string("MSans14.ifn")) ' 14 point seems to be the same as 8.25 in vb.net ? why
LoadSmallPicture(string("butn8430.raw"),84,30,Pic1) ' a button 84x30 in size
LoadSmallPicture(string("Check13A.raw"),13,13,Pic3) ' unchecked checkbox pic3
LoadSmallPicture(string("Check13B.raw"),13,13,Pic4) ' checked checkbox pic4
LoadSmallPicture(string("Radio12A.raw"),12,12,Pic5) ' unchecked radiobox pic 5
LoadSmallPicture(string("Radio12B.raw"),12,12,Pic6) ' checked radiobox pic 6
redraw := true
' set all the locations of the objects on the screen
ck1x := ck2x := rd1x := rd2x := rd3x := 20 ' x all the same
ck1y := 10
ck2y := ck1y + 40 ' y coordinates
rd1y := ck2y + 40
rd2y := rd1y + 40
rd3y := rd2y + 40
bu1x := 80 ' button position
bu1y := 280
ck1s := true ' startup status
ck2s := false
rd1s := true
rd2s := false
rd3s := false
' now wait for touch
SelectSPIGroup ' talk to the spi touchscreen
repeat
if redraw ' if redraw true then redraw all the objects
SelectMemGroup ' display mode
DrawCheckbox(ck1x,ck1y,ck1s,string("Checkbox1")) ' checkbox
DrawCheckbox(ck2x,ck2y,ck2s,string("Checkbox2")) ' checkbox
DrawRadiobox(rd1x,rd1y,rd1s,string("Radiobox1")) ' radiobox
DrawRadiobox(rd2x,rd2y,rd2s,string("Radiobox1")) ' radiobox
DrawRadiobox(rd3x,rd3y,rd3s,string("Radiobox2")) ' radiobox
DrawButton(bu1x,bu1y,pic1,string("Ok")) ' button (fixed size at the moment)
redraw := false
SelectSPIGroup ' talk to the spi touchscreen
yval := TouchYPercent ' decode yval 0-100%
xval := TouchXPercent ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
xval := (xval * 24) / 10 ' scale to pixels as can measure from the picture in paintshop
yval := (yval * 32) / 10 ' scale to pixels
' cheat a bit here, no need to look for x value as only one column of objects. See calculator for x and y buttons
case yval
(ck1y-10)..(ck1y+25): !ck1s ' checkbox is small so active area bigger than the checkbox
redraw := true ' redraw the screen
(ck2y-10)..(ck2y+25): !ck2s ' checkbox is small so active area bigger than the checkbox
redraw := true
(rd1y-10)..(rd1y+25): rd1s := true ' there probably is a smarter way to make one value true and all the rest false
rd2s := false
rd3s := false
redraw := true
(rd2y-10)..(rd2y+25): rd1s := false
rd2s := true
rd3s := false
redraw := true
(rd3y-10)..(rd3y+25): rd1s := false
rd2s := false
rd3s := true
redraw := true
bu1y..(bu1y + 30): return ' button so exit this screen
pause1ms(250) ' debounce
repeat
PUB DrawCheckbox(x,y,Checked,Stringptr) | i ' draw a checkbox
if checked
i := pic4
else
i := pic3
DrawSmallPicture(x,y,13,13,i) ' size determined from original picture
curx := x+20 ' add 20 width
cury := y
ILIPrintString(stringptr)
PUB DrawRadioBox(x,y,Checked,Stringptr)| i ' draw a radio box
if checked
i := pic6
else
i := pic5
DrawSmallPicture(x,y,12,12,i) ' size determined from original picture
curx := x+20 ' add 20 width
cury := y
ILIPrintString(stringptr)
PUB DrawButton(x,y,Ramaddress,Stringptr) ' draw a radio box
DrawSmallPicture(x,y,84,30,Ramaddress) ' size determined from original picture (later build variable sized buttons, or load them from the sd card)
curx := x + (84/2)-(str.len(stringptr)*4 / 2) ' centre, avg width 4 per char 84 could be a variable width passed to this routine
cury := y + 8
ILIPrintString(stringptr)
Sweet! I can't wait to give this a try! I'm bogged down on homework and other stuff right now. I should have time next week to finish up the wiring and start testing!
I see on Facebook you have a breadboard made up - looking very good. And probably quicker to test things than the way I have been with getting PCBs made.
I have been getting bogged down in the complexity of .raw files. Specifically, each picture has a size, and the size has to be stored somewhere, and if you forget what the size of a picture was, you can't restore it except by trial and error.
So I figured that the .bmp format might be better than the .raw format. And then I figured that keeping track of all these pictures was getting too complex and was wasting a lot of memory allocating larger than the required amount. So I figured we needed a simple disk file system. The nice thing about bitmaps is they contain the file size and width and height. So I preserved that, and added in the filename so you can search for it later.
This code reads in some bitmap files from the sd card into the sram, and then displays them in a different order. Just pass the filename and the x and y location and the routine finds where the file is on the sram and then displays it. Super fast display (max 30 milliseconds for a full screen) that is much faster than reading off the sd card:
LoadBMPtoRamdisk(string("hotair.bmp")) ' load a bitmap and increments ramdisk pointer
LoadBMPtoRamdisk(string("cat2.bmp")) ' because we now have 4 Burmese cats!
LoadBMPtoRamdisk(string("cat3.bmp"))
LoadBMPtoRamdisk(string("nt.bmp")) ' nice picture of the Northern Territory of Australia.
setorientation(false)
result := DrawBMP(string("nt.bmp"),0,0)
result := DrawBMP(string("hotair.bmp"),180,90)
result := DrawBMP(string("cat2.bmp"),10,10)
result := DrawBMP(string("cat3.bmp"),80,60)
The image is flipped upside down. And if the width happens to end up an odd number, it needs to be padded to a multiple of 4 (eg 109 width is 327 bytes which needs one extra byte to pad to 328). And just to really keep you on your toes, the pixels are BGR instead of RGB.
Bitmaps are a very standard file format. Now I need to recode all the stuff up to now from .raw to .bmp. It should end up a lot easier.
Code for the above routines. I probably could have made better use of Kye's string library for matching filenames. Maybe I'll do that later, eg change the case so it matches even if the case does not match.:
PUB LoadBMPtoRamdisk(stringptr) | width,height,w,i ' load and display a bitmap file
' http://en.wikipedia.org/wiki/BMP_file_format scroll down about 1/3 of the way for the header formats
' get the width, height
' store these as 2 longs at the beginning of the ram file
' the bitmap format starts at the last row and works up so need to reverse the order
' on the ram store a 0x36 byte header - the bitmap header but put in the filename at location 0
' this becomes a rudimentary file system that can be searched to find pictures
propfont_out(".") ' for debugging display something while load in pictures
fat.openfile(stringptr,"R")
fat.readdata(@sdbuffer,$36) ' get the header 0x36 hex bytes
width := sdbuffer[$12] + sdbuffer[$13] << 8 ' only read in two bytes as never will be >64k wide or high
height := sdbuffer[$16] + sdbuffer[$17] << 8
w := width * 3 ' this number of bytes per row, and round up to nearest 4 bytes et 327 goes to 328 The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.
w +=3 ' add 3 and
w &= %11111111_11111111_11111111_11111100 ' round down
repeat i from 0 to 11 ' add the file name at the beginning of the header
sdbuffer[i] := byte[stringptr][i]
docmd("S",@sdbuffer,RamDiskPointer,$36) ' store header to ram
i := $36 + RamDiskPointer + ((height - 1) * width) ' start + header and on the last row and work back
repeat height
fat.readdata(@sdbuffer,w) ' read in the first row
docmd("F",@sdbuffer,@rambuffer,width)
HubToRam(i,width) ' send to ram
i -= width ' subtract the width, move up the picture
fat.closefile
RamDiskPointer += $36 + (width * height) ' increment the ramdiskpointer for next picture
RamDiskFiles += 1 ' increment number of entries in the ram disk
PUB DrawBMP(stringptr,x,y) | i,rampointer,ramcounter,match,searchlen,width,height ' pass the name and the x and y location, searches for this file and if found, displays it
rampointer := RamStart
searchlen := str.instr(stringptr,".") - 1 ' ignore the .bmp extension
repeat ramcounter from 1 to ramdiskfiles
docmd("T",@sdbuffer,rampointer,$36) ' get hex $36 bytes from the ramdisk = filenames
width := sdbuffer[$12] + sdbuffer[$13] << 8 ' only read in two bytes as never will be >64k wide or high
height := sdbuffer[$16] + sdbuffer[$17] << 8
match := true
repeat i from 0 to searchlen - 1
if sdbuffer[i] <> byte[stringptr][i]
match := false ' any characters not matching, try next one. (case must match too)
if match == true
quit ' found a match so quit looking for any more files
' get the next rampointer = $36 + width * height
rampointer += $36 + (width * height)
if match == true ' if found a match display the picture
Draw(x,y,x+width-1,y+height-1) ' set up the area to draw
RamToDisplay(RamPointer + $36,width*height) ' skip the header and display
result := (width <<16) | (height & $0000FFFF) ' return the width and height combined into a long
I am really hoping that after 4 lots of PCBs we have a design that is good enough to give away some boards and get some others involved.
I think we're very close to a "reference" design. I've been way busy trying to get homework done, as well as working on the other project. I'm getting very close with the other project but having some issues due to coms protocol. I should be done next week, at least with the preliminary object. Then I get to catch up with you. As you said, I have the breadboard made up for the most part. I'm missing some resistors, and a few connections. Should go quick. I'm still wondering if I can get kye's sd object going. I was unable to in the past and was forced to use fsrw. Not a bad thing, just an inconvenience. I think it's the sd-cards I'm using but I'm not 100% on that.
Nice to see bitmaps working. I do believe this to be a better route than .raw. What happens if the bmp resolution > display resolution? *just wondering*
I'm also wondering the best way to interface the display with another controller... Wireless. I'm thinking xbee's would work but I don't have any laying around. *My wife made the suggestion of using the display to control her Bri-Bot. Sounds like a fun challenge! *
Back to homework. Keep kickin butt and takin names Doc!
What happens if the bmp resolution > display resolution? *just wondering*
Nothing terrible - it just overlaps at the top of the screen again. However, everything that gets displayed is run through paintshop pro first, to resize and resample the file.
Re interfacing with other controllers, I like RS232. 3 wires, ground, data out and data in. I've got a pile of nifty RS232 to wireless modules, cost around $20 on ebay and they are truly a replacement for a wire link (albeit with no handshaking and slower baud rates, so you can't use them for wirelessly programming propeller chips). I'm hoping with a couple of boards I can replicate what the CP/M wireless network using these modules (CP/M is great but it is a bit impractical lugging around a VGA monitor out in the field). I'd like an icon on the touchscreen that 'discovers' nearby nodes and then automatically sets up links with them.
That's a lot of TTL glue...pushing 100 pins worth - (These days, boards & assembly cost more than MSI parts )
I guess someone has already suggested using a second Prop, as the Scan counter ?
What clock speeds do you target ?
Good point. Yes it could be done with a second prop. Or a FPGA. The initial aim is to get a design working and prove it all works. I'm sure it can then be shrunk down with less chips, less pins, surface mount. My daughter says it needs to be the size of the display which is about 1/3 of the size of the current board. The clock is fast enough now - 5 pasm instructions to move two bytes from ram to the display which equates to 30ms for a screen refresh. Next limiting problem might be code space - currently using about half the hub ram when writing in Spin but sooner or later will probably need to port this over to C.
I agree that this design could be, and needs to be, shrunk. I agree with your daughter on scale, maybe stacking boards? I've been thinking surface mount myself, wondering how much space this would save. FPGA might be the way to go, but that's beyond my realm. I have a few thoughts on the memory issue, but C will solve this problem, as well as some others. Quite a bit of work ahead. If only there were 8 more hours in a day...
Good point. Yes it could be done with a second prop. Or a FPGA. The initial aim is to get a design working and prove it all works. I'm sure it can then be shrunk down with less chips, less pins, surface mount. My daughter says it needs to be the size of the display which is about 1/3 of the size of the current board.
The clock is fast enough now - 5 pasm instructions to move two bytes from ram to the display which equates to 30ms for a screen refresh. Next limiting problem might be code space - currently using about half the hub ram when writing in Spin but sooner or later will probably need to port this over to C.
If that speed is ok, then a FPGA/CPLD is not needed.
A small CPLD could do a 20 bit clone of HC161 address counter easily, but if you want to buffer the preload value, and support address Swap for example, you start to nudge up the size.
Adding any sort of write cache pops you to the size of a MachXO2 - essentially the same price as a Prop, and yet another thing to learn.
Just use the second prop as a scan counter, and it can easily manage a little access buffering, Address swap, and some features like fast clear.
If you used a QuadSPI DDR interface, the nibble-wise handling would be similar to the HC161 loading.
Pin count will limit what that 2nd prop can do data-wise, but the between prop link should allow some co-processing off load, into all those spare cogs.. plus 32K of SPI RAM has to be useful ?
Such peripheral focused code will likely be very small, and (in the long term) stable.
@ jmg, that is a very interesting idea. I'm not too sold on the whole quad-spi idea yet though. The max frequency of the screen is 10Mhz. 5mhz is quite acceptable. I was thinking fgpa /cpld would be better but sounds like the prop may be the way to go. So, maybe...
Prop1 p0-19 = a0 - a19, RamAddress lines
Prop2 p0-16 = d0-d16 Ram Data, LCD data?
?p26 & p27? interprop comms?
@ jmg, that is a very interesting idea. I'm not too sold on the whole quad-spi idea yet though. The max frequency of the screen is 10Mhz. 5mhz is quite acceptable. I was thinking fgpa /cpld would be better but sounds like the prop may be the way to go. So, maybe...
Prop1 p0-19 = a0 - a19, RamAddress lines
Prop2 p0-16 = d0-d16 Ram Data, LCD data?
?p26 & p27? interprop comms?
Quad SPI is done all in Sw, so you can all it anything you like.
DDR is a natural to couple with for the WAIT opcode, so why slow things down more ?
Tightly linked COGS may not need a WAIT, but adding it makes the link Auto-baud, so any SW can drive it.
The pin budget would likely limit the 'Logic-prop' to Address-Bus only, but it could add address swap(s), which would be faster SW than HC161,
and I'm sure 32K of SPI memory will find some use.
My daughter says it needs to be the size of the display which is about 1/3 of the size of the current board.
This doesn't have to be as much of a constraint as many people seem to think... You can actually go quite a bit longer and wider than the screen while still maintaining an acceptable touch screen "slate" form factor. The I-Phone and I-Pad are excellent examples of using this added space as a sort of border.
So I've been thinking a bit more, and I would have to agree with the-new-guy. *Great name btw!* I would LIKE it to be about the size of the display, but slightly larger wouldn't be horrible. I am also using the 3.2" screen, not the ?2.4"? not sure of the difference in size of the carrier board. Probably not much. The one issue I see with using these displays in a handheld is... the sd-card slot. Having a card slot so close to the top *or side if in landscape* causes some aesthetic issues IMO. I've been thinking about it for a while, and I'm not jumping to any conclusions yet.
I keep thinking about the possibilities of using another prop, and it leaves some interesting ideas. I'm starting to think of it as P1-"Main prop", P2-"logic prop" the 7 pins left on the logic prop could do the RS232, keyboard, and other stuff I'm sure. Might want to think about the comms protocol between props. Full-duplex-Serial was my main thought, but that was mainly to save pins. Maybe some sort of ADDRESSABLE? AsyncSerial. With hardware handshaking like your previous board suggested. *Just spitballing again* Now that things have calmed back down and I've caught up, I will have time to do some more tests...
TBC
The size of this can be slashed by moving to even partial SMD.
I see one can fit a 512kx16 SRAM under a DIP40 socket...;)
Thinking about the 'Logic Prop' it needs to couple to the Address lines as the highest priority, as they are what needs to toggle and swap fastest..
Add a couple of LVC1G99's for Edge to Pulse Strobe operation, and you have a HW system that will give a write Pulse, just on an Increment, and a peak possible Ram-LCD rate of 20MHz. I think it needs a XNOR Pulser on A0 to LCD_WRN, and a !(AND.NOT) on the DBus Latches, as they update interleaved during Prop-Ram writes.
That leaves the DataBus lines .... hmmm...
Flipping the ALE convention, from Address latch Enable, to Date latch Enable, & using 2 TSSOP24 registered transceivers, we can have a Multiplex action on the Prop pins, and those TSSOP24's can fit under the DIP40, on the other PCB side to the 512K SRAM.
You can get x16 Registered Transceivers, but they are finer pitch, and no cheaper, and look harder to route. besides the TSSOP24's split either side of the DIP40 centre web nicely.
It may be possible to use BUS HOLD 245 type devices, with a little care, as registers, as they are smaller and cheaper than a true register ?
Data says up to 75uA for valid logic keep, and 500uA to flip logic on OE activate.
Series resistor models help lower RFI, so something like 74LVTH2245MTC ?
Hmm, very interesting things to think about. I drafted up a quick idea based on 2 props. I tried to keep it as simple as possible. Thinking about adding a third prop in the "ring" but I think it's best to play with this idea first. The 245's are for fast bus transfers and such. I think it might come in handy. Any thoughts or suggestions?
Hmm, very interesting things to think about. I drafted up a quick idea based on 2 props. I tried to keep it as simple as possible. Thinking about adding a third prop in the "ring" but I think it's best to play with this idea first. The 245's are for fast bus transfers and such. I think it might come in handy. Any thoughts or suggestions?
Very close, but I'd make IC15, IC17 74LVTH2245MTC (bus-hold latch, needs CMOS loads on DBUS), or a LVC543 for a 'proper' latch.
- one issue is the 74LVTH2245MTC does not come in DIP, but you can get SO20, which is large.
Some edge-to-pulse rate doublers dropped in would help speed too.
Edit: Checked some more details, and you do need a 'proper' latched transceiver, for Ram READ.
The bus-hold idea works on write, but on read you need to grab DATA while address is stable, THEN pass that data to the Prop.
You guys don't need to worry about aesthetics much anyhow, being as this appears to be a hobby project, and just get back to brain storming, all night sponsored-by-caffeine hacking, or whatever else you enjoy!
Re two props and the schematic. I still need to get my head around this, but essentially you have a 16 bit fast bus from ram to the display, but you need to also talk to this bus from a propeller to get data from hub-to-ram, or hub-to-display. And you need to talk to the address pins. Seems it needs either 245's or 161s. In that schematic you have four 245s, vs five 161s. Still almost the same number of TTL pins. It possibly ends up lineball. I'll ponder this some more.
I've got all the previous version boards in hand, but the latest one will be next week, and that is the one with the stereo sound and I think the best design so far. Hopefully it works and we can get a few more people using it. I'd like to get C running on the board so you can write huge programs. The GCC guys over on their thread have confirmed that caching can share the ram with the display - it turns out to be very easy with one command that makes sure a C function is running from hub. Then the cache goes to sleep and the display routines can take over all the pins. So devote maybe half the ram to bitmaps and fonts, and the other half to a C program. I've got bits of an html browser working and I think bits of javascript could also be got working quite easily. That opens up a lot of possibilities - you could debug your synthesizer in a PC browser for instance. Crazy stuff and we have only just started to scratch the surface!
Seems it needs either 245's or 161s. In that schematic you have four 245s, vs five 161s.
For the Prop to RAM, with direct Address connects (for speed) you effectively have a flipped multiplex scheme, and so need registered transceivers for RAM (or LCD) read back. (LVC543 or equiv)
I'm looking for Bus Hold and Series terminated registered transceivers, but they are less common than the universal '245. There seem to be plenty of x16 ones, but they really do not fit/route as well as 2 x 8
Arrow show 74LCX543WM for 24c on special offer.
Perhaps SO24L is also being phased out ?
Fastest pathway is the RAM to LCD.
For a smaller-design, best RAM is a single x16 TSSOP44 (0.8mm pitch, and covers 1M/2M/4M/8M which come from ~ $2 to ~ $10) , and transceivers can be either TSSOP24, or SOL24.
Both look route-able, but the SOL24 is easier to solder, and it still fits underneath a DIP40 footprint.
ie you can pack RAM+Transceivers, under a DIP Prop, and then the LCD connect, sits right alongside the Prop.
@jmg, certainly this is a problem to get the brain working!
I think ram to display is the core of the design because that enables the fastest font drawing, and fast picture redraws
Hub to ram and ram to hub are the next thing to add.
I think there could be another cunning circuit lurking out there.
Some of my board designs do strange things with the Eagle autorouter - the closer the chips, the *better* it routes. So - pack em all in!
While waiting for the boards, I took all the code and changed everything from .raw to .bmp files. Much easier to see what is on an sd card too by selecting thumbnail view in windows.
I also have made the icon drawing faster by moving more of it from spin to pasm. Icons have a transparency layer so each pixel has to be tested.
Bootup is faster. About 3 secs from pushing the reset button to having a background image, and another 1.5 seconds to draw all the icons.
I added a textbox - see photo. Still working on things like word wrap and scrolling. One of the "hard" problems is going to be inserting text - if you insert one character do you shuffle all the text in the ram buffer up by one? Or do you have a smaller cache - maybe the current line of text, and only update the ram buffer when the line changes?
Attached code. I can bundle up the fonts and .bmp files if anyone wants these. This whole project is open source.
Some of my board designs do strange things with the Eagle autorouter - the closer the chips, the *better* it routes. So - pack em all in!
The SO24L route better at either end of the RAM than TSSOP24, mainly because they have similar channel width to the TSOP44 RAM.
TI says the SO24L is still an active package.
The registered transceivers landscape is a little confusing.
It seems there are two main choices : a x543, and x2952, but with non-compatible pin-outs - so you cannot allow both in a single artwork.
Even so, change from one to the other is just pin-re-ordering on each side, so does not impact overall PCB size.
NXP's website has gone to corporate bland-land, but TI shows their x2952 much cheaper (35c/1k0 than their x543, (90c/1k)
- I'd favour the x543 simply because there are more sources for this pin-out.
You probably know this already, but the ram address pins can be in any order you want them to be, and so can the data pins. So if you want to change the order to connect more directly to other chips that might help the routing?
You probably know this already, but the ram address pins can be in any order you want them to be, and so can the data pins. So if you want to change the order to connect more directly to other chips that might help the routing?
Yes, and you can also pair-swap pins on the registered transceivers - in the mock up I did, that helps under the Prop, as some pins can connect without vias. Not too many can do this, as the different pin-pitches finally win.
I can't recall if the RAM needed any pin-swap, as it came out quite well with 16b SRAM.
It was mainly a 'Is it possible' proof of concept, and yes, you can pack 1 SRAM and 2 RT under a DIP40, and even have 4 decoupling caps in there too. (Fit in the space under the DIP40 socket)
I doubt 5 x 161 would route quite the same density
The appeal of keeping inside the DIP40 length at least, is that matches the Connector/PCB of the smaller LCD modules.
Update : 5 x LVC161 does have more connections/pins, but it turns out you CAN actually route a 5 x std SO16 underneath a DIP40. (SO16 allows traces between pins, so can sometimes route better than TSSOP16)
Two pairs of each LVC161 go on the top, neatly fit in the DIP40 socket cavities, and one goes underneath by the SRAM.
It is tighter than 2 x SOL24, but just to add a reference point that 5 x LVC161 is not a 'drop dead' problem.
ie Choose the solution that gives the fastest code
So post #231 was just a thought. I plan on sticking with the counters for a bit I think. The possibilities of two props sounds interesting, but it's probably overkill ATM. Regarding text buffer. That's one I've been thinking about for a bit. I have been thinking along the lines of current onscreen text with position markers. I keep wondering if reading from the screen will come in handy for anything other than "layout, template" generation. Reads are slow, but it could save some ram space maybe?
This whole week has been INSANE. I have the screen out of the rackmount, breadboards 99%, and no time to work on anything! Next week....
Comments
FYI, I have seen an additional cap for ac-coupling on some schematics. This is not a big deal b.c. most line-ins have ac-coupling on the input. If using headphones this will place quite a bit of dc-bias on their coils. I have also experienced pops and clicks when turning audio signals on and off. Still have tests to do on this.
re. resistor divider for spidif,. not sure about that. Read http://forums.parallax.com/showthread.php?133075-Polyphonic-SIDcog-synth-WIP&p=1090085&viewfull=1#post1090085
A couple jumpers would be handy to bypass cap, but I'm not sure that they are necessary. IF you REALLY wanted to, a 4066 could switch the cap out of circuit. Latch that in from a few of the extra group pins, just a thought
The other thing I'm thinking about... @ the expo, I grabbed a few 8583 RTC's, and I thought one might come in handy. I also like the second 3232, although I won't be using that or the keyboard right now. I have a feeling the I2C breakout will be coming in VERY handy. Gotta run, just wanted to give an update.
Re putting the RC filter near the prop or near the socket, that is an interesting question. I'd be inclined to think that the digital part is both discrete in terms of high and low, and also a lower impedance (whatever the prop pin impedance is ? a few hundred ohms) cf what comes out of the RC filter which is at least 1k impedance because that is the value of the resistor, and also more prone to interference from nearby pins as it is now analog vs digital so more prone to minor disturbances from nearby pins. So maybe I'm wrong but I put the RC components near the socket rather than near the propeller. I guess the proof will be in the audio testing.
Real time clock? Almost every board I build, I run out of room for a RTC. I've got to try harder!
My "out" is to stick it on the I2C bus that we now have formalised. Use a premade board from futurlec http://www.futurlec.com/Mini_DS1307.shtml or something we design ourselves.
AC coupling - hmm, probably on the amp board? Or at least I hope so. In software you should be able to program it to do a 1V Peak to Peak so it should work with most audio amps.
237's are hard to come by. I got mine from Farnell/Element14 but they are more UK/Australia. We might end up doubling the world market for these chips or something
I have some RS232 to wireless modules (multiple brands) and hope to use that port for interfacing wirelessly to other boards, albeit it at slower baud rates like 2400 or 9600.
LCD cable? Good point. I was thinking about that this morning too. So you have a board in a box but the display is on the front of the box. Use a couple of 40 pin headers and some cable. A standard IDE cable from a PC will do - $1 on ebay or probably free from your local computer store.
Re 4066s vs latches on the cap, well if I get a few extra boards made you can customise them as you want. I'll send you some free ones. I can afford a few extra boards. Today I just moved $20 billion dollars around in the Australian healthcare system, and just ensured that 4 million people will not lose access to their local family doctor. I'm on a high! None of the money comes to me but I don't care right now, this is about improving health and saving lives. It is a big picture thing about helping humanity. So the cost of a few boards here does not matter
I'm not sure about the SPDIF format and specifically, whether it is tolerant of voltages over about 0.7V. I've got to confess, it is a strange world what is easy to achieve (150 letters to local politicians = $20 billion) and what is uncertain (SPDIF voltage specifications). I'm sure those SPDIF specs are there for a reason, so at the worst, it can be done with a couple of resistors, or a LED. In general terms, SPDIF is a very "clean" digital format vs lossy analog. This is where talking to people who actually use synthesizers is really useful! So thanks++
If there are any mistakes on that board, hopefully they are fixable with a few wirelinks. I'll send you some freebies when they come through (? a couple of weeks).
Thanks,
Tyler
Common to all groups are:
P30-31 is serial download
P28-29 is I2C bus
P24-P27 is the SD card
P21 and 23 are audio
P22 selects which group
and P0-P20 are selected in groups.
Group 0 does the 161 latching
Group 1 does memory I/O eg hub to ram, ram to hub, ram to display, hub to display
Group 2 does keyboard, touch input to the touchscreen, second serial port (with handshaking so it can handle being disabled some of the time)
and the other groups are free for whatever you want.
spin code:
PUB Buttons | ck1x,ck1y,ck1s,ck2x,ck2y,ck2s,rd1x,rd1y,rd1s,rd2x, rd2y,rd2s,rd3x,rd3y,rd3s,bu1x,bu1y,xval,yval,redra w ' test out buttons, radio buttons, checkboxes SetOrientation(true) ' portrait view clearscreen(RGBtoWord(212,208,200)) ' background color determined from paintshop ILIloadfont(string("MSans14.ifn")) ' 14 point seems to be the same as 8.25 in vb.net ? why LoadSmallPicture(string("butn8430.raw"),84,30,Pic1) ' a button 84x30 in size LoadSmallPicture(string("Check13A.raw"),13,13,Pic3) ' unchecked checkbox pic3 LoadSmallPicture(string("Check13B.raw"),13,13,Pic4) ' checked checkbox pic4 LoadSmallPicture(string("Radio12A.raw"),12,12,Pic5) ' unchecked radiobox pic 5 LoadSmallPicture(string("Radio12B.raw"),12,12,Pic6) ' checked radiobox pic 6 redraw := true ' set all the locations of the objects on the screen ck1x := ck2x := rd1x := rd2x := rd3x := 20 ' x all the same ck1y := 10 ck2y := ck1y + 40 ' y coordinates rd1y := ck2y + 40 rd2y := rd1y + 40 rd3y := rd2y + 40 bu1x := 80 ' button position bu1y := 280 ck1s := true ' startup status ck2s := false rd1s := true rd2s := false rd3s := false ' now wait for touch SelectSPIGroup ' talk to the spi touchscreen repeat if redraw ' if redraw true then redraw all the objects SelectMemGroup ' display mode DrawCheckbox(ck1x,ck1y,ck1s,string("Checkbox1")) ' checkbox DrawCheckbox(ck2x,ck2y,ck2s,string("Checkbox2")) ' checkbox DrawRadiobox(rd1x,rd1y,rd1s,string("Radiobox1")) ' radiobox DrawRadiobox(rd2x,rd2y,rd2s,string("Radiobox1")) ' radiobox DrawRadiobox(rd3x,rd3y,rd3s,string("Radiobox2")) ' radiobox DrawButton(bu1x,bu1y,pic1,string("Ok")) ' button (fixed size at the moment) redraw := false SelectSPIGroup ' talk to the spi touchscreen yval := TouchYPercent ' decode yval 0-100% xval := TouchXPercent ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress xval := (xval * 24) / 10 ' scale to pixels as can measure from the picture in paintshop yval := (yval * 32) / 10 ' scale to pixels ' cheat a bit here, no need to look for x value as only one column of objects. See calculator for x and y buttons case yval (ck1y-10)..(ck1y+25): !ck1s ' checkbox is small so active area bigger than the checkbox redraw := true ' redraw the screen (ck2y-10)..(ck2y+25): !ck2s ' checkbox is small so active area bigger than the checkbox redraw := true (rd1y-10)..(rd1y+25): rd1s := true ' there probably is a smarter way to make one value true and all the rest false rd2s := false rd3s := false redraw := true (rd2y-10)..(rd2y+25): rd1s := false rd2s := true rd3s := false redraw := true (rd3y-10)..(rd3y+25): rd1s := false rd2s := false rd3s := true redraw := true bu1y..(bu1y + 30): return ' button so exit this screen pause1ms(250) ' debounce repeat PUB DrawCheckbox(x,y,Checked,Stringptr) | i ' draw a checkbox if checked i := pic4 else i := pic3 DrawSmallPicture(x,y,13,13,i) ' size determined from original picture curx := x+20 ' add 20 width cury := y ILIPrintString(stringptr) PUB DrawRadioBox(x,y,Checked,Stringptr)| i ' draw a radio box if checked i := pic6 else i := pic5 DrawSmallPicture(x,y,12,12,i) ' size determined from original picture curx := x+20 ' add 20 width cury := y ILIPrintString(stringptr) PUB DrawButton(x,y,Ramaddress,Stringptr) ' draw a radio box DrawSmallPicture(x,y,84,30,Ramaddress) ' size determined from original picture (later build variable sized buttons, or load them from the sd card) curx := x + (84/2)-(str.len(stringptr)*4 / 2) ' centre, avg width 4 per char 84 could be a variable width passed to this routine cury := y + 8 ILIPrintString(stringptr)I see on Facebook you have a breadboard made up - looking very good. And probably quicker to test things than the way I have been with getting PCBs made.
I have been getting bogged down in the complexity of .raw files. Specifically, each picture has a size, and the size has to be stored somewhere, and if you forget what the size of a picture was, you can't restore it except by trial and error.
So I figured that the .bmp format might be better than the .raw format. And then I figured that keeping track of all these pictures was getting too complex and was wasting a lot of memory allocating larger than the required amount. So I figured we needed a simple disk file system. The nice thing about bitmaps is they contain the file size and width and height. So I preserved that, and added in the filename so you can search for it later.
This code reads in some bitmap files from the sd card into the sram, and then displays them in a different order. Just pass the filename and the x and y location and the routine finds where the file is on the sram and then displays it. Super fast display (max 30 milliseconds for a full screen) that is much faster than reading off the sd card:
LoadBMPtoRamdisk(string("hotair.bmp")) ' load a bitmap and increments ramdisk pointer LoadBMPtoRamdisk(string("cat2.bmp")) ' because we now have 4 Burmese cats! LoadBMPtoRamdisk(string("cat3.bmp")) LoadBMPtoRamdisk(string("nt.bmp")) ' nice picture of the Northern Territory of Australia. setorientation(false) result := DrawBMP(string("nt.bmp"),0,0) result := DrawBMP(string("hotair.bmp"),180,90) result := DrawBMP(string("cat2.bmp"),10,10) result := DrawBMP(string("cat3.bmp"),80,60)Bitmaps took a bit of decoding. Lucky wikipedia has a good description http://en.wikipedia.org/wiki/BMP_file_format
The image is flipped upside down. And if the width happens to end up an odd number, it needs to be padded to a multiple of 4 (eg 109 width is 327 bytes which needs one extra byte to pad to 328). And just to really keep you on your toes, the pixels are BGR instead of RGB.
Bitmaps are a very standard file format. Now I need to recode all the stuff up to now from .raw to .bmp. It should end up a lot easier.
Code for the above routines. I probably could have made better use of Kye's string library for matching filenames. Maybe I'll do that later, eg change the case so it matches even if the case does not match.:
PUB LoadBMPtoRamdisk(stringptr) | width,height,w,i ' load and display a bitmap file ' http://en.wikipedia.org/wiki/BMP_file_format scroll down about 1/3 of the way for the header formats ' get the width, height ' store these as 2 longs at the beginning of the ram file ' the bitmap format starts at the last row and works up so need to reverse the order ' on the ram store a 0x36 byte header - the bitmap header but put in the filename at location 0 ' this becomes a rudimentary file system that can be searched to find pictures propfont_out(".") ' for debugging display something while load in pictures fat.openfile(stringptr,"R") fat.readdata(@sdbuffer,$36) ' get the header 0x36 hex bytes width := sdbuffer[$12] + sdbuffer[$13] << 8 ' only read in two bytes as never will be >64k wide or high height := sdbuffer[$16] + sdbuffer[$17] << 8 w := width * 3 ' this number of bytes per row, and round up to nearest 4 bytes et 327 goes to 328 The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding. w +=3 ' add 3 and w &= %11111111_11111111_11111111_11111100 ' round down repeat i from 0 to 11 ' add the file name at the beginning of the header sdbuffer[i] := byte[stringptr][i] docmd("S",@sdbuffer,RamDiskPointer,$36) ' store header to ram i := $36 + RamDiskPointer + ((height - 1) * width) ' start + header and on the last row and work back repeat height fat.readdata(@sdbuffer,w) ' read in the first row docmd("F",@sdbuffer,@rambuffer,width) HubToRam(i,width) ' send to ram i -= width ' subtract the width, move up the picture fat.closefile RamDiskPointer += $36 + (width * height) ' increment the ramdiskpointer for next picture RamDiskFiles += 1 ' increment number of entries in the ram disk PUB DrawBMP(stringptr,x,y) | i,rampointer,ramcounter,match,searchlen,width,height ' pass the name and the x and y location, searches for this file and if found, displays it rampointer := RamStart searchlen := str.instr(stringptr,".") - 1 ' ignore the .bmp extension repeat ramcounter from 1 to ramdiskfiles docmd("T",@sdbuffer,rampointer,$36) ' get hex $36 bytes from the ramdisk = filenames width := sdbuffer[$12] + sdbuffer[$13] << 8 ' only read in two bytes as never will be >64k wide or high height := sdbuffer[$16] + sdbuffer[$17] << 8 match := true repeat i from 0 to searchlen - 1 if sdbuffer[i] <> byte[stringptr][i] match := false ' any characters not matching, try next one. (case must match too) if match == true quit ' found a match so quit looking for any more files ' get the next rampointer = $36 + width * height rampointer += $36 + (width * height) if match == true ' if found a match display the picture Draw(x,y,x+width-1,y+height-1) ' set up the area to draw RamToDisplay(RamPointer + $36,width*height) ' skip the header and display result := (width <<16) | (height & $0000FFFF) ' return the width and height combined into a longI am really hoping that after 4 lots of PCBs we have a design that is good enough to give away some boards and get some others involved.
Nice to see bitmaps working. I do believe this to be a better route than .raw. What happens if the bmp resolution > display resolution? *just wondering*
I'm also wondering the best way to interface the display with another controller... Wireless. I'm thinking xbee's would work but I don't have any laying around. *My wife made the suggestion of using the display to control her Bri-Bot. Sounds like a fun challenge! *
Back to homework. Keep kickin butt and takin names Doc!
Nothing terrible - it just overlaps at the top of the screen again. However, everything that gets displayed is run through paintshop pro first, to resize and resample the file.
Re interfacing with other controllers, I like RS232. 3 wires, ground, data out and data in. I've got a pile of nifty RS232 to wireless modules, cost around $20 on ebay and they are truly a replacement for a wire link (albeit with no handshaking and slower baud rates, so you can't use them for wirelessly programming propeller chips). I'm hoping with a couple of boards I can replicate what the CP/M wireless network using these modules (CP/M is great but it is a bit impractical lugging around a VGA monitor out in the field). I'd like an icon on the touchscreen that 'discovers' nearby nodes and then automatically sets up links with them.
I guess someone has already suggested using a second Prop, as the Scan counter ?
What clock speeds do you target ?
*edit*
BTW...
Happy Birthday James!
If that speed is ok, then a FPGA/CPLD is not needed.
A small CPLD could do a 20 bit clone of HC161 address counter easily, but if you want to buffer the preload value, and support address Swap for example, you start to nudge up the size.
Adding any sort of write cache pops you to the size of a MachXO2 - essentially the same price as a Prop, and yet another thing to learn.
Just use the second prop as a scan counter, and it can easily manage a little access buffering, Address swap, and some features like fast clear.
If you used a QuadSPI DDR interface, the nibble-wise handling would be similar to the HC161 loading.
Pin count will limit what that 2nd prop can do data-wise, but the between prop link should allow some co-processing off load, into all those spare cogs.. plus 32K of SPI RAM has to be useful ?
Such peripheral focused code will likely be very small, and (in the long term) stable.
Prop1 p0-19 = a0 - a19, RamAddress lines
Prop2 p0-16 = d0-d16 Ram Data, LCD data?
?p26 & p27? interprop comms?
Quad SPI is done all in Sw, so you can all it anything you like.
DDR is a natural to couple with for the WAIT opcode, so why slow things down more ?
Tightly linked COGS may not need a WAIT, but adding it makes the link Auto-baud, so any SW can drive it.
The pin budget would likely limit the 'Logic-prop' to Address-Bus only, but it could add address swap(s), which would be faster SW than HC161,
and I'm sure 32K of SPI memory will find some use.
This doesn't have to be as much of a constraint as many people seem to think... You can actually go quite a bit longer and wider than the screen while still maintaining an acceptable touch screen "slate" form factor. The I-Phone and I-Pad are excellent examples of using this added space as a sort of border.
I keep thinking about the possibilities of using another prop, and it leaves some interesting ideas. I'm starting to think of it as P1-"Main prop", P2-"logic prop" the 7 pins left on the logic prop could do the RS232, keyboard, and other stuff I'm sure. Might want to think about the comms protocol between props. Full-duplex-Serial was my main thought, but that was mainly to save pins. Maybe some sort of ADDRESSABLE? AsyncSerial. With hardware handshaking like your previous board suggested. *Just spitballing again* Now that things have calmed back down and I've caught up, I will have time to do some more tests...
TBC
I see one can fit a 512kx16 SRAM under a DIP40 socket...;)
Thinking about the 'Logic Prop' it needs to couple to the Address lines as the highest priority, as they are what needs to toggle and swap fastest..
Add a couple of LVC1G99's for Edge to Pulse Strobe operation, and you have a HW system that will give a write Pulse, just on an Increment, and a peak possible Ram-LCD rate of 20MHz. I think it needs a XNOR Pulser on A0 to LCD_WRN, and a !(AND.NOT) on the DBus Latches, as they update interleaved during Prop-Ram writes.
That leaves the DataBus lines .... hmmm...
Flipping the ALE convention, from Address latch Enable, to Date latch Enable, & using 2 TSSOP24 registered transceivers, we can have a Multiplex action on the Prop pins, and those TSSOP24's can fit under the DIP40, on the other PCB side to the 512K SRAM.
You can get x16 Registered Transceivers, but they are finer pitch, and no cheaper, and look harder to route. besides the TSSOP24's split either side of the DIP40 centre web nicely.
It may be possible to use BUS HOLD 245 type devices, with a little care, as registers, as they are smaller and cheaper than a true register ?
Data says up to 75uA for valid logic keep, and 500uA to flip logic on OE activate.
Series resistor models help lower RFI, so something like 74LVTH2245MTC ?
Very close, but I'd make IC15, IC17 74LVTH2245MTC (bus-hold latch, needs CMOS loads on DBUS), or a LVC543 for a 'proper' latch.
- one issue is the 74LVTH2245MTC does not come in DIP, but you can get SO20, which is large.
Some edge-to-pulse rate doublers dropped in would help speed too.
Edit: Checked some more details, and you do need a 'proper' latched transceiver, for Ram READ.
The bus-hold idea works on write, but on read you need to grab DATA while address is stable, THEN pass that data to the Prop.
Edge to Pulse Generation for highest data bandwidths VCC | Enable DDR .-. ----------------------------+ | | | | | A0_IP __ | '-' ----+---------------|==| _/ | WR_OP =\_/== | ___ | |o-o/ o----+----- +----|___|--+---|__| R | XNOR eg 1G99 Gate C--- (schmitt) --- | GND A0_IP ______________________/=====================\__________________ WR_OP =======================\____/================\_____/====== [XNOR] K*RC K*RC Mux Bus dddddddddddaaaaaaaaaaaaaa Data_Addr ===\__________/===============\_______/====================== LE_OP ========\___/======================\___/============= K*RC K*RC Pulse @ Both = XNOR Pulse @ Rising only = !(AND.NOT) Pulse @ Falling only = !(NOT.AND)I've got all the previous version boards in hand, but the latest one will be next week, and that is the one with the stereo sound and I think the best design so far. Hopefully it works and we can get a few more people using it. I'd like to get C running on the board so you can write huge programs. The GCC guys over on their thread have confirmed that caching can share the ram with the display - it turns out to be very easy with one command that makes sure a C function is running from hub. Then the cache goes to sleep and the display routines can take over all the pins. So devote maybe half the ram to bitmaps and fonts, and the other half to a C program. I've got bits of an html browser working and I think bits of javascript could also be got working quite easily. That opens up a lot of possibilities - you could debug your synthesizer in a PC browser for instance. Crazy stuff and we have only just started to scratch the surface!
For the Prop to RAM, with direct Address connects (for speed) you effectively have a flipped multiplex scheme, and so need registered transceivers for RAM (or LCD) read back. (LVC543 or equiv)
I'm looking for Bus Hold and Series terminated registered transceivers, but they are less common than the universal '245. There seem to be plenty of x16 ones, but they really do not fit/route as well as 2 x 8
Arrow show 74LCX543WM for 24c on special offer.
Perhaps SO24L is also being phased out ?
Fastest pathway is the RAM to LCD.
For a smaller-design, best RAM is a single x16 TSSOP44 (0.8mm pitch, and covers 1M/2M/4M/8M which come from ~ $2 to ~ $10) , and transceivers can be either TSSOP24, or SOL24.
Both look route-able, but the SOL24 is easier to solder, and it still fits underneath a DIP40 footprint.
ie you can pack RAM+Transceivers, under a DIP Prop, and then the LCD connect, sits right alongside the Prop.
I think ram to display is the core of the design because that enables the fastest font drawing, and fast picture redraws
Hub to ram and ram to hub are the next thing to add.
I think there could be another cunning circuit lurking out there.
Some of my board designs do strange things with the Eagle autorouter - the closer the chips, the *better* it routes. So - pack em all in!
While waiting for the boards, I took all the code and changed everything from .raw to .bmp files. Much easier to see what is on an sd card too by selecting thumbnail view in windows.
I also have made the icon drawing faster by moving more of it from spin to pasm. Icons have a transparency layer so each pixel has to be tested.
Bootup is faster. About 3 secs from pushing the reset button to having a background image, and another 1.5 seconds to draw all the icons.
I added a textbox - see photo. Still working on things like word wrap and scrolling. One of the "hard" problems is going to be inserting text - if you insert one character do you shuffle all the text in the ram buffer up by one? Or do you have a smaller cache - maybe the current line of text, and only update the ram buffer when the line changes?
Attached code. I can bundle up the fonts and .bmp files if anyone wants these. This whole project is open source.
The SO24L route better at either end of the RAM than TSSOP24, mainly because they have similar channel width to the TSOP44 RAM.
TI says the SO24L is still an active package.
The registered transceivers landscape is a little confusing.
It seems there are two main choices : a x543, and x2952, but with non-compatible pin-outs - so you cannot allow both in a single artwork.
Even so, change from one to the other is just pin-re-ordering on each side, so does not impact overall PCB size.
NXP's website has gone to corporate bland-land, but TI shows their x2952 much cheaper (35c/1k0 than their x543, (90c/1k)
- I'd favour the x543 simply because there are more sources for this pin-out.
Yes, and you can also pair-swap pins on the registered transceivers - in the mock up I did, that helps under the Prop, as some pins can connect without vias. Not too many can do this, as the different pin-pitches finally win.
I can't recall if the RAM needed any pin-swap, as it came out quite well with 16b SRAM.
It was mainly a 'Is it possible' proof of concept, and yes, you can pack 1 SRAM and 2 RT under a DIP40, and even have 4 decoupling caps in there too. (Fit in the space under the DIP40 socket)
I doubt 5 x 161 would route quite the same density
The appeal of keeping inside the DIP40 length at least, is that matches the Connector/PCB of the smaller LCD modules.
Update : 5 x LVC161 does have more connections/pins, but it turns out you CAN actually route a 5 x std SO16 underneath a DIP40. (SO16 allows traces between pins, so can sometimes route better than TSSOP16)
Two pairs of each LVC161 go on the top, neatly fit in the DIP40 socket cavities, and one goes underneath by the SRAM.
It is tighter than 2 x SOL24, but just to add a reference point that 5 x LVC161 is not a 'drop dead' problem.
ie Choose the solution that gives the fastest code
This whole week has been INSANE. I have the screen out of the rackmount, breadboards 99%, and no time to work on anything! Next week....