I am sorry to hear about the issues. I have not had a chance to really think about it but I'm sure we will figure it out.
I have had some difficulties of my own. An object I was working on and had partially tested okay, now refuses to work. No changes in hardware. The bizarre thing is: one method works and the other one doesn't. They do almost exactly the same thing, just with a different command number. I might post this in the appropriate thread later...
The one thing I've been wondering about on the schematic is the '137. Seems to me that toggling gate and enable together might cause issues? Still does not explain what you are experiencing though. If you could post zip of the object, I will try to power on the breadboard tonight. I have everything wired properly *I THINK* except for resistor networks. I don't have any 100k networks laying around, so I'll be using 100k resistors till parts arrive. Installing these has proven time consuming and quite annoying.
*thinking about it more, it sounds like the PASM driver thinks it's doing block transfers? Would be nice to examine this.
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.
If you suspect timing, you could always slow the clock(s) right down, and see if the content changes at all ?
That can give a quick reality-test.
( I've also lowered Vcc on a working uC board, to check timing and system margins)
@average joe, I think you could leave out the 100k resistors for P0 to P15. But they are needed for P16-P20 and definitely on P22.
@average joe - the 137 seems to be working fine. I've got leds on those and once a value is latched in, P22 stays high so the output doesn't change.
Thinking about this more, it is behaving as if A7 on the memory chips is shorted with something. The behaviour is that if A7 is meant to be high, it is high and low at the same time. And if it is meant to be low it is in fact high. The fact that it can write to two memory locations with a single write suggests it is changing state through the write pulse, and maybe it is shorted with a control line. Possibly even the memory write line.
I think I might solder up another board. Glad I used sockets!
I assumed the `137 to be correct, just can't quite wrap my brain around the latching operation. Hopefully my `174 to `138 solution will work for now. My parts are in Salt Lake, UT so they will be here tomorrow morning *I HOPE*
Now that you describe the A7 operation, it does sound as if it's shorted somewhere. Fingers crossed!
*edit*
Breadboard is fully populated *I think*. I have a few last checks to run before I power up and I was wondering if you could post most recent code. Thanks!
Now that you describe the A7 operation, it does sound as if it's shorted somewhere.
I found it!!! When I was fixing the AND gate problem I was cutting tracks with a knife. The A7 track was accidentally cut as well, so it was floating, which explains the strange behaviour.
Code is a mess. Not working at the moment as there is a minor bug either not reading or not writing the first word in a block memory move. I'll post code when I find the bug.
Addit: found the bug. Have to be so careful with the handovers between groups of pins that there are no conditions that can slip through. In this case, the ram /wr pin was not being held high and then in the handover going low and saving the address into the ram as data. So there were two big errors there and no wonder it was hard to debug them!
Right now, I have the background display and the fonts on the screen. Next is to get the touch working.
Ok, pretty much everything is now working with this new board. Those bugs have been a nightmare - two days of solid coding and experimenting. But worth it because this design is simpler and more flexible.
I've had to leave out the movie player and the movie as they are over the limit for the propeller forum.
But I think there is enough there to get things working. Pictures, fonts, demos of text boxes, an onscreen keyboard, a calculator, a slider that moves.
I think the next thing is to port this over to C.
Also the code needs tidying up. Some functions are more part of an "object" while others are part of the code and they are muddled up. In C the object code probably goes in a .h header file - eg things like memory block moves, loading bitmaps etc.
The board I am working on has those few links to add that AND gate. I am getting some more boards made with the simpler schematic attached. We can always add features later but I thought it might be useful to have a minimal feature board.
Nice to hear that everything is working now. I powered on the breadboard and couldn't get things working the other day. I'm chalking it up to my 137 substitute so now that I have a few, time to revise the breadboard. I think the KISS schematic is wonderful, just wondering if we could get pin-headers for Group 4-7?
Just got home from Lake Tahoe, will edit later
*so it's later and*
The comment about the files being to large for the forum got me thinking, I have a webpage set up but have not maintained in a while. I have hosted out of my home before with no problems, but don't have the bandwidth at the moment. When I move I'm getting faster internet. I'll PM you with the details when I get a chance!
PM sent. Once again very nice to hear things are working. I will double check my breadboard against the schematic, but I'm fairly sure to be close. Installing the 137 should make it identical and hopefully it should work then! Building such a complex circuit on a breadboard can be frustrating at times! My previous approach was taking a schematic and deleting every line as I connected things up. Surely there must be a better way!
Looking @ your board, I noticed the LPF looks like carbon resistors and TANT caps. Metal film caps would be WAY better and I've read about using different resistors but not explored this thoroughly. I have used tants with carbon for the filter on breadboard tests and metal film caps sound WAY better IMO. Also, note for headphones it's best to add an ac-coupling cap between the output of the filter and the socket to remove dc bias from the headphone drivers. As I said before it doesn't matter for most line-in situations because those have input caps. DC bias is really hard on headphones though so keep this in mind and don't fry your nice drivers. It won't happen right away but over time, performance WILL degrade. *I built a cheap headphone amp and killed several pair of headphones before I figured out the DC bias problem!*
Lots of notes! I love the debugging LEDS on the audio port! The I2C looks very nice as well. My apprehension with the power supply is cost! Three terminal regulators are less efficient but much cheaper to implement. This is not saying I endorse that route instead, I just wonder if it might be better to assume a regulated supply is already available? This way there could be a couple regulator board choices, maybe one including soft power on and a RTC with Li-ion charger? Just spitballing as usual. Also wondering if the 4 groups of pin-headers on the corners are easier to route this way?
Connector "P23-P1" should read "P8-P15" ?
Another thought is possibly a 4pin header for the PropPlug? Having the MAX onboard is NICE, but I would prefer not to hack connectors on board although using Pinholes for max could accomidate a 4 pin easily I guess.
P21-1 fixed
1uF polyesters added to the output of the audio circuit for ac coupling. Good idea
The audio low pass filter components can be anything you want them to be. I happen to be using metal film resistors and greencap polyester caps. I doubt the resistor type would make much difference though.
Re power supply, ok which regs do you suggest? We have room on the board for some linear regs so ? 7805 for the 5V and what would you like for the 3V?
Re 137 and other groups, you can always add another 137 on another board - it will decode the same. Or put a header on this board.
Ultimately I suspect a smaller board design is where it is heading - surface mount and fit it into the size of the screen. Got to prove it all works first though.
Email sent!
My comments about the LPF might sound trivial, but I did experiment with different caps and found metal films to sound very warm. Poly is an excellent choice too but a bit more expensive? Ceramics sounded about the same as metal films. Tants sound bad in audio circuits, that's all there is to that. The resistor choice is probably less critical but in my audio experiments I have been using carbon composition and metal film resistors. The metal film resistors sound a teensy bit cleaner than carbon comps but carbon sounds slightly warmer? My resistor experiments used very high gain and any resistor noise will probably disappear at lower gains, ie: Line level VS Instrument level. There was also talk about a large value resistor between the output of the LPF to ground on another post. The theory here is to remove the pop when starting an audio cog. The voltage is slowly brought from ground to about 1.65 then handed off like normal. Maybe the resistor would be best to a 1.65v refernece, but I'm not 100% sure. I would like to do some experiments on the breadboard with this very soon.
I am really torn about the voltage regulators. I like the idea of buck-regulation for battery powered devices since they are more efficient. When putting a parts order together I did notice that they are a bit expensive to implement. I'm wondering if there is an advantage to using buck-regulators in a non-battery powered device? If so, maybe it would be worth the cost. I have a small stock of LM7805s *about 20* as well as LM2937ET-3.3 *also about 20* in TO220. These are cheap and don't require inductors for proper operation but do waste a bit of power. To me, it's a bit hard to justify voltage regulation sections that cost more than the micro-controller?
The only reason I mention the pin header for the group outs is we have access to the prop pins on breakout headers. I didn't think about using a second 137 off the board though. As you stated, it will decode the same and the pinouts needed for it are already available!
I wonder if removing the pop has a software solution? Just ramp it up very slowly to half volts?
It is easy enough to add pads for those two linear regs. Then you can either install switching or linear. I'll add that to the next design.
I'm building a software synth at the moment based on Ahle2's tinysynth. I'll have something finished in a few days, but it is possible to play it already and it sounds good. Just need to get all the knobs working.
The page is live, and very blank right now... I will fix this in a bit.
Got the breadboard to fire up, and guess what... SD doesn't work again. Once again, I'm blaming my SD card. Don't have time to troubleshoot right now so I guess I will deal with this later. I think getting the page ready is importaint, as well as preparing my old servers to be revived! I will keep you advised!
I am really torn about the voltage regulators. I like the idea of buck-regulation for battery powered devices since they are more efficient. When putting a parts order together I did notice that they are a bit expensive to implement. I'm wondering if there is an advantage to using buck-regulators in a non-battery powered device? If so, maybe it would be worth the cost. I have a small stock of LM7805s *about 20* as well as LM2937ET-3.3 *also about 20* in TO220. These are cheap and don't require inductors for proper operation but do waste a bit of power. To me, it's a bit hard to justify voltage regulation sections that cost more than the micro-controller?
The ideal here is to be very forgiving of feed supply, which these days should include 5.1V from cell phone chargers.
It should also be adjustable for testing margins, (or over clocking), and should include a RESET signal.
The venerable LP2951 is a good trade off here, very cheap, and Micrel have improved MIC2951 / MIC2954, that include inbuilt reverse protection, so you can save a diode.
If you really want to push the low-drop-out angle, (heavier 5V loads?) then the MIC29303 is a 3A model...
@ jmg, I like the looks of the LP2951-50 Need to finish RTFM but I would say the soic-8's look pretty nice. Perfect for a "core" mockup, and decent price too! Testing margins is a very good point, something I was not even thinking about until now. I don't see there being much 5v load, just a 3.3vreg on the display and back-light for display as well? Maybe whatever you power on a breadboard from the supply rails?
*EDIT*
I fixed it, well sort of. I fudged fsrw into the sd code and it works. Tried re-formatting a couple different times, a few different ways, AGAIN and I will chalk it up to the SD cards. FSRW works for my cards, kye's doesn't. I'm going card hunting at the pawn shops in the next couple days. I'm grinning from ear-to-ear about this, just ashamed it took me this long to get the bread board finished. Caught 2 wiring mistakes, but that's why I triple check everything...
Latest schematic. I added TO220 pads for the 7805 and LM2937 regs - if installing the linear regs then leave out the switching reg, the switching reg diode and the inductors.
Also added 1uF caps in series with the audio output.
Any other suggestions?
I don't know about all the SD card problems. I'm using sandisk 1gb ones if that helps.
Boards showed up this morning but I spent all day installing a car stereo for a client. So I will probably get crackin on the board tonight. I think your design should be perfect! Love the choice of regs! Gotta run for now. More later!
So for those boards the errata are:
1) pullup on P22 (use one of the spare 100k resistors top right of the board if using a network)
2) Only one of the HC32 chips needs to be installed. Install the one on the right and leave out the one on the left. I also left out the second max3232 and the quad switch as the keyboard I don't think is needed.
3) Add the HC08 gate as per that new schematic.
The schematic on post #286 hasn't been made into a board yet. I think I might wait till you get your board soldered up and then together if we find any improvements or bugs we can make the changes.
I'm putting the finishing touches on a touchscreen version of Ahle's TinySynth - hopefully should have something ready in the next couple of days.
With the pin groupings, group 0 is the 161 load. Group 1 is updating the display. Group 2 is reading the touchscreen.
I'm finding the software spends 99% of its time in group 2. So for group 2, only 3 pins are being used for the SPI to talk to the touchscreen and P9 is being used to reset the display. So there are actually a lot of propeller pins free. 17 I think.
I'm wondering about adding a few headers for SPI ports. I know we have i2c but SPI might be useful too as there are lots of SPI objects in the obex. So for these ports, /CS on each device is the 137 output for group 2, so in effect, only 3 pins needed for each SPI port and no extra decoding or chips.
Should be enough room on the board for a few SPI headers.
Sounds good, I should be running fairly quickly. I've modified the 2 sockets and cut the trace from the `32's gates and to the counter. I'm wondering if using a couple small signal diodes *1n4148s* with a pull-up resistor ??*1k?* ?? *10k?*?? to make the AND of the OR's already wired?? Seems like less work, if not I have an 08 to AND the OR's together. Logic is equivalent?
RE, those 4 -resistor 1k networks. I have some 7-resistor and I'm wondering if cutting the wafer after the last resistor used is ok? I can "dope" it with liquid electrical tape to seal it if necessary?
I do want to get things running and tested a bit before printing more boards.
I could use at least a couple SPI ports. Need to think about that a bit. I will let you know when I'm done building...
Should I solder-plate the vias? or do you think they will be ok?
I just got done with a mad wiring session and I have 2 LEDs and an LCD backlight! Installing chips is next and then comes the fun.
As a note! On the new boards, for programming. I placed a 4 pin header on the max chips @ pins 14 - 11. Pin14 comes out to pin 1 on the prop plug. If you can tweak the silk screen to place a box around these pins and notes? Also, ground for prop plug is pin2 of DB9 and reset is pin3 of DB9 Programming port. Reset goes to collector of transistor? Gnd goes to pin4 of 3.3Vreg. If you could also note those with numbers? or something? *Just to make the prop Plug mod easier for a beginner?* I fixed the error by using the unused `32 socket and cutting traces, and re-connecting everything. Fingers crossed!
I will have to translate the SD calls to FSRW, but that shouldn't be TOO horrible since I've done it before.
*edit*
Installing chips, I realized I wired the board for an `08 and I'm using an `00... So I pulled a small breadboard out for now, getting ready to test things!
Okay, I will try the new code. I was using May5th. Groups were not selected and sanity check says everything should work.. I'll update with a few pics when I get it working!
BTW, we should think about putting the LCD registers in an ini file or something. It would make porting to different displays WAY easier!
I have LEDs - power "2-3" and when programming 1. When it starts, it should at least show a group, before I port over to my display. I'll try a few things and keep you updated.
*well seems like the resistor network I used for the group leds is bad? Built a new one. Next?
And the diagnostic leds work now. Also cleaned up the count logic fix. Now to translate the LCD commands and SD stuffs!
SD just worked! It's ALMOST working, just fixin the screen registers.
i have display, but it's all garbled..
@jazzed, thanks for the kind words. Google Images and search for Synthesizer. It is a hybrid of several images. Then a bit of work with Paint Shop Pro. It ends up only five bitmap files - the background, the slider background, slider knob, an "on" switch with LED and an "off" switch with LED in the same position.
I see on the other thread a comment about adding another screen.
It needed one extra chip. Also had to lose the propeller pins round the outside. But to make up for this, it now has 3 SPI ports. And there is the I2C port, and also 3 generic latched digital outputs.
The board is all soldered tested okay. I have been translating the screen registers and still not drawing correctly. Should be able to get this fixed in the next couple days!
Attached is a zip of the code. It is the same as before but what I have done is drawn a line in about the middle and above that line are all the routines that run programs eg the calculator and the synthesizer, and below that line are all the common routines.
I guess it is half way towards turning the code into an object. Before it was a muddle with bits all over the place. I also tried to turn any routines called only by routines in the common area into PRI rather than PUB. Again as a step towards turning into an object.
The first part of the code prints something on the display and you don't need the SD card working for that. I gather you are working towards porting to FSRW?
Well I went pawn-shopping and picked up an SD card that works with Kye's driver. I've been working on "screen register" changes to get my display working. I was able to get the screen to display your background, in landscape but it's all garbled. My request is this, in places where you have this:
ILIcmd($00E5,$78F0) ' set SRAM internal timing
ILIcmd($0001,$0100) ' set SS and SM bit 0001 0100 portrait
ILIcmd($0002,$0700) ' set 1 line inversion
ILIcmd($0003,$1030) ' set GRAM write direction and BGR=1. $0003 $1030
ILIcmd($0004,$0000) ' Resize register
ILIcmd($0008,$0207) ' set the back porch and front porch
ILIcmd($0009,$0000) ' set non-display area refresh cycle ISC[3:0]
ILIcmd($000A,$0000) ' FMARK function
ILIcmd($000C,$0000) ' RGB interface setting
ILIcmd($000D,$0000) ' Frame marker Position
ILIcmd($000F,$0000) ' RGB interface polarity
I would also like to stuff the register SETTINGS *such as "EntryModeLandscape" and "EntryModePortrait" * into the CON block to make changes between screens easier.
So, the display is on. Propfont is not working at all? *LCD Register settings I think* The background displays. *incorrectly* Just gotta keep playing with the numbers until I get it working!
Comments
I have had some difficulties of my own. An object I was working on and had partially tested okay, now refuses to work. No changes in hardware. The bizarre thing is: one method works and the other one doesn't. They do almost exactly the same thing, just with a different command number. I might post this in the appropriate thread later...
The one thing I've been wondering about on the schematic is the '137. Seems to me that toggling gate and enable together might cause issues? Still does not explain what you are experiencing though. If you could post zip of the object, I will try to power on the breadboard tonight. I have everything wired properly *I THINK* except for resistor networks. I don't have any 100k networks laying around, so I'll be using 100k resistors till parts arrive. Installing these has proven time consuming and quite annoying.
*thinking about it more, it sounds like the PASM driver thinks it's doing block transfers? Would be nice to examine this.
If you suspect timing, you could always slow the clock(s) right down, and see if the content changes at all ?
That can give a quick reality-test.
( I've also lowered Vcc on a working uC board, to check timing and system margins)
@average joe, I think you could leave out the 100k resistors for P0 to P15. But they are needed for P16-P20 and definitely on P22.
@average joe - the 137 seems to be working fine. I've got leds on those and once a value is latched in, P22 stays high so the output doesn't change.
Thinking about this more, it is behaving as if A7 on the memory chips is shorted with something. The behaviour is that if A7 is meant to be high, it is high and low at the same time. And if it is meant to be low it is in fact high. The fact that it can write to two memory locations with a single write suggests it is changing state through the write pulse, and maybe it is shorted with a control line. Possibly even the memory write line.
I think I might solder up another board. Glad I used sockets!
Now that you describe the A7 operation, it does sound as if it's shorted somewhere. Fingers crossed!
*edit*
Breadboard is fully populated *I think*. I have a few last checks to run before I power up and I was wondering if you could post most recent code. Thanks!
I found it!!! When I was fixing the AND gate problem I was cutting tracks with a knife. The A7 track was accidentally cut as well, so it was floating, which explains the strange behaviour.
Code is a mess. Not working at the moment as there is a minor bug either not reading or not writing the first word in a block memory move. I'll post code when I find the bug.
Addit: found the bug. Have to be so careful with the handovers between groups of pins that there are no conditions that can slip through. In this case, the ram /wr pin was not being held high and then in the handover going low and saving the address into the ram as data. So there were two big errors there and no wonder it was hard to debug them!
Right now, I have the background display and the fonts on the screen. Next is to get the touch working.
I've had to leave out the movie player and the movie as they are over the limit for the propeller forum.
But I think there is enough there to get things working. Pictures, fonts, demos of text boxes, an onscreen keyboard, a calculator, a slider that moves.
I think the next thing is to port this over to C.
Also the code needs tidying up. Some functions are more part of an "object" while others are part of the code and they are muddled up. In C the object code probably goes in a .h header file - eg things like memory block moves, loading bitmaps etc.
The board I am working on has those few links to add that AND gate. I am getting some more boards made with the simpler schematic attached. We can always add features later but I thought it might be useful to have a minimal feature board.
Just got home from Lake Tahoe, will edit later
*so it's later and*
The comment about the files being to large for the forum got me thinking, I have a webpage set up but have not maintained in a while. I have hosted out of my home before with no problems, but don't have the bandwidth at the moment. When I move I'm getting faster internet. I'll PM you with the details when I get a chance!
PM sent. Once again very nice to hear things are working. I will double check my breadboard against the schematic, but I'm fairly sure to be close. Installing the 137 should make it identical and hopefully it should work then! Building such a complex circuit on a breadboard can be frustrating at times! My previous approach was taking a schematic and deleting every line as I connected things up. Surely there must be a better way!
Looking @ your board, I noticed the LPF looks like carbon resistors and TANT caps. Metal film caps would be WAY better and I've read about using different resistors but not explored this thoroughly. I have used tants with carbon for the filter on breadboard tests and metal film caps sound WAY better IMO. Also, note for headphones it's best to add an ac-coupling cap between the output of the filter and the socket to remove dc bias from the headphone drivers. As I said before it doesn't matter for most line-in situations because those have input caps. DC bias is really hard on headphones though so keep this in mind and don't fry your nice drivers. It won't happen right away but over time, performance WILL degrade. *I built a cheap headphone amp and killed several pair of headphones before I figured out the DC bias problem!*
Lots of notes! I love the debugging LEDS on the audio port! The I2C looks very nice as well. My apprehension with the power supply is cost! Three terminal regulators are less efficient but much cheaper to implement. This is not saying I endorse that route instead, I just wonder if it might be better to assume a regulated supply is already available? This way there could be a couple regulator board choices, maybe one including soft power on and a RTC with Li-ion charger? Just spitballing as usual. Also wondering if the 4 groups of pin-headers on the corners are easier to route this way?
Connector "P23-P1" should read "P8-P15" ?
Another thought is possibly a 4pin header for the PropPlug? Having the MAX onboard is NICE, but I would prefer not to hack connectors on board although using Pinholes for max could accomidate a 4 pin easily I guess.
P21-1 fixed
1uF polyesters added to the output of the audio circuit for ac coupling. Good idea
The audio low pass filter components can be anything you want them to be. I happen to be using metal film resistors and greencap polyester caps. I doubt the resistor type would make much difference though.
Re power supply, ok which regs do you suggest? We have room on the board for some linear regs so ? 7805 for the 5V and what would you like for the 3V?
Re 137 and other groups, you can always add another 137 on another board - it will decode the same. Or put a header on this board.
Ultimately I suspect a smaller board design is where it is heading - surface mount and fit it into the size of the screen. Got to prove it all works first though.
My comments about the LPF might sound trivial, but I did experiment with different caps and found metal films to sound very warm. Poly is an excellent choice too but a bit more expensive? Ceramics sounded about the same as metal films. Tants sound bad in audio circuits, that's all there is to that. The resistor choice is probably less critical but in my audio experiments I have been using carbon composition and metal film resistors. The metal film resistors sound a teensy bit cleaner than carbon comps but carbon sounds slightly warmer? My resistor experiments used very high gain and any resistor noise will probably disappear at lower gains, ie: Line level VS Instrument level. There was also talk about a large value resistor between the output of the LPF to ground on another post. The theory here is to remove the pop when starting an audio cog. The voltage is slowly brought from ground to about 1.65 then handed off like normal. Maybe the resistor would be best to a 1.65v refernece, but I'm not 100% sure. I would like to do some experiments on the breadboard with this very soon.
I am really torn about the voltage regulators. I like the idea of buck-regulation for battery powered devices since they are more efficient. When putting a parts order together I did notice that they are a bit expensive to implement. I'm wondering if there is an advantage to using buck-regulators in a non-battery powered device? If so, maybe it would be worth the cost. I have a small stock of LM7805s *about 20* as well as LM2937ET-3.3 *also about 20* in TO220. These are cheap and don't require inductors for proper operation but do waste a bit of power. To me, it's a bit hard to justify voltage regulation sections that cost more than the micro-controller?
The only reason I mention the pin header for the group outs is we have access to the prop pins on breakout headers. I didn't think about using a second 137 off the board though. As you stated, it will decode the same and the pinouts needed for it are already available!
I wonder if removing the pop has a software solution? Just ramp it up very slowly to half volts?
It is easy enough to add pads for those two linear regs. Then you can either install switching or linear. I'll add that to the next design.
I'm building a software synth at the moment based on Ahle2's tinysynth. I'll have something finished in a few days, but it is possible to play it already and it sounds good. Just need to get all the knobs working.
There is a software solution that helps. I will see if I can find the post...
I have the placeholder page for web...
http://cheeseburgerjoe.dyndns.org/EuroTouch161
The page is live, and very blank right now... I will fix this in a bit.
Got the breadboard to fire up, and guess what... SD doesn't work again. Once again, I'm blaming my SD card. Don't have time to troubleshoot right now so I guess I will deal with this later. I think getting the page ready is importaint, as well as preparing my old servers to be revived! I will keep you advised!
*edit*
I found the post about ramping voltage see http://forums.parallax.com/showthread.php?139343-Help-with-shortest-path-cogs-and-pins-wiring&p=1091712&viewfull=1#post1091712
Microchip have a good, low cost buck regulator, but it still needs a number of external parts....
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en554058
For a test board, something simpler is better.
The ideal here is to be very forgiving of feed supply, which these days should include 5.1V from cell phone chargers.
It should also be adjustable for testing margins, (or over clocking), and should include a RESET signal.
The venerable LP2951 is a good trade off here, very cheap, and Micrel have improved MIC2951 / MIC2954, that include inbuilt reverse protection, so you can save a diode.
If you really want to push the low-drop-out angle, (heavier 5V loads?) then the MIC29303 is a 3A model...
*EDIT*
I fixed it, well sort of. I fudged fsrw into the sd code and it works. Tried re-formatting a couple different times, a few different ways, AGAIN and I will chalk it up to the SD cards. FSRW works for my cards, kye's doesn't. I'm going card hunting at the pawn shops in the next couple days. I'm grinning from ear-to-ear about this, just ashamed it took me this long to get the bread board finished. Caught 2 wiring mistakes, but that's why I triple check everything...
Also added 1uF caps in series with the audio output.
Any other suggestions?
I don't know about all the SD card problems. I'm using sandisk 1gb ones if that helps.
1) pullup on P22 (use one of the spare 100k resistors top right of the board if using a network)
2) Only one of the HC32 chips needs to be installed. Install the one on the right and leave out the one on the left. I also left out the second max3232 and the quad switch as the keyboard I don't think is needed.
3) Add the HC08 gate as per that new schematic.
The schematic on post #286 hasn't been made into a board yet. I think I might wait till you get your board soldered up and then together if we find any improvements or bugs we can make the changes.
I'm putting the finishing touches on a touchscreen version of Ahle's TinySynth - hopefully should have something ready in the next couple of days.
With the pin groupings, group 0 is the 161 load. Group 1 is updating the display. Group 2 is reading the touchscreen.
I'm finding the software spends 99% of its time in group 2. So for group 2, only 3 pins are being used for the SPI to talk to the touchscreen and P9 is being used to reset the display. So there are actually a lot of propeller pins free. 17 I think.
I'm wondering about adding a few headers for SPI ports. I know we have i2c but SPI might be useful too as there are lots of SPI objects in the obex. So for these ports, /CS on each device is the 137 output for group 2, so in effect, only 3 pins needed for each SPI port and no extra decoding or chips.
Should be enough room on the board for a few SPI headers.
RE, those 4 -resistor 1k networks. I have some 7-resistor and I'm wondering if cutting the wafer after the last resistor used is ok? I can "dope" it with liquid electrical tape to seal it if necessary?
I do want to get things running and tested a bit before printing more boards.
I could use at least a couple SPI ports. Need to think about that a bit. I will let you know when I'm done building...
Should I solder-plate the vias? or do you think they will be ok?
As a note! On the new boards, for programming. I placed a 4 pin header on the max chips @ pins 14 - 11. Pin14 comes out to pin 1 on the prop plug. If you can tweak the silk screen to place a box around these pins and notes? Also, ground for prop plug is pin2 of DB9 and reset is pin3 of DB9 Programming port. Reset goes to collector of transistor? Gnd goes to pin4 of 3.3Vreg. If you could also note those with numbers? or something? *Just to make the prop Plug mod easier for a beginner?* I fixed the error by using the unused `32 socket and cutting traces, and re-connecting everything. Fingers crossed!
I will have to translate the SD calls to FSRW, but that shouldn't be TOO horrible since I've done it before.
*edit*
Installing chips, I realized I wired the board for an `08 and I'm using an `00... So I pulled a small breadboard out for now, getting ready to test things!
So that will simplify the board even more - leave out the max3232 and the transistor and reset components.
PUB testJOE pst.start(115200) pst.clear pst.str(string("Started")) pst.newline pst.str(string("Starting Ram returns ")) pst.dec(start_ram) ' start the external ram / display driver in a cog pst.newline 'returns 0 -*GOOD* pst.str(string("Setting Group 0")) start_ram Change137(0) 'no leds? DeadendI just tested this 2 seconds ago. I will keep you posted!You should have at least 2 leds for the 5V and 3V and then 2 more when you do a download. Leds in backwards?
Nice demo. Where do you get all those graphics?
BTW, we should think about putting the LCD registers in an ini file or something. It would make porting to different displays WAY easier!
I have LEDs - power "2-3" and when programming 1. When it starts, it should at least show a group, before I port over to my display. I'll try a few things and keep you updated.
*well seems like the resistor network I used for the group leds is bad? Built a new one. Next?
And the diagnostic leds work now. Also cleaned up the count logic fix. Now to translate the LCD commands and SD stuffs!
SD just worked! It's ALMOST working, just fixin the screen registers.
i have display, but it's all garbled..
I've got to get this into GCC next!
It needed one extra chip. Also had to lose the propeller pins round the outside. But to make up for this, it now has 3 SPI ports. And there is the I2C port, and also 3 generic latched digital outputs.
The second screen doesn't need the SD card.
How are you going with soldering up the board?
Attached is a zip of the code. It is the same as before but what I have done is drawn a line in about the middle and above that line are all the routines that run programs eg the calculator and the synthesizer, and below that line are all the common routines.
I guess it is half way towards turning the code into an object. Before it was a muddle with bits all over the place. I also tried to turn any routines called only by routines in the common area into PRI rather than PUB. Again as a step towards turning into an object.
The first part of the code prints something on the display and you don't need the SD card working for that. I gather you are working towards porting to FSRW?
Have you got any text on the display yet?
ILIcmd($00E5,$78F0) ' set SRAM internal timing ILIcmd($0001,$0100) ' set SS and SM bit 0001 0100 portrait ILIcmd($0002,$0700) ' set 1 line inversion ILIcmd($0003,$1030) ' set GRAM write direction and BGR=1. $0003 $1030 ILIcmd($0004,$0000) ' Resize register ILIcmd($0008,$0207) ' set the back porch and front porch ILIcmd($0009,$0000) ' set non-display area refresh cycle ISC[3:0] ILIcmd($000A,$0000) ' FMARK function ILIcmd($000C,$0000) ' RGB interface setting ILIcmd($000D,$0000) ' Frame marker Position ILIcmd($000F,$0000) ' RGB interface polarityCould we code like this :
CON ' ''LCD REGISTERS" REG_OSCILLATOR = $0000 ''Oscillator (R00h) (POR = 0000h) REG_DRIVEROUTPUTCONTROL = $0001 ''Driver Output Control (R01h) (POR = 2B3Fh) REG_LCDDRIVINGWAVFORM = $0002 ''LCD-Driving-Waveform Control (R02h) (POR = 0000h) REG_POWERCONTROL1 = $0003 '' (R03H) REG_DISPLAYCONTROL = $0007 ''Display Control (R07h) (POR = 0000h) REG_FRAMECYCLECONTROL = $000B ''Frame Cycle Control (R0Bh) (POR = 5308h)D308 BY DATASHEET REG_POWERCONTROL2 = $000C '' (R0Ch) (POR = 0004) REG_POWERCONTROL3 = $000D '' REG_POWERCONTROL4 = $000E '' REG_GATESCANPOSITION = $000F ''Gate Scan Position (R0Fh) (POR = 0000h) REG_SLEEPMODE = $0010 ''Sleep mode (R10h) (POR = 0001h) REG_ENTRYMODE = $0011 ''Entry Mode (R11h) (POR = 6830h) REG_HPORCH = $0016 '' (R16h) (POR = EF1Ch) REG_VPORCH = $0017 '' (R17h) (POR = 0003h) REG_POWERCONTROL5 = $001E '' REG_RAMDATAWRITE = $0022 '' REG_RAMWRITEDATAMASK1 = $0023 '' (R23h) (POR = 0000h) REG_RAMWRITEDATAMASK2 = $0024 '' (R24h) (POR = 0000h) REG_VERTICALSCROLCONTROL1 = $0041 '' (R41h) (POR = 0000h) REG_VERTICALSCROLCONTROL2 = $0042 '' (R42h) (POR = 0000h) REG_HORIZONTALRAMADDRESSPOS = $0044 '' (R44h) (POR = EF00h) REG_VERTICALRAMADDRESSSTART = $0045 '' (R45h) (POR = 0000h) REG_VERTICALRAMADDRESSEND = $0046 '' (R46h) (POR = 013Fh) REG_FIRSTWINDOWSTART = $0048 '' (R48h) (POR = 0000h) REG_FIRSTWINDOWEND = $0049 '' (R49h) (POR = 013Fh) REG_SECONDWINDOWSTART = $004A '' (R4Ah) (POR = 0000h) REG_SECONDWINDOWEND = $004B '' (R4Bh) (POR = 013Fh) REG_SETGDDRXADDRESSCOUNTER = $004E '' (R4Eh) (POR = 0000h) REG_SETGDDRYADDRESSCOUNTER = $004F '' (R4Fh) (POR = 0000h) PRI Init_SSD1289 ''Init Display EnableDisplayPins Lcd_Write_Com (REG_DISPLAYCONTROL) ''Display Control (R07h) (POR = 0000h) Lcd_Write_Data($0021) ''GON = 1 DTE = 0 D[1:0] = 01 Lcd_Write_Com (REG_OSCILLATOR) ''Oscillator (R00h) (POR = 0000h) Lcd_Write_Data($0001) ''Turn on oscillator Lcd_Write_Com (REG_DISPLAYCONTROL) ''Display Control (R07h) (POR = 0000h) Lcd_Write_Data($0023) ''GON = 1 DTE = 0 D[1:0] = 11 Lcd_Write_Com (REG_SLEEPMODE) ''Sleep mode (R10h) (POR = 0001h) Lcd_Write_Data($0000) '' ''exit sleep mode Lcd_Write_Com (REG_DISPLAYCONTROL) ''Display Control (R07h) (POR = 0000h) Lcd_Write_Data($0033) ''GON = 1 DTE = 1 D[1:0] = 11 Lcd_Write_Com (REG_ENTRYMODE) ''Entry Mode (R11h) (POR = 6830h) 6838 Lcd_Write_Data($6838) '' Lcd_Write_Com (REG_LCDDRIVINGWAVFORM) ''LCD-Driving-Waveform Control (R02h) (POR = 0000h)($1000) Lcd_Write_Data($1000) '' '' Lcd_Write_Com (REG_GATESCANPOSITION) ''Gate Scan Position (R0Fh) (POR = 0000h) ($0000) Lcd_Write_Data($0000) '' '' '' Lcd_Write_Com (REG_DRIVEROUTPUTCONTROL) ''Driver Output Control (R01h) (POR = [0XXXX0X1]3Fh) 433f ($633F) 6838 Lcd_Write_Data($6B3F) '' '' Bit 14 - Invert Color bit9-TB Lcd_Write_Com (REG_FRAMECYCLECONTROL) ''Frame Cycle Control (R0Bh) (POR = 5308h) ($5308) Lcd_Write_Data($5308) '' ' Lcd_Write_Com (REG_DISPLAYCONTROL) ''Display Control (R07h) (POR = 0000h) ($0033) Lcd_Write_Data($0033) TristateDisplayPins ''Release pinsI would also like to stuff the register SETTINGS *such as "EntryModeLandscape" and "EntryModePortrait" * into the CON block to make changes between screens easier.So, the display is on. Propfont is not working at all? *LCD Register settings I think* The background displays. *incorrectly* Just gotta keep playing with the numbers until I get it working!