I'm still not sure you can beat the counters. Super fast for ram to the display. And for ram to hub and hub to ram, well both of those need 16 data pins and 18 address pins which is more than a propeller has. So then you have to flip back and forth between address and data which slows things down.
The latest board with stereo sound shipped out from china yesterday. I'm looking forward to some of the audio/synth projects that have been posted lately on the forum I think we could attache those to a picture of a keyboard pretty easily, and then with a few of those slider bars you could adjust the parameters.
Also I'd like to get C running on the board as this gives you much bigger programs.
I'm still not sure you can beat the counters. Super fast for ram to the display.
See the update in my post #240 - turns out you can route 5x LVC161-SO16 under a DIP40, with the 16b SRAM too, - and even have room for a SO8 EEPROM under there too...
You can also use the 1G99 circuit I gave in #233 for any Clock case, to save on lines of ASM on SW clock cases.
I'm still not sure you can beat the counters. Super fast for ram to the display. ....
DR_A,
Please help me understand some things.
Can you explain why you need super fast RAM to drive the display?
What special requirements drive this?
Are there limits caused by Propeller?
Are you updating the entire display area all at once?
What happens if you block-transfer pieces to the display?
What is the required throughput?
The display is 320x240 pixels and each pixel is two bytes RRRRRGGG_GGGBBBBB so the complete display is 153600 bytes. So the first problem is that this is too big for the propeller memory. Even one icon is 59x60x2 = 7080 bytes and so only a few icons at most would fit in the propeller memory.
One scenario might be to have a textbox and when you touch the text box, a keyboard pops up. The keyboard might take up half the screen and so won't fit in propeller memory. Then when you have finished entering some text you want the screen underneath refreshed quickly. So you need a fast way of moving a large picture from external ram to the display.
The displays can read data from all sorts of sources. I believe they can even use an SPI protocol. However, screen updates would be much slower. The fastest way is to use the screens 16 bit bus. Much of the propeller design is dictated by the way the screen is designed. To draw a picture, you send it the x1,y1,x2,y2 coordinates, and then send the right number of words by toggling one line.
This means that if you want to send one pixel you make x1=y1 and x2=y2 and send one word. However, the setup time sending those coordinates takes many times longer (?8x) than sending the singe pixel. This means that if you wanted to send a character of text by sending just the foreground pixels, it takes a lot longer than sending the entire character as a single bitmap. (a downside of this is you need a different font file for every foreground/background color combination).
So fonts can't really be stored in the propeller either. They also need to be stored in external ram as they are often 30-40-50kilobytes in size.
Over the last few months average joe and I have steadily improved the refresh speed. A full screen was 9 seconds in spin, and now is 30 milliseconds. The slowest part is now the SD interface. For instance, when you first boot it up it takes about a second to load the background from the sd card and display it. Then about another second to read in all the fonts and do the transparency calculation and draw these on the ram buffer holding the background picture. So that is two seconds. Then you might push an icon and a program might run, eg the calculator. But when you finish the calculator program, going back to the main screen only takes 30 milliseconds, not 2 seconds.
It makes the whole user experience more natural not having to wait all the time for things to happen.
The required throughput is 320x240x2 bytes which is 1.2 megabits, in 30ms so something like 36 megabits per second.
I'd love to get all this working in a C library ? a .h file, so you can have a simple program printf_touch("hello world); and it prints to a textbox on the screen. It works in Spin but Spin is running out of space so big XMMC programs are going to save the day I think!
Boards have just arrived as I am typing this. This is the design based on your (jazzed's) concept of grouping the propeller pins and having a formal handover between groups where things like SPI devices are shut down, cogs driving pins are shut down and then all pins go HiZ for the handover. I've tested this and it works well - flipping between the SPI driver waiting for fingerpresses to the display update (which is using the same prop pins). Cog reloads are fast and cog starts and stops are fast so it can be simplified down to one function call to swap between groups.
Those were very good questions and a great explanation. Memory is really the limiting factor here and as stated, XMM will save the day here. Unfortunately I will be moving in the next few weeks so I will have very little time to work on anything. After I am moved, I have scheduled a week strictly for development. So sometime next month I should be back up and running.
Sending the x,y position to the screen is QUITE a bit of work, and takes 8 words *I believe* I think there is also a time-out requirement for RS so this slows down commands a bit too and of the 8 words, half are commands.
Maximum clocking for the display is 10MHZ. It would be nice to run the memory faster than display can transfer as this would reduce the time to fill memory from cog. Filling memory from hub to ram transfers will be about 10mhz max too theoretically? *based on hub access window* I know we could use a couple of cogs to speed this up, just stuff to think about. I think moving to SMT will be the next step, which means small redesigns for new ram chips, etc. One requirement I would like but is certainly not the most important thing : the ability to purchace everything for the project, save screen and propeller chip, from the same supplier!
@joe, if I post the boards today will you still be at your current address?
One requirement I would like but is certainly not the most important thing : the ability to purchace everything for the project, save screen and propeller chip, from the same supplier!
Hear hear!
I'm trying to get as much as possible from futurlec. They take ages to deliver, sometimes a PCB can be made faster than a futurlec delivery, but the prices are so amazingly low that it ends up worth it most of the time. Their website has all sorts of things hidden away - eg the switching regulators on that board are there, as are the power inductors but the inductors are hard to find. They sell the 20x2 socket for the display for instance. And sometimes you find categories of parts on the left in the text section but the pictures have not been updated so you can miss whole sections if you only click on the pictures.
I get most parts from futurlec in Thailand. Ram chips from future electronics in Canada. Propeller from Parallax. HC237 from Element14. Display off ebay. So I think that is 5 suppliers.
Once we get a design finalised I guess some kits would be useful.
And I'm looking forward to seeing it shrunk as I know there are experts on this forum who are much better at that than I.
Did I ever tell you, You Rock! So I was thinking about it, and we should come up with a list of different displays. I would like to pick up one of the 2.4" like yours. I really like my 3.2" and wondering if there's a reason the smaller would be preferable? IMO the 3.2" is just about right. The 2.6" - 200 x 400 i have been working with seems a bit small to me. I think they would work great as expansions. I've also thought about running more than one screen. There's a few reasons, but most of all is - fake multi-touch.Gotta run for now. Thanks again!
Just multiplex with some 244s and you would only need one set of 161 counters. And there are plenty of free prop pins when it is in SPI touchscreen reading mode so you can easily read two screens at the same time. Even run one cog per screen waiting for touch input on either of them. This is where the parallel nature of the prop would really shine.
Addit: no I don't think you even need 244s. Parallel up the 16 digital input lines and the reset lines and I think you just need to multiplex two control lines (RS and /WR) to determine which screen the data goes to. So you could maybe do that with just one extra TTL chip.
That's the screen that I purchased. SSD1289. Seems there's a bunch of different 16-bit controllers out there, would be nice to have some way to use different controllers in C with a change in def file.
I've been thinking about controlling multiple screens and whatnot. Seems /WR could be multiplexed. RS could be left with the 16-bit interface? Then control of the /RD still seems handy in a few cases. If we had read control, then we could auto-detect screens?
I'll take some pictures of my screen with reference tomorrow.
Sorry to be hard, but i have been studying the schematic provided by Dr. Acula and there is somthing I can't wrap my head around. The 512k Memory IC's I have looked around and can't seem to find what they are and how they are used and how are they being used in this setup? If anyone could point me to somthing to read to fill me in or explain this to me that would be great. I'm trying to keep up on the display race, but I have fallen way...way behind .
Hi Tyler, the purpose of the RAM chips are to store the fonts and pictures to transfer to the screen. These are needed due to the lack of propeller ram. The fonts or images are loaded from SD card, into hub ram and then pushed out to the 512k RAM chips. There are 2 chips in parallel, giving access to word-aligned data which is necessary for the display's 16 bit bus.
BTW, the memory chips are standard 512k SRAM. Hope this helps a bit. Must run for now but I will edit this with more info later!
I'm working on an order for everything needed to build 2 boards. I have the propeller chips, eeproms, xtals. 3.3 ldo Vregs. Caps, etc. http://www.futureelectronics.com
has almost everything I need, other than the inductors to get the buck converters going... I'm sticking with the 3 terminal regs for now, due to expenses, about $7.50 per board. The other problem is finding a 74hc4316. They are only showing surface mount parts. They do have the 237s, the `32s the `161s and RAM chips. Also grabbing 2 of these regs for 5v. http://www.futureelectronics.com/en/technologies/semiconductors/analog/regulators-reference/linear-regulators/Pages/5372982-LM340T-5.0-NOPB.aspx?IM=0&IT=False
I think that's everything, other than displays and passives I have laying around?
Like average joe says, the ram is for storing pictures and fonts. There simply is not enough room in the propeller to store these, and if you read them out from the sd card it is a bit slow.
Moral of this little story - always read the data sheet... *not*.
Because sometimes the datasheet is wrong. I soldered up a board and all the diagnostic leds came on. Lucky I have diagnostic leds!. So why would that be? The datasheet http://www.nxp.com/documents/data_sheet/74HC237.pdf clearly says
When the latch is enabled (LE = LOW), the 74HC237 acts as a 3-to-8 active
LOW decoder.
But if you scroll down to section 6, the truth table shows it is active HIGH.
So a bit more sleuthing leads to the 74HC137 http://www.nxp.com/documents/data_sheet/74HC137.pdf. Scroll down to the truth table and it is the opposite of the 237. Also the internal diagram has one less inverter. An interestingly, it also says
When the latch is enabled (LE = LOW), the 74HC137 acts as a 3-to-8 active
LOW decoder
So the bottom line is, you need a 74HC137 chip, not a 74HC237.
Addit, re the 4316, you only need that chip if you are adding a keyboard.
Re regulators, at the bottom left of the board are pads for 0V, 3V, 5V so you can always bring in regulated volts from elsewhere and just leave out the switching regulators.
... more twists of fate with this board. Years ago I bought a whole lot of 137 chips mistakenly instead if 138s. I never used them. I just found them in the shed. Also, I have piles of 74HCT32 chips and in amongst those I found one HC32. And then realised that to get this board going in a minimal fashion only needs one chip, not two. So - back to coding...
Also, I have piles of 74HCT32 chips and in amongst those I found one HC32.
Why are you worried about the difference ? - The HCT parts are still CMOS, and will work at 3.3V, they just have skewed FETS on the Pin buffer, so the threshold is moved lower.
So it will switch closer to 1V than 1.65V, but it should work fine in any SW test loop.
I read the datasheet, but not the truth table too! Oops. So, swap 137s for the `237s. Check.
Re, keyboard. I don't think it's the most important so could be scraped for GPIOs or something?
Would you guys be interested in a 256KB 8x SPI memory card?
Crazy idea is to put 8 32K SPI RAM chips on 1 board to get 8 bits wide. It might speed up XMM and it would be a simpler way of doing the same thing you are doing now, but have internal shift registers in the chips.
128K chips can be had, but they are like $13 each, 32K are $1.62 each.
I've got a vague idea that xmm does not even need external memory. The clever boffins over on the GCC thread have built a cache that runs off an SD card. Because most of the time loops of code fit in a cache, cache misses are fairly infrequent and previous experiments have shown that the actual speed of the external memory matters much less with a cache. I'm a bit stuck at the moment as my SD cards are not talking to GCC, but if that can be fixed, I think you don't need external memory for a huge mega/gigabyte program.
I personally don't see the SPI memory boards helping. The big limitation to me is clocking in the start address. That's my main complaint about SPI/QuadSPI. I've had some issues in the past with the sd-cards. Specifically Kye's driver. I will blame the SD cards *or my inability to format them correctly?* since I only have 3 laying around for testing. I will take a look at this later since I did have FSRW working.
I'm wondering what Doc's got in store for the keyboard pins?
One side note, I've been talking with several people who have showed interest in the project. There seems to be QUITE a bit of interest in a portable device. This would require a bit of work IMO. Shouldn't be anything too bad, but an option to dim or turn off the LCD backlight sounds like something to look at.
I've discussed this with my wife a bit, and she suggested I look at putting kits together for the finished design. I know we're close!
*edit*
I've been playing with programming, and for some reason, the Max 3232 on my propRPM is giving me programming errors. Pull it out of circuit and plug-in the PropPlug and everything works perfectly. When the MAX 2323 was plugged into a USB-Serial converter, it was almost impossible to program. When plugged into an ACTUAL serial port on my other pc, I can detect the prop 1 time out of 25 or so. I've read a few things on this but nothing seemed to solve this. I wanted to ask if you EVER have had any issues communicating with the prop via the MAX chip?
Stuff to get working would include getting GCC to run on the board. Not essential though as there is still half the code space free in spin at the moment and it is easy to split programs up (the movie player is a separate program that reboots the propeller just to show it can be done).
How are you planning to get data in and out of the board? RS232 to midi or something else?
Dimming the backlight should be possible. You could add a DAC. Open a group of pins eg group 3 (which are mosly free) then create 4 pins that is an SPI bus and send out data to a DAC. Run the DAC from 5V. If the DAC can source 10mA it should be able to drive the backlight led by programming voltages.
I want to build two of these and use the RS232 port to communicate wirelessly.
I also would like to play a wav file. Kye's original code has a driver for that.
And I'd love to put a few slider pots on the screen and add some of those software synths.
Got to get the software working for the HC137 first.
RE: Data I/O. I'm planning on using the programming port to do SerialMidi with the propPlug. It's the easiest setup I've been able to come up with. What I'm actually banking on : using SPIDIF coax I/O on audio pins or freeing audio in for a Hardware midi In (Say for plugging in my keyboard, use programming port to talk to pc. I can use the multiplexed display pins for as many midi outs as I want.
I didn't even think of using an spi DAC. Brilliant!
Wireless communication would be really nice.
I STILL have not tried playing actual wav files? Maybe later
I'm waiting for the thumbs up on the board to finalize my parts order. BTW, you sent me 2 of these boards?
*edit*
The breadboard is ALMOST wired, but I will probably end up changing things? I substituted a 174 / 138 for the 237. I hope it works. Everything else should be correct though.
Very nice! I am only concerned about having all the parts I need for 2 of these puppies. One "kit" will be shipped to my friend in Oregon. He is very excited to start working with this and should offer a good "beginners" view. I've been waiting a while to make this order, and it will be a while before I order again.
Thank you SO much for the 3 boards! This means I can build one, send one to my friend and I still have an extra! How cool is that!
*edit*
$9.00 SHIPPING for a $16.00 order? This is why I want to order everything at once. Any suggestions of stuff I should order one or 2 of??
Sorry joe, I found a mistake on the board. The logic is wrong with IC1A and IC1B - the two OR gates going into the 161 clocks. D'oh, I've got two gate outputs joined together. And the logic is wrong anyway.
I'm about to "dead bug" a fix, I think the correct logic is to have group0 and group1 going into an AND gate, and the output of that is logic OR with pin19. So if either group0 or group1 are selected (low) then the output of the AND gate will be low, and then if P19 is low as well then it goes through to the clock.
So if you haven't got some already, grab a few 74HC08 chips.
Well that would explain a few things! I don't have any `08s floating around so I must think about this... My parts order shipped today, might end up going to Reno to grab a few. I will be thinking about the logic a bit, maybe I can make it work with something I have around.
The logic you stated sounds correct. Hopefully this will fix the breadboard!
*edit*
After looking through my parts, it looks as if I will be using a `00. Since I'll be using a NAND instead of an AND, I'll need to feed the output of the first NAND through both inputs of a second NAND which will act as an inverter. This should work!
*aedit*
Looking at the schematic a bit more got me thinking... An open-collector "OR" should work as on the v22 schematic? This could be fixed with a couple diodes and a resistor I think!
Yes there are other fixes. A simple OR gate is two diodes going into a pulldown resistor (?10k). And a simple AND gate is two diodes facing the other way and a pull up resistor.
Your NAND solution will work fine too.
One other tiny bug - when the audio changed from P22 and P23 to P21 and P23 I didn't change the 100k pullup. So you need a pullup on P22. I'm fixing it in software at the moment by leaving P22 always connected with a DIRA, but ultimately the purist in me says that formal handovers between groups should involve a DIRA to make every pin HiZ as part of the process. So a little link in the top right corner from P22 to one of the spare 100k SIL resistors will do the trick.
I've got the display working with this new schematic. Big rewrite of the code but the code is simpler now. Testing the 161s now.
I'm off to the shed to make these changes.
Ok, I spent a day coding this and I'm stuck. If you display a picture, the right half is fine and the left half is overwritten with the right half.
Draw a little square 16x16 pixels, put a white pixel at any address above 128 and you get another pixel at the address 128 below this. So the first half of the square is overwritten with the second half. Try to write to the first half and it doesn't work.
I've been doing multiple experiments and I think it is the routine writing to the memory. But I cannot work out what is wrong. It is almost as if it is a timing issue. Maybe the 100k pullup on pin 22 but that pin is not left HiZ - it is pulled up and down in code.
I really don't know where to go from here. Resolder the board. Go back to the old design from a few weeks back with all its flaws (and mono sound). Abandon the pasm code and write it all in spin again.
I'll post my experiments through the afternoon. They don't mean much in themselves, just a demonstration of how bizarre the errors are.
PUB Main | touchtest ' debug value
'term.start( 31, 30, 0, 115200 ) ' for debugging
Margin := 4 ' if set to zero some letters don't display on the left side eg v
start_ram ' start the external ram / display driver in a cog
Change161(0) ' reset all the 161 counters to zero
SelectMemGroup ' select group1
Start_ILI9325 ' start the display. Don't clear screen as this uses ram commands and these might not be working yet
Propfont_string(string("SD")) ' string to send, uses internal prop font so can see something if the SD fails to mount
SetOrientation(true) ' in portrait (true) or landscape mode (false), must be before clearscreen otherwise don't know screensize
Clearscreen(RGBtoWord(0,0,0)) ' clear screen to black - uses the display driver above
' there are bugs with reading and writing from external ram. I suspect it is writing rather than reading back
' as doing a dump to the screen looks the same as the hex numbers.
' display a full screen picture and the right half is correct and the left half is overwritten backwards from the right
' going back to the beginning - something is wrong with writing so lets test it at the bit level
' so is it the transition over 128 that is the problem, or is it the 128th number that is the problem?
' quick test - is the data getting to the routine? Yes it is, using len as the value gives the same problem
'draw(100,100,115,115)
'hubtoram(0,128) ' use len for the number
'ramtodisplay(0,128)
' This little bit of code fails - returns a 1!
'rambuffer[0] := 5
'hubtoram(0,1)
'rambuffer[0] := 6
'ramtohub(0,1)
'hex(rambuffer[0],8)
' ah -but this little bit returns a 5 as it is over 128
' so it is the absolute number
'rambuffer[150] := 5
'hubtoram(0,256)
'rambuffer[150] := 6
'ramtohub(0,256)
'hex(rambuffer[150],4)
' next experiment - this works
'rambuffer[150] := 5
'hubtoram(150,1)
'rambuffer[150] := 6
'ramtohub(150,1)
'hex(rambuffer[150],4)
' and then test with low rambuffer and high ram (4 binary combinations, low ram, low rambuffer, LH HL HH
'rambuffer[0] := 5
'hubtoram(150,1)
'rambuffer[0] := 6
'ramtohub(150,1)
'hex(rambuffer[0],4)
' and that fails
' so this looks very much like it is the rambuffer array that is the problem, not the memory
' ie an array in spin. How can that be?
' time to try a different array then
'sdbuffer[350] := 3 ' two bytes = 1 word
'sdbuffer[351] := 3
'docmd("S",@sdbuffer,150,256)
'sdbuffer[350] :=4
'sdbuffer[351] :=4
'docmd("T",@sdbuffer,150,256)
'hex(sdbuffer[350],2)
' well nothing at all works there. low ram low sdbuffer, high ram, high sdbuffer, low sdbuffer, high ram
' but what does work is if len is 256. But not if len is 1.
' ah - so it is len that is the problem??
' ok, try this - ram is low
'sdbuffer[258] := 3 ' two bytes = 1 word
'docmd("S",@sdbuffer,0,186)
'sdbuffer[258] := 4 ' when this errors, the answer is 4. When it works the answer is 3
'docmd("T",@sdbuffer,0,186)
'hex(sdbuffer[258],2)
' well that works if sdbuffer[350] but not if it is 150 (ie still at the 128 word transition = 256)
' so the combination that works is the array location must be >128 words, and the len has to be a large number
' but the ram location does not matter.
' just for the fun of it let's find where the transition point is for len
' after testing using a binary decision tree, the answer is 176. If len is 175 it does not work, and if 176 or more it does
' what do these numbers mean?!!!
' even more bizarre, that 176 changed a bit. Now it is 186. This suggests a timing problem.
' also with that code above, testing for the exact transition point for the sdbuffer number and it is 258
' so in summary, what works is if you read and write from a location 258 bytes or more from the start of the array
' and you read in and out at least 186 bytes. The ram location does not matter.
' it almost suggests a timing problem - it takes this long for something to sync.
Comments
The latest board with stereo sound shipped out from china yesterday. I'm looking forward to some of the audio/synth projects that have been posted lately on the forum I think we could attache those to a picture of a keyboard pretty easily, and then with a few of those slider bars you could adjust the parameters.
Also I'd like to get C running on the board as this gives you much bigger programs.
See the update in my post #240 - turns out you can route 5x LVC161-SO16 under a DIP40, with the 16b SRAM too, - and even have room for a SO8 EEPROM under there too...
You can also use the 1G99 circuit I gave in #233 for any Clock case, to save on lines of ASM on SW clock cases.
DR_A,
Please help me understand some things.
Can you explain why you need super fast RAM to drive the display?
What special requirements drive this?
Are there limits caused by Propeller?
Are you updating the entire display area all at once?
What happens if you block-transfer pieces to the display?
What is the required throughput?
Thanks,
--Steve
Excellent questions!
The display is 320x240 pixels and each pixel is two bytes RRRRRGGG_GGGBBBBB so the complete display is 153600 bytes. So the first problem is that this is too big for the propeller memory. Even one icon is 59x60x2 = 7080 bytes and so only a few icons at most would fit in the propeller memory.
One scenario might be to have a textbox and when you touch the text box, a keyboard pops up. The keyboard might take up half the screen and so won't fit in propeller memory. Then when you have finished entering some text you want the screen underneath refreshed quickly. So you need a fast way of moving a large picture from external ram to the display.
The displays can read data from all sorts of sources. I believe they can even use an SPI protocol. However, screen updates would be much slower. The fastest way is to use the screens 16 bit bus. Much of the propeller design is dictated by the way the screen is designed. To draw a picture, you send it the x1,y1,x2,y2 coordinates, and then send the right number of words by toggling one line.
This means that if you want to send one pixel you make x1=y1 and x2=y2 and send one word. However, the setup time sending those coordinates takes many times longer (?8x) than sending the singe pixel. This means that if you wanted to send a character of text by sending just the foreground pixels, it takes a lot longer than sending the entire character as a single bitmap. (a downside of this is you need a different font file for every foreground/background color combination).
So fonts can't really be stored in the propeller either. They also need to be stored in external ram as they are often 30-40-50kilobytes in size.
Over the last few months average joe and I have steadily improved the refresh speed. A full screen was 9 seconds in spin, and now is 30 milliseconds. The slowest part is now the SD interface. For instance, when you first boot it up it takes about a second to load the background from the sd card and display it. Then about another second to read in all the fonts and do the transparency calculation and draw these on the ram buffer holding the background picture. So that is two seconds. Then you might push an icon and a program might run, eg the calculator. But when you finish the calculator program, going back to the main screen only takes 30 milliseconds, not 2 seconds.
It makes the whole user experience more natural not having to wait all the time for things to happen.
The required throughput is 320x240x2 bytes which is 1.2 megabits, in 30ms so something like 36 megabits per second.
I'd love to get all this working in a C library ? a .h file, so you can have a simple program printf_touch("hello world); and it prints to a textbox on the screen. It works in Spin but Spin is running out of space so big XMMC programs are going to save the day I think!
Boards have just arrived as I am typing this. This is the design based on your (jazzed's) concept of grouping the propeller pins and having a formal handover between groups where things like SPI devices are shut down, cogs driving pins are shut down and then all pins go HiZ for the handover. I've tested this and it works well - flipping between the SPI driver waiting for fingerpresses to the display update (which is using the same prop pins). Cog reloads are fast and cog starts and stops are fast so it can be simplified down to one function call to swap between groups.
Sending the x,y position to the screen is QUITE a bit of work, and takes 8 words *I believe* I think there is also a time-out requirement for RS so this slows down commands a bit too and of the 8 words, half are commands.
Maximum clocking for the display is 10MHZ. It would be nice to run the memory faster than display can transfer as this would reduce the time to fill memory from cog. Filling memory from hub to ram transfers will be about 10mhz max too theoretically? *based on hub access window* I know we could use a couple of cogs to speed this up, just stuff to think about. I think moving to SMT will be the next step, which means small redesigns for new ram chips, etc. One requirement I would like but is certainly not the most important thing : the ability to purchace everything for the project, save screen and propeller chip, from the same supplier!
Hear hear!
I'm trying to get as much as possible from futurlec. They take ages to deliver, sometimes a PCB can be made faster than a futurlec delivery, but the prices are so amazingly low that it ends up worth it most of the time. Their website has all sorts of things hidden away - eg the switching regulators on that board are there, as are the power inductors but the inductors are hard to find. They sell the 20x2 socket for the display for instance. And sometimes you find categories of parts on the left in the text section but the pictures have not been updated so you can miss whole sections if you only click on the pictures.
I get most parts from futurlec in Thailand. Ram chips from future electronics in Canada. Propeller from Parallax. HC237 from Element14. Display off ebay. So I think that is 5 suppliers.
Once we get a design finalised I guess some kits would be useful.
And I'm looking forward to seeing it shrunk as I know there are experts on this forum who are much better at that than I.
Good luck with the move
Did I ever tell you, You Rock!
Two screens? Yes, we could do that!
Just multiplex with some 244s and you would only need one set of 161 counters. And there are plenty of free prop pins when it is in SPI touchscreen reading mode so you can easily read two screens at the same time. Even run one cog per screen waiting for touch input on either of them. This is where the parallel nature of the prop would really shine.
Addit: no I don't think you even need 244s. Parallel up the 16 digital input lines and the reset lines and I think you just need to multiplex two control lines (RS and /WR) to determine which screen the data goes to. So you could maybe do that with just one extra TTL chip.
I've been thinking about controlling multiple screens and whatnot. Seems /WR could be multiplexed. RS could be left with the 16-bit interface? Then control of the /RD still seems handy in a few cases. If we had read control, then we could auto-detect screens?
I'll take some pictures of my screen with reference tomorrow.
Sorry to be hard, but i have been studying the schematic provided by Dr. Acula and there is somthing I can't wrap my head around. The 512k Memory IC's I have looked around and can't seem to find what they are and how they are used and how are they being used in this setup? If anyone could point me to somthing to read to fill me in or explain this to me that would be great. I'm trying to keep up on the display race, but I have fallen way...way behind
Thanks,
Tyler-
BTW, the memory chips are standard 512k SRAM. Hope this helps a bit. Must run for now but I will edit this with more info later!
*edit*
Doc's link is broken for me?
Just go here... http://www.futureelectronics.com/WebsiteLanding.aspx
and look up
"as6c4008"
*edited again*
I'm working on an order for everything needed to build 2 boards. I have the propeller chips, eeproms, xtals. 3.3 ldo Vregs. Caps, etc.
http://www.futureelectronics.com
has almost everything I need, other than the inductors to get the buck converters going... I'm sticking with the 3 terminal regs for now, due to expenses, about $7.50 per board. The other problem is finding a 74hc4316. They are only showing surface mount parts. They do have the 237s, the `32s the `161s and RAM chips. Also grabbing 2 of these regs for 5v.
http://www.futureelectronics.com/en/technologies/semiconductors/analog/regulators-reference/linear-regulators/Pages/5372982-LM340T-5.0-NOPB.aspx?IM=0&IT=False
I think that's everything, other than displays and passives I have laying around?
Like average joe says, the ram is for storing pictures and fonts. There simply is not enough room in the propeller to store these, and if you read them out from the sd card it is a bit slow.
Moral of this little story - always read the data sheet... *not*.
Because sometimes the datasheet is wrong. I soldered up a board and all the diagnostic leds came on. Lucky I have diagnostic leds!. So why would that be? The datasheet http://www.nxp.com/documents/data_sheet/74HC237.pdf clearly says
But if you scroll down to section 6, the truth table shows it is active HIGH.
So a bit more sleuthing leads to the 74HC137 http://www.nxp.com/documents/data_sheet/74HC137.pdf. Scroll down to the truth table and it is the opposite of the 237. Also the internal diagram has one less inverter. An interestingly, it also says
So the bottom line is, you need a 74HC137 chip, not a 74HC237.
Addit, re the 4316, you only need that chip if you are adding a keyboard.
Re regulators, at the bottom left of the board are pads for 0V, 3V, 5V so you can always bring in regulated volts from elsewhere and just leave out the switching regulators.
... more twists of fate with this board. Years ago I bought a whole lot of 137 chips mistakenly instead if 138s. I never used them. I just found them in the shed. Also, I have piles of 74HCT32 chips and in amongst those I found one HC32. And then realised that to get this board going in a minimal fashion only needs one chip, not two. So - back to coding...
And a question - do we actually need a keyboard??
Why are you worried about the difference ? - The HCT parts are still CMOS, and will work at 3.3V, they just have skewed FETS on the Pin buffer, so the threshold is moved lower.
So it will switch closer to 1V than 1.65V, but it should work fine in any SW test loop.
Re, keyboard. I don't think it's the most important so could be scraped for GPIOs or something?
I'm waiting impatiently for the PropKEY RC1 boards to come so I can proof and order a bunch.
I have to design a flash daughter board now too, so PGCC can have obscene amounts of memory to play with in XMM mode!
Crazy idea is to put 8 32K SPI RAM chips on 1 board to get 8 bits wide. It might speed up XMM and it would be a simpler way of doing the same thing you are doing now, but have internal shift registers in the chips.
128K chips can be had, but they are like $13 each, 32K are $1.62 each.
I'm wondering what Doc's got in store for the keyboard pins?
One side note, I've been talking with several people who have showed interest in the project. There seems to be QUITE a bit of interest in a portable device. This would require a bit of work IMO. Shouldn't be anything too bad, but an option to dim or turn off the LCD backlight sounds like something to look at.
I've discussed this with my wife a bit, and she suggested I look at putting kits together for the finished design. I know we're close!
*edit*
I've been playing with programming, and for some reason, the Max 3232 on my propRPM is giving me programming errors. Pull it out of circuit and plug-in the PropPlug and everything works perfectly. When the MAX 2323 was plugged into a USB-Serial converter, it was almost impossible to program. When plugged into an ACTUAL serial port on my other pc, I can detect the prop 1 time out of 25 or so. I've read a few things on this but nothing seemed to solve this. I wanted to ask if you EVER have had any issues communicating with the prop via the MAX chip?
How are you planning to get data in and out of the board? RS232 to midi or something else?
Dimming the backlight should be possible. You could add a DAC. Open a group of pins eg group 3 (which are mosly free) then create 4 pins that is an SPI bus and send out data to a DAC. Run the DAC from 5V. If the DAC can source 10mA it should be able to drive the backlight led by programming voltages.
I want to build two of these and use the RS232 port to communicate wirelessly.
I also would like to play a wav file. Kye's original code has a driver for that.
And I'd love to put a few slider pots on the screen and add some of those software synths.
Got to get the software working for the HC137 first.
I didn't even think of using an spi DAC. Brilliant!
Wireless communication would be really nice.
I STILL have not tried playing actual wav files? Maybe later
I'm waiting for the thumbs up on the board to finalize my parts order. BTW, you sent me 2 of these boards?
*edit*
The breadboard is ALMOST wired, but I will probably end up changing things? I substituted a 174 / 138 for the 237. I hope it works. Everything else should be correct though.
BTW if we have a working board and you want to experiment with extra things like dimming leds you can bring out the prop pins onto a breadboard.
I sent you 3 boards
Thank you SO much for the 3 boards! This means I can build one, send one to my friend and I still have an extra! How cool is that!
*edit*
$9.00 SHIPPING for a $16.00 order? This is why I want to order everything at once. Any suggestions of stuff I should order one or 2 of??
Also? Can we get a Bill of Materials?
I'm about to "dead bug" a fix, I think the correct logic is to have group0 and group1 going into an AND gate, and the output of that is logic OR with pin19. So if either group0 or group1 are selected (low) then the output of the AND gate will be low, and then if P19 is low as well then it goes through to the clock.
So if you haven't got some already, grab a few 74HC08 chips.
The logic you stated sounds correct. Hopefully this will fix the breadboard!
*edit*
After looking through my parts, it looks as if I will be using a `00. Since I'll be using a NAND instead of an AND, I'll need to feed the output of the first NAND through both inputs of a second NAND which will act as an inverter. This should work!
*aedit*
Looking at the schematic a bit more got me thinking... An open-collector "OR" should work as on the v22 schematic? This could be fixed with a couple diodes and a resistor I think!
Your NAND solution will work fine too.
One other tiny bug - when the audio changed from P22 and P23 to P21 and P23 I didn't change the 100k pullup. So you need a pullup on P22. I'm fixing it in software at the moment by leaving P22 always connected with a DIRA, but ultimately the purist in me says that formal handovers between groups should involve a DIRA to make every pin HiZ as part of the process. So a little link in the top right corner from P22 to one of the spare 100k SIL resistors will do the trick.
I've got the display working with this new schematic. Big rewrite of the code but the code is simpler now. Testing the 161s now.
I'm off to the shed to make these changes.
Ok, I spent a day coding this and I'm stuck. If you display a picture, the right half is fine and the left half is overwritten with the right half.
Draw a little square 16x16 pixels, put a white pixel at any address above 128 and you get another pixel at the address 128 below this. So the first half of the square is overwritten with the second half. Try to write to the first half and it doesn't work.
I've been doing multiple experiments and I think it is the routine writing to the memory. But I cannot work out what is wrong. It is almost as if it is a timing issue. Maybe the 100k pullup on pin 22 but that pin is not left HiZ - it is pulled up and down in code.
I really don't know where to go from here. Resolder the board. Go back to the old design from a few weeks back with all its flaws (and mono sound). Abandon the pasm code and write it all in spin again.
I'll post my experiments through the afternoon. They don't mean much in themselves, just a demonstration of how bizarre the errors are.
PUB Main | touchtest ' debug value 'term.start( 31, 30, 0, 115200 ) ' for debugging Margin := 4 ' if set to zero some letters don't display on the left side eg v start_ram ' start the external ram / display driver in a cog Change161(0) ' reset all the 161 counters to zero SelectMemGroup ' select group1 Start_ILI9325 ' start the display. Don't clear screen as this uses ram commands and these might not be working yet Propfont_string(string("SD")) ' string to send, uses internal prop font so can see something if the SD fails to mount SetOrientation(true) ' in portrait (true) or landscape mode (false), must be before clearscreen otherwise don't know screensize Clearscreen(RGBtoWord(0,0,0)) ' clear screen to black - uses the display driver above ' there are bugs with reading and writing from external ram. I suspect it is writing rather than reading back ' as doing a dump to the screen looks the same as the hex numbers. ' display a full screen picture and the right half is correct and the left half is overwritten backwards from the right ' going back to the beginning - something is wrong with writing so lets test it at the bit level ' so is it the transition over 128 that is the problem, or is it the 128th number that is the problem? ' quick test - is the data getting to the routine? Yes it is, using len as the value gives the same problem 'draw(100,100,115,115) 'hubtoram(0,128) ' use len for the number 'ramtodisplay(0,128) ' This little bit of code fails - returns a 1! 'rambuffer[0] := 5 'hubtoram(0,1) 'rambuffer[0] := 6 'ramtohub(0,1) 'hex(rambuffer[0],8) ' ah -but this little bit returns a 5 as it is over 128 ' so it is the absolute number 'rambuffer[150] := 5 'hubtoram(0,256) 'rambuffer[150] := 6 'ramtohub(0,256) 'hex(rambuffer[150],4) ' next experiment - this works 'rambuffer[150] := 5 'hubtoram(150,1) 'rambuffer[150] := 6 'ramtohub(150,1) 'hex(rambuffer[150],4) ' and then test with low rambuffer and high ram (4 binary combinations, low ram, low rambuffer, LH HL HH 'rambuffer[0] := 5 'hubtoram(150,1) 'rambuffer[0] := 6 'ramtohub(150,1) 'hex(rambuffer[0],4) ' and that fails ' so this looks very much like it is the rambuffer array that is the problem, not the memory ' ie an array in spin. How can that be? ' time to try a different array then 'sdbuffer[350] := 3 ' two bytes = 1 word 'sdbuffer[351] := 3 'docmd("S",@sdbuffer,150,256) 'sdbuffer[350] :=4 'sdbuffer[351] :=4 'docmd("T",@sdbuffer,150,256) 'hex(sdbuffer[350],2) ' well nothing at all works there. low ram low sdbuffer, high ram, high sdbuffer, low sdbuffer, high ram ' but what does work is if len is 256. But not if len is 1. ' ah - so it is len that is the problem?? ' ok, try this - ram is low 'sdbuffer[258] := 3 ' two bytes = 1 word 'docmd("S",@sdbuffer,0,186) 'sdbuffer[258] := 4 ' when this errors, the answer is 4. When it works the answer is 3 'docmd("T",@sdbuffer,0,186) 'hex(sdbuffer[258],2) ' well that works if sdbuffer[350] but not if it is 150 (ie still at the 128 word transition = 256) ' so the combination that works is the array location must be >128 words, and the len has to be a large number ' but the ram location does not matter. ' just for the fun of it let's find where the transition point is for len ' after testing using a binary decision tree, the answer is 176. If len is 175 it does not work, and if 176 or more it does ' what do these numbers mean?!!! ' even more bizarre, that 176 changed a bit. Now it is 186. This suggests a timing problem. ' also with that code above, testing for the exact transition point for the sdbuffer number and it is 258 ' so in summary, what works is if you read and write from a location 258 bytes or more from the start of the array ' and you read in and out at least 186 bytes. The ram location does not matter. ' it almost suggests a timing problem - it takes this long for something to sync.