Re the 161 clocks, I managed to find a schematic somewhere on the interweb and just copied that.
Re all the theory about clocking delays, the proof of the pudding is that full screen picture. The data has been clocked from the propeller to the ram, then from the ram to the display and if there were any faults along the way, particularly when a carry ripples through all 5 chips, then there would be tearing of the picture and things like the keys on the synth keyboard would not line up.
The board I am using has about 10 cuts and wire link fixes on it. There is another board on the way but that also has an error on it where P24 now goes to the SD /CS line rather than the audio out. I am mulling over sending the audio out of two channels rather than one and then use a small stereo socket rather than a RCA socket. Use the analog switch chip.
I have no doubt that the board can be made smaller, and ideally as small as the display.
Re sliders, I think using a stylus rather than a finger works a lot better on these displays. I can type characters on a little keyboard with a stylus. I'll see if I can code up a slider.
Another option might be to have several real slider pots and read them in via the I2C bus and you can rename them in software. So you could have a group of pots/knobs/sliders above the display and text on the display saying what they are.
One idea I have is to bring out the I2C bus on some sort of socket. Maybe a 6 pin header with Gnd, 3V, 5V, Clk and Data. Then you can daisy chain that to things like a RTC, a pot, a MCP23008 expander etc.
Re all the theory about clocking delays, the proof of the pudding is that full screen picture. The data has been clocked from the propeller to the ram, then from the ram to the display and if there were any faults along the way, particularly when a carry ripples through all 5 chips, then there would be tearing of the picture and things like the keys on the synth keyboard would not line up.
Of course. And please understand, I was not attacking your work.
I'm interested in a variant of it as discussed back on March 11th.
Using fewer Propeller pins for a general purpose solution is better for me.
I don't want to waste any more money than necessary on re-spins.
This is why I ask questions.
Hi jazzed, yes I think you might be onto something there.
I went for a 3 pins 138 select solution because it was quick and simple, but you are right, in a general sense, formally selecting whole groups of pins with an I2C chip may well be a better solution.
I say that also having emerged from from some high powered, caffeine fueled coding where some conflicts came up with the DIRA/OUTA registers in Spin and the DIRA/OUTA registers in the cog. It seems the best way to do handovers from groups of pins is to do a "DIRA = zero" at the end of blocks of code. Make all pins HiZ and have pullups for mission critical pins such as ram /wr and /rd pins.
So you are right about going back to that March 11th variant. I kind of kept to the concept of groups of pins on the current design eg memory plus display are one group, but I also strayed by using a couple of the 138 pins to do the /load on the 161 groups.
So in summary, thanks++ for those comments, they have got me thinking about a better variant where once the display has been loaded up with images and then needs no further attention, all the prop pins are free for whatever you want them for.
Ok, that needs an I2C driver for a MCP23008 - I think there are some spin ones in the obex. A pasm one should be a fairly short looking at the spin.
Reserved pins could be P28-29 which are i2c, 30-31 which are serial and 24-27 which are an SD card.
P0-P23 are selected in groups based on the output oaf a MCP23008 on the i2c bus. Call them 'boards' because they might be physical boards stacked one on top of each other. If a board is deselected it is up to the hardware to make sure that no pins are left floating and there are pullups etc.
So -
'board 0' would be to load the counters
'board 1' would be the memory and the display.
'board 2' could be the touch part of the touch screen (SPI bus) and audio output and MIDI and the like.
board 3 and up = for anything - P0-P23 free.
But other boards can be whatever you want them to be, including the external ram solutions for GCC.
Would it be ok to allow weak pullups on pins eg 100k, that are still connected to pins even when their board is not selected?
Oh, and yes, it would be cool to get GCC running on this.
Dr Acula should have the schematic just about perfected.
Yea, right...
Ok, here is *another* version. Taking jazzed's idea of formally separating the propeller pins into groups.
Group 0 - load the 161 chips
Group 1 - move data from prop to ram, ram to prop, ram to display.
Group 2 - input/output eg keyboard, touching the touchscreen, midi
I was studying the MCP23008 chip and then figured that what if you selected two boards at the same time? So then you need to use just 3 pins and have a 3 to 8 decoder. And that is two chips, and could there be a chip that has a latch and a decoder all in one?
So I managed to find the 74HC237. Select it with prop pins P0-P2. This was something l looked at before, and I couldn't work out a way of avoiding a latchup whereby board n is selected and it so happens that board n has decided to put n on pins P0-P2 so you can't deselect this board. The answer is to connect the latch of the 237 and one of the enable pins together. Then, when you select the latch, it guarantees that all outputs are high, which then puts all boards into HiZ.
The 237 is latched with P29 which is also the eeprom data line. This will be pulsing at startup, but I think that the propeller boots up with DIRA all zero, so all pins are HiZ, so with some weak pullups on P0-P2 all the outputs of the 237 will be high.
There are a few pins where you definitely do not want there status to change if a board is not currently selected - eg the count of the 161 chips. So for those, there are some OR gates with the current 237 output. There is a special case with the 161 counter pin because either group0 or group1 can talk to this pin.
Another case is the ILI reset pin - even if the ILI chip is deselected with /CS, I am not 100% sure if it won't reset so there is an OR gate on that one.
Chips like the memory chips - if their /CS line is high, then it does not matter what the /RD or /WR lines are doing.
I removed the TV and VGA. There are plenty of really good propeller boards that have TV and VGA. I had put them in for debugging, but now we have the super simple font code using the propeller internal font, that can be used for debugging even if an SD card is not working. You can always add TV and VGA using HC240 and one of the HC237 outputs.
I think the code is going to end up even simpler.
There was a bit of room on the board so I thought I would put in stereo sound and MIDI in and MIDI out. Found some interesting info on midi here http://www.compuphase.com/electronics/midi_rs232.htm I think I have the polarity right - a zero is current flowing, a 1 is no current flowing. Deselected group will be no current flowing too. Hmm - maybe that isn't right, maybe need a transistor inverter in there or something?
The 237 is latched with P29 which is also the eeprom data line. This will be pulsing at startup, but I think that the propeller boots up with DIRA all zero, so all pins are HiZ, so with some weak pullups on P0-P2 all the outputs of the 237 will be high.
Use P28 instead. It will never be driven by the EEPROM - you have control over it.
I'm constantly reminded that P28 needs a pull-up too ... 10K is fine.
For midi In, the best way is to use an opto-isolator which will invert the signal BACK to true. I tried using a 2k resistor to connect directly to the prop and this works too but not the safest way to do it. http://www.ucapps.de/mbhp/mbhp_core_v3.pdf
They use a slight modification, without the output inverters. Sounds like you have the right idea.
Re handing off between spin and pasm. Those pull-up resistors were the best way I could find to do this. Very interesting to see what's developing. Keep up the great work!
My thinking was that if you toggled the data line but not the clock, the eeprom would not care, but if you toggled the clock line then you might accidentally send some data through to the eeprom and tell it to do something?
But that was just a guess - any advice on this would be much appreciated.
I've been thinking about isolating the EEPROM using a 4066 tied to the reset and !reset lines. That has been my whole reason for trying to figure out how to detect an on-chip reset. This will free up BOTH lines and in my design it has a cost of 1 chip. Something to think about
My thinking was that if you toggled the data line but not the clock, the eeprom would not care, but if you toggled the clock line then you might accidentally send some data through to the eeprom and tell it to do something?
But that was just a guess - any advice on this would be much appreciated.
You must toggle both P28 and P29 in a correct sequence to get a response. It's just that P28 is always an output of the Propeller (without the obscure multi-master mode). I use P28 in one application as a clock.
Joe I also have an i2c/serial disconnect circuit though unproven (LS is really LVT).
You must toggle both P28 and P29 in a correct sequence to get a response.
Now what that makes me wonder is, prop to prop communication using i2c on the EEprom pins. What is the lowest parts-count solution we can come up with?
RE ili reset. I can't PROMISE your controller is the same, but my display resets without /CS.
RE midi, again. I think it's best to leave midi off of your board for now. There are other more important things, like `245s between the display bus and prop. Doing a WHOLE screen draw, from RAM would give access to all 16 prop pins. Maybe more if smart about this.
We could use i2c for rotary encoders, but I've been thinking about rotary encoders with push buttons. Not that expensive. And I want A BUNCH. I think reading these, as well as updating a couple 4x40 displays justifies the isolation. At least that's my thought, I will know more in a couple weeks. I need to give that synth image a try. I have some ideas but need to get things working. As a side note, I still have some small bugs in my propFont *I THINK that's where they are*, but it runs MUCH faster. If you blink, you'll miss the blank screen.. Character reads could still be improved but this code is "throw away" at this point.. I'm almost happy with the schematic, I just need to try it out.
RE ili reset. I can't PROMISE your controller is the same, but my display resets without /CS.
Ok, that will be fine with the new 'jazzed inspired' schematic.
Now what that makes me wonder is, prop to prop communication using i2c on the EEprom pins. What is the lowest parts-count solution we can come up with?
Cluso99 is one of our interprop comms experts - on his triblade there are three props designed to work together.
RE midi, again. I think it's best to leave midi off of your board for now.
Midi could be used for data transfer. It is essentially RS232 but with optoisolating. Indeed, in some ways it is even better than RS232 as it does not depend on a common ground. You could use the same hardware and run it at 115200 baud. How fast does you interprop comms need to be?
Another MIDI thought - just found some USB to MIDI adapters on ebay for $8 including shipping. Opens up some intriguing possibilities with a midi keyboard, a PC and one of these prop boards.
There are other more important things, like `245s between the display bus and prop. Doing a WHOLE screen draw, from RAM would give access to all 16 prop pins. Maybe more if smart about this.
I do need to study up on the tri-blade design. Not sure how fast I need but about 4x midi should be more than enough. *That's just an uninformed guess, I still am working on system topology. The "challenge" now is using 1 prop just for audio, pins 0-7 out and 8,9 -10,11 for ADCs.*
Attached is the "new" schematic. It isolates the RAM/Display bus from the propeller pins. This way once the first ram address is loaded and display has draw set, I can use pins 0-15 for banks of buttons, rotary encoders, 2x40 or 4x40 screens, even 16 bit DACs. *I have a couple PCM54's I want to play with* controller_fy.pdf
*edit*
Further experimentation has given some interesting results. I'm still scratching my head about where to go from here. The biggest issue is audio right now. Pin24 is out for audio, leading me to thinking about using pins 16,18 for audio. Once again, let me emphasize that midi will be best left off the board. I'm working on getting RolandSerial Midi driver to connect properly. The issue is getting my usb-serial converter on com 1-4. Once I get this figured out, I plan on using programming connection for serial midi to pc. Later versions may implement midi on-board, but I feel it's best left out at this point.
*aedit*
I ditched RSM because of device issues. I found serial Midi converter here. http://www.spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html It also includes a great tutorial about setting this up. I am also looking for free midi "studios" and have not found anything I like. I think I'm on to something with the serial midi. I can even turn the baudrate WAY up!
I have been working on some midi plugins and having total failure. I have also been toiling with a midi player. Everything is just so slow on this HW, and there's not much memory. I can't wait to get the new HW up and running.
Upon further inspection, it appears the tri-blade uses the eeprom ports in a ring topology. Verification would be nice so I can start playing with this soon. I have been thinking about starting an audio thread, because I feel some tests should be done. I would like to pin down the "best" sounding dac for line output. I would also like to pin down the 8 pins to use for audio on the "audio engine." I would like to include 4 ADCs on the Audio Engine as well. The tri-blade seems perfect for adaption to this system. My thought right now is "Prop 1 = Display Controller, Prop 2 = Audio Engine, Prop 3 = Expansion module?" I have some ideas for the expansion module but need to play around a bit more.
Things are getting exciting, although little progress has been made for the expo. I've tied up some loose ends with the guitar portion of the hardware. I have also done some work on drivers but am currently waiting for liquid electrical tape to dry before I can test those.
*more edit*
Here's a quick thought, what about using SPIDIF?
Movie is a bit blurry but gives an idea of the screen refresh time, esp when hitting the calculator off button.
There are formal handovers from the spi touchscreen to displaying, and this involves starting and stopping the SPI driver cog. I think the technique can be easily expanded so that a propeller can effectively drive hundreds of pins. It is just a matter of remembering to turn off things connected to pins before changing over to other groups of pins.
So re your thoughts on audio, the audio would be off when a screen is being redrawn. Unless you dedicate propeller pins to just audio?
So would you want to be drawing things on the screen while audio is playing?
What we do have on this board is a serial port. It is used for downloads but no reason it can't be then used for inter prop comms. Just a standard RS232 three wire crossover cable (swap pins 2 and 3 on a D9). Then you can use the standard obex objects to send data at 115200 baud between props. Those pins are always free.
I'd like to think it can fit in one propeller. Makes debugging and testing quicker.
I think we can get text faster by moving the "draw" routine into pasm?
Very, very nice work doc! I'm not sure what you mean by pushing draw into PASM. The modified drivers I'm running on the slow hardware allow command AND DATA to be sent to the screen.
hubtodisplayData ' send a block of data blocklen from hubaddr to the display (bypasses external ram)
call #ram_open ' gets hubaddr and len (ignores ramaddress)
call #setRShigh ' set pins for data output
:hubdisploop rdword Display, hubaddr ' copy word from hub, not needed ?
add hubaddr,#2 ' add 2 to hub address changed for word alligned
call #ilidisplayword ' send these bytes to the display
djnz len,#:hubdisploop ' loop until done
jmp #init ' set pins to tristate
hubtodisplayCommand call #ram_open ' gets hubaddr and len (ignores ramaddress)
:hubdisplayloop call #setRSlow ' set pins for Command output
rdword Display, hubaddr ' copy word from hub
add hubaddr,#2 ' add 2 to hub address changed for word alligned
call #ilidisplayword ' send these bytes to the display
djnz len,#:data ' loop until done
jmp #init ' set pins to tristate
:data call #setRShigh
rdword Display, hubaddr ' copy word from hub
add hubaddr,#2 ' add 2 to hub address changed for word alligned
call #ilidisplayword ' send these bytes to the display
djnz len,#:hubdisplayloop ' loop until done
jmp #init ' set pins to tristate
setRShigh mov outa, #0
mov dira, DirsEnabled ' set rsHigh by tristate pin
setRShigh_ret ret
setRSlow mov outa, #0
mov dira, DirsEnabled wz ' set rsHigh by tristate pin
muxz dira, RSpin ' set rsLow by enabling pin
setRslow_ret ret
ilidisplayword ' pass data out, sends out to the display
add zero, #0 wz 'this add presets the data for control pins and primes WZ flag for mux operation
mov outa, Display 'then make pins = data
muxnz dira,EnablePin 'make enable pin low
mov timeout, #$f 'set wait period
:wait1 djnz timeout, :wait1 'and wait
muxz dira, EnablePin 'make enable pin high
ilidisplayword_ret ret
Not the fastest way to do things, but seems to work. PropFont has come a long way from 9 seconds, but still wastes at least 1 cog with character reads. I've been meaning to tune the drivers a bit more but have not had time of course. I keep thinking about pushing ALL the font work into PASM but I'm not sure I will see enough improvement to warrant the effort. Not worth the time right now, maybe later.
I have a few ideas on pin expansion, and need to finish up a schematic on existing "peripherals" which include a foot controller among other things.
I like the idea of using multiple propeller chips. Dedicate one as a display controller, another as audio generator. This will solve some of the problems of the propeller chip not being designed as a "audio / mixed signal" processor. Using the programming port was my though for a while, but then that adds more complexity. Debugging small changes then becomes a pain IMO. Cluso is ?*apparently*? using the eeprom pins, and I would like to do so as well. Could be as simple as 1- 4066 but still would like Cluso's input on his hardware recommendations. Also, I am using the programming port for serial midi now and this works quite well.
Re- audio and screen draws. For my design requirements, at least 1 stereo pair must be running at ALL TIMES! If audio is done on the display controller, it will NEED dedicated pins. To me the best solution is using SPIDIF. This is what I'm thinking right now. When I build the stinkin hardware and finally try it out, I should know more. With SPIDIF, I can have audio out AND IN *something I have been wanting for a while.*
I plan on doing screen refreshes while audio is running. How else am I going to make those keys re-draw active WHILE playing a sidcog?
I see our hardware taking separate, if somewhat compatible, paths. I'm thinking about "synth / audio platform" and it seems you're design is more "single board computer." Large portions of the software SHOULD be interchangeable with different low level drivers. I think the hardware will be different since single board computers don't make the best synths IMO.
I will be working on things a bit more when I get home. Rocklin is rainy and I love it! I spent several hours pinning down the last of the issues with my guitar switcher. Once again, drivers are tuned WAY slow and need to be sped up quite a bit. Still it seems to be working again, despite a testing accident that killed almost half the board. That happened during the last round of driver tuning. Much more rolling around right now, but my brain has that thing...
Plus it has been a difficult 20something hours. Not to be a buzzkill but my grandma passed away yesterday. Can't sleep even though I need it for tomorrow. Hopefully everyone will understand.
*Edit* I am thinking about changing the name of PropFont to ROMFont. Do we have any projects out there with ROMF out there? PF is already taken
P30,31 for serial port, P28-29 for the eeprom and switching the groups, P24-P27 for the sd card.
Then the shared pins
Group0 - load the 161 chips, uses P0-P18 for the address, P22 for load and P23 for clock
Group1 - P0-P15 for a data bus, P16-P19 for rd,wr,ilirs,iliwr, P20 for lilreset
Group3 - P0-P2 for the touchscreen and the rest are free at the moment.
I've just realised that P21 is free on all those. So you could use that for audio.
I have a feeling there is a way of reorganising those pins so that two are freed up to give you stereo audio.
Do you still need interprop comms as well as audio?
If so, I'm wondering if we can think about a protocol with more wires - something like RS232 with RTS and CTS as well. The group 2 could be doing the data comms, and when there is a screen refresh, it sets CTS high so the other prop knows not to send during those times. The serial drivers have buffers.
We can add more serial ports. Serial to MIDI is easy too.
Addit:
See attached schematic. I think this gives you stereo sound at the same time as the display.
Tell me more about SPDIF. I see there are objects in the obex. What does the physical connector look like? Is it just a led. Is this a two way comms protocol?
I THINK that should solve it! The audio channels could be used for prop communication or audio, I have no need for both at the same time. SPIDIF is pretty easy from my understanding. You can use coax or optical. Communication is one way but one cable *or pin* can handle more than one channel.Here's some info as I have not directly worked with it. http://en.wikipedia.org/wiki/S/PDIF
Alesis ADATs *industry standard audio recorders* use a form of TosLink that has 8 channels. I would like to study a bit more but having 8 digital channels would be AWESOME! http://en.wikipedia.org/wiki/ADAT_Lightpipe
I need to check on pins 22 and 23 but they should work? From my understanding, it would be best not to use two consecutive pins. I have heard rumors the 40-pin props are less susceptible to noise. I plan on doing quite extensive audio testing over the next few months. I do think staying in the digital domain is the best and easiest way to get audio out of the prop. This adds some complexity but that is usually the case in superior methods.
That sounds encouraging. So with that schematic you could do some useful things with one propeller?
Now have a text keyboard working. Landscape is better than portrait - keys are bigger so you can type with few mistakes. So, why not a music keyboard and a wavetable synth?
All good fun!
PUB Keyboard | capslock, backspace,xval,yval,address,ascii
Clearscreen(0) ' clear the screen
SetOrientation(false) ' landscape view
ILIloadfont(string("Arial30.ifn")) ' load this font
RawSDToDisplay(string("KeyL.raw")) ' load this picture
capslock := 0 ' default to off ' caps lock
backspace := 0 'default to off ' backspace is zero
str.builtstring(true) ' clear the working string
SelectSPIGroup ' talk to the spi touchscreen
ILISetcursor(margin,27) ' cursor to top left
repeat
xval := TouchValue >> 8 ' decode yval 0-100% and swap x and y as this is landscape mode
yval := TouchValue & 255 ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
SelectMemGroup ' displaying now
address :=255
ascii := 255
xval := (xval * 32) / 10 ' scale to pixels as can measure off the picture
yval := 240 - ((yval * 24) / 10) ' scale to pixels and org top left
case yval
133..162:address := xval / 32 ' top row qwertyuiop
163..188:address := 10 + ((xval-17) / 32) ' second row addres 10 up, offset
189..214:address := 19 + ((xval -47) / 32) ' third row, includes two buttons in one
if xval<47
address := 255 ' non printing character capslock
!capslock ' toggle capslock
if xval >273
!backspace ' backspace character
215..239:if xval >64 and xval < 256
address := 26 ' space bar
if xval>256
address :=27 ' carriage return (LF added below)
if address < 255 and backspace == 0
ascii := lookupz(address: "Q","W","E","R","T","Y","U","I","O","P","A","S","D","F","G","H","J","K","L","Z","X","C","V","B","N","M",32,13)
if (capslock == 0) and (ascii => 65) and (ascii =< 90)
ascii += 32 ' lower case
curx := ILIChar(ascii,curx,cury) ' only print if a valid ascii character
str.buildstring(ascii)
if ascii == 13 ' add line feed if this is a return
ascii := 10 ' add LF
curx := ILIChar(ascii,curx,cury) ' display line feed
str.buildstring(ascii) ' and add to the built string
if backspace <>0 ' backspace redraws the entire string buffer
backspace := 0 ' backspace now zero
str.buildstring(8) ' kye's string routine removes a character
ClearFontBackground(0,22,319,132) ' clear an area the same color as the font background
ILISetcursor(margin,27) ' top left of the screen
ILIPrintstring(str.builtstring(false)) ' redraw text
if xval => 0 and xval <45 and yval => 0 and yval <21
return ' cancel button
if xval => 280 and xval < 320 and yval => 0 and yval <21
result := str.builtstring(true) ' the 'send' button returns the string including carriage return, line feeds (can do multiple lines of input)
return
pause1ms(250) ' debounce
SelectSPIGroup ' wait for next keypress
I just finished watching Chip's presentation on the webinar. Thanks to all those who made it so easy for someone on the other side of the world to log in and watch.
Added a slider knob. @average joe, I think you were wanting these for controlling a synth, right?
[video=youtube_share;JRg1-_EnwwM]
PUB Slider | Percent,startx,starty,xval,yval
Clearscreen(%00000000_00000000) ' background
LoadSmallPicture(string("SlideBck.raw"),36,92,Pic1) ' size determined by paint shop pro, original bmp file (.raw loses the size data)
LoadSmallPicture(string("SlideKnb.raw"),27,19,Pic2) ' slider knob
startx:=100 ' location of the slider
starty:=100
percent := 50 ' start percentage
DrawSmallPicture(startx,starty,36,92,Pic1) ' size determined from original picture
DrawSmallPicture(startx+5,starty+3+(percent*67/100),27,19,Pic2) ' scale for this particular slider image
repeat until (yval >80 and yval<100) ' exit condition hit anywhere in the top of the screen
SelectSPIGroup
yval := TouchValue >> 8 ' decode yval 0-100%
xval := TouchValue & 255 ' decode xval 0-100%
if (xval <> 255) and (yval <> 255) ' valid keypress
SelectMemGroup
percent := (yval-30)*400/100 ' offset and scale
if percent <0 ' make sure in range 0-100
percent :=0
if percent >100
percent :=100
DrawSmallPicture(startx,starty,36,92,Pic1) ' size determined from original picture
DrawSmallPicture(startx+5,starty+3+(percent*67/100),27,19,Pic2) ' scale for this particular slider image
pause1ms(10) ' small pause
Also can you take a look at this schematic. I've taken on board the comments about going in different directions and I don't want to take it too far from something you are going to use. I guess it helps keep me grounded to building useful things. Plus, when I was a kid I spent all my pocket money for years trying to build a synthesizer. There is enough now on this board to make a software one. All the existing objects in the obex. A display. Stereo sound. Mass storage of sounds and pictures. The serial port can be turned into a midi port with just a few components. You can also stack another board on this and select this board with the 237 and get another 22 general purpose pins.
On the schematic I also added weak (100k) pullups to pins so that during the handover between groups of pins, the cog or the spin program does a dira:=0 and the default position is all groups deselected. So during a handover there is no chance of data clashes and pins being left over as outputs going into other outputs.
One thing that slider video demonstrates behind the scenes is flipping quickly between display mode and touchscreen mode. These are actually using different groups of pins (or to be more precise, they are both using the *same* propeller pins), so the handover back and forth needs to be seamless. Read the touchscreen, update the display, and repeat. There is even a 10ms delay loop in there which probably does not need to be there (the loop runs even faster than that). So you can think about looping between multiple groups. eg you could devote 22 propeller pins to reading footpedals, to reading drumpads etc. Then check the touchscreen. Then update the display. A full screen redraw is 30ms but just redrawing a bit of the screen is proportionally faster. So if there was a 10ms delay between hitting a drumpad and sound coming out of the speakers, would this be acceptable?
First, thank you SO much for the package. I got home about an hour ago and had a nice box from Australia sitting on my doorstep. That put quite a smile on my face!
Re sliders, that is so much nicer than what I'm using now. Those should work quite nicely for controlling synths.
Re schematic. I took a quick glance but I'm honestly too tired to think, plus I have that brain thing... I will study it closely tomorrow and let you know my conclusion.
I totally understand not wanting to take it too far from what I'm working on. I would hazard to say this device should work as an entry level synth. A pro-sumer device would need some expansion and a second screen wouldn't hurt, along with some physical buttons and knobs. I've been thinking quite a bit about a full-blown professional synth and working on design requirements. Should have a basic idea in the next few months. I do think this board should be quite capable.
Now 10ms latency for a drum pad is PROBABLY noticeable. 5ms is PROBABLY about right and faster would be better. I know 10ms is SMALL and the entry to average level musician probably wouldn't notice. I, however, get very frustrated trying to play something with 10ms latency. My ASIO driver and software package allows latency compensation and right now I have about 3ms latency. Not noticeable at all. If I nudge it up to 5ms I can start to "feel" it and at 10ms it's practically impossible to play. I am very picky however. Most people are not quite so picky.
I do need to think on the latency a bit more and I will also do a small sample of my musician friends to find out what they actually notice and what they find un-playable. I would hazard a guess @ 7ms and 15-20ms respectively. It will be interesting to find out!
I will get some more info to you shortly. A couple more quick posts and it's bedtime! Keep up the great work!
First, thank you SO much for the package. I got home about an hour ago and had a nice box from Australia sitting on my doorstep. That put quite a smile on my face!
Yea, Doc seems to be a very friendly, intelligent, and helpful person, which is definitely a huge asset to the forum. As this thread progresses, I just wonder where he is headed with this technology he is creating.
Could it all just be an experiment? I venture to guess a phone interface.
What I really want to send to average joe is a PCB board, but the design keeps changing. The board I am using has too many wire links. There are two more recent designs on the way from the fab house and those are closer to the mark. Jazzed's idea of more formally having groups of pins has ended up making the design a lot simpler to think about. And there is the latest design which still I think needs a bit of work to make it into an audio synth. Getting close though.
Those comments about timing delays are extremely useful. I think this might be a situation where the multiple core part of the propeller comes to the rescue.
Ok - general concept - board design, audio, some pins doing video, and some inputs. The video is using too many pins. But... I have an idea. How about we use the I2C bus for all the inputs like drumpads and pots?
There are a wide range of I2C devices. Some, like the MCP23008/MCP23016 can (I think) even be set up so their pins act as interrupt inputs. So you could be reading the time critical inputs with those pins, and then less frequently you could be polling the A to D chips on the I2C bus for pot changes.
Any inputs from the I2C bus go to some hub ram locations, and then an audio cog reads them off the hub. Should get delays down under a millisecond?
So that part runs completely indepenently of the display. The display can be reading the same hub locations but that is less time critical. The display could even do clever things like detect a pot has moved, and bring up a new screen showing what the pot does, and then you can have a small number of pots doing a lot more things (my synth I built when I was 13 ultimately failed because there were so many pots that wires were falling off).
Another idea - say we have a generic board like the design we are working on plus some I2C i/o. You could have two of these boards, same board design, but doing different things. Communicate with the serial pins but that is not so time critical.
Though I still think it is worth trying to do a one propeller solution.
I've wondered sometimes if there is a physical standard for an I2C bus? And if not, how about a 6 pin header, 2 pins for the bus, and bring out Gnd, 3V and 5V and 12V and that should be enough to run lots of peripherals. Then think about a series of small boards, maybe just a MCP23008 and some sort of standard musical sockets (stereo 6.5mm plugs, RCA etc) so you can interface to other equipment. Daisy chain those boards which should work as long as there is not a long run (I2C is a 'local' comms system). Maybe some sort of DIN plug instead of a header? Addit - http://www.nxp.com/documents/data_sheet/P82B715.pdf I2C bus extender could be very useful.
It might mean we don't have to keep redesigning the main board.
@idbruce
Could it all just be an experiment? I venture to guess a phone interface
I'm not entirely sure where it is going, but I think it can do more and more things an android phone or an iphone can do. And for less cost. And it can do other things that are more real world oriented. I'm thinking of a board that can be a synthesizer one day, and the next day can be controlling your quad copter. Fast real-time response is critical for both of these, and I think that little demo with the slider on the display shows it is very much real time now. (much faster than the original 9 seconds for a screen refresh!). I'd like to get a board design that is good enough and flexible enough that we can get some others contributing.
I'm not entirely sure where it is going, but I think it can do more and more things an android phone or an iphone can do. And for less cost. And it can do other things that are more real world oriented. I'm thinking of a board that can be a synthesizer one day, and the next day can be controlling your quad copter. Fast real-time response is critical for both of these, and I think that little demo with the slider on the display shows it is very much real time now. (much faster than the original 9 seconds for a screen refresh!). I'd like to get a board design that is good enough and flexible enough that we can get some others contributing.
Thanks idbruce. Well, this sort of brainstorming is very useful.
If average joe wants lots of inputs running in real time, I think the I2C bus is the answer.
But - I was using one of the I2C pins to control the pin groups. Hmm - that won't work. I checked the I2C bus specs again and according to what they say, you can't toggle either clk or data. Both have special meanings in the I2C world.
So - that means another prop pin. I think we can use P21 here. That means one less pin in the selectable groups, but I think we can live with that, as the ILIreset is only ever run once at bootup. So that can be toggled by a different pin group.
So - now there are P0-P20 = 21 pins in 7 groups (still a lot of spare pins there, I'm only using 52 out of 147).
I also thought I might bring out the I2C bus on a 6 pin header. Some intriguing circuits out there on the internet that can extend the wire length, even an optocoupled I2C isolator. So in general terms the I2C bus can talk to drum pads and slider pots and real world things like that.
Or if time is not so super critical (30ms or so, ie max time for a screen refresh), you can always use those propeller pins that are spare. Some things in music I presume are not so time critical, eg adjusting the Attack/Decay/Sustain/Release pots.
Hmm, I like the idea of using i2c to detect drum pads and knobs. Not super familiar with the protocol, but shouldn't be too much work. That bus expander looks handy indeed! A one propeller solution would be great and I believe a lot could be done with it.
I started wiring up the breadboards this morning and all I can say is Thank You! *I can't say that enough!* My life is SO much easier now that I have the proper bread boarding tools to work with. Should speed up prototyping time exponentially.
Also, the R2R ladders just made me smile! I have been wanting to score a couple of these for testing for a while now.
*edit*
I have an android phone and have played with using it as a controller. There are some great free apps, but they require installing MORE software. *rolls eyes* Even with a 2ghz dual-core snapdragon processor and half a gig of memory, it is still slow IMO.
BTW, the 9 second screen refresh had more to do with me using the display wrong than anything else.
I'm still learning about I2C but it has a lot of potential.
re Android phones, I have an android 7" "pandapad" and I've written a few programs for it. One nice thing is wireless downloading with wifi. Development in Basic http://www.basic4ppc.com/forum/ However it is a bit slow to download and run. I have a few problems with Android though. No real world I/O. The device gets hot. And if it hangs and you need to do a reset and the reset process takes a long time and needs human intervention to get the program running again. Not something that is very practical on a quadcopter for instance.
So if that board looks ok maybe we can think about which I2C chips to use. MCP23008 I think is already in the obex. There are probably others in there too for A to D and D to A.
re. resistor networks. I've read about using resistor networks and analog mux to make selectable RC networks.. and other interesting apps I would like to play with. No time now, but those will come in handy once we move to sound gens and such
I2C has some very nice looking chips indeed. I'm not real familiar with the protocall as I have said, but I have looked at a few different chips from time to time. I always end up using spi instead.
The pandapad is very nice. I've been wanting a tablet to use as a midi controller. My HTC Incredible is a very nice phone, although I have no wireless coverage. I use gvoice and a few workarounds to have a wifi-only phone with poor quality. Thank my ISP for being lame.. When I use free wifi connections, like @Starbucks I get great quality. A few of the free apps I've played with for control surfaces are "FingerPlay" "touchDAW" *which I broke the other day? "Control v1.31" *my favorite. These take quite a bit of setup to use with the computer.
Ableton Live is a very nice program, but very expensive. Propellerhead's Reason is another very nice piece of software too. Also very expensive.. These are the programs I use for music production, but I'm looking for free alternatives for "Open Development" I'm not having any luck finding anything I like.
I have some `32's so that's not a problem but I don't think I have a `237. I'm going to Reno on Wednesday so I will make a list for the Sandy's Electronics.
The MCP23008 should work good for mux I2C bus. I don't have one but I think I have a workaround for now. Chip order will have to wait a while since I spent a bunch of money to go to the Expo.
Now, re the schematic. Here's my though after some close examination.
Swap Pins 19,20 on counter Load,Clock.
Move iliWr to Pin 20 if necessary.
Move AudioL to Pin 21
Move demux 4&6 to Pin 22 *was Pin21*
I can't promise this would be best, but all the hints point to this being the best pinout. So from my understanding, pin23 should be effectively shielded on one side by the supply. By moving AudioL to non-adjacent pin we can reduce crosstalk. Keeping the surrounding pins at lower clocks will help keep noise gremlins at bay as well. This is the reason for swapping pins 19,20. The cog layout may come into play at this point. I still come back to the though that this may not be of huge issue if we use SPIDIF out. We also get audio in as well this way. The only problem is you can't plug it directly into most speakers. So I keep going back and forth. Probably better to design for analog out. Worst-Case design and all that.. Just some things to think about.
Now you got me thinking about drum pads and keys and physical input schemes. I've played with using anti-static foam for weight/pressure sensors before. Makes me wonder what the best DIY method would be to have 16 TOUCH SENSITIVE pads. I was also wondering about a one-octave, touch sensitive, keyboard. They don't have to be "perfect" just a better solution than spending $60 bucks for each. I'm thinking of keeping this completely accessible to the "DIY synth" community.
Adapting the basic design to flying quad-copters wouldn't be too hard. A couple xBees, antennas, Maybe an RF amp? Makes me wonder...
Well every week brings more homework, so I will get back to you after that is done.
*edit*
I was just wondering, other than bit-banging, what would be the best way to do usb?
Now, re the schematic. Here's my though after some close examination.
Swap Pins 19,20 on counter Load,Clock.
Move iliWr to Pin 20 if necessary.
Move AudioL to Pin 21
Move demux 4&6 to Pin 22 *was Pin21*
I can't promise this would be best, but all the hints point to this being the best pinout. So from my understanding, pin23 should be effectively shielded on one side by the supply. By moving AudioL to non-adjacent pin we can reduce crosstalk. Keeping the surrounding pins at lower clocks will help keep noise gremlins at bay as well. This is the reason for swapping pins 19,20. The cog layout may come into play at this point. I still come back to the though that this may not be of huge issue if we use SPIDIF out. We also get audio in as well this way. The only problem is you can't plug it directly into most speakers. So I keep going back and forth. Probably better to design for analog out. Worst-Case design and all that.. Just some things to think about.
Excellent suggestions. I've made all the changes, see attached schematic.
Isn't this cool - a collaborative effort half a world apart?!
I just thought of something, say the audio is too noisy, well then take just one channel of the audio output say the left one, leave out the capacitor, leave in the 1k resistor, plug in a stereo plug and wire a led across the left channel inside the stereo plug and you have an SPDIF output. And use the other channel as audio in? Then just change the software. So that gives flexibility with both solutions.
Very nice! I think we're really close. A bit more schoolwork to finish and then I can get back to bread boarding. I do like the idea of being able to go from analog audio to spidif that easily. TBH, I will probably be using coaxial if I go the digital route. I have several optical connectors, but nothing to plug them into. Creative Labs Soundblaster cards have SPIDIF coax and I have a few of these laying around. Not a big deal since coax is simpler than optical. All we have to do is remove the caps on the audio outs and make software changes. The coax signal goes pin21, resistor, connector *RCA's are standard for coax, and cable is 75ohm impedance*
This is quite exciting, working on a project with someone on the other side of the world. Very cool!
So if you did want to do this, make up a 3 pin stereo plug to a RCA plug, and maybe there is a resistor or two inside that plug to divide the voltage down. I think there are circuits around for SPDIF to TTL and vice versa.
Anyway, I think this can be done off the board with other circuits so it shouldn't affect the board design. It would be cool to select between analog and SPDIF by touching an icon on the screen. Though the capacitor on the audio circuit might be a problem so ? a jumper next to each of those caps. Or would you just bring the pins out with no resistor or capacitor and then do the RC or R/R off board?
Comments
Re all the theory about clocking delays, the proof of the pudding is that full screen picture. The data has been clocked from the propeller to the ram, then from the ram to the display and if there were any faults along the way, particularly when a carry ripples through all 5 chips, then there would be tearing of the picture and things like the keys on the synth keyboard would not line up.
The board I am using has about 10 cuts and wire link fixes on it. There is another board on the way but that also has an error on it where P24 now goes to the SD /CS line rather than the audio out. I am mulling over sending the audio out of two channels rather than one and then use a small stereo socket rather than a RCA socket. Use the analog switch chip.
I have no doubt that the board can be made smaller, and ideally as small as the display.
Re sliders, I think using a stylus rather than a finger works a lot better on these displays. I can type characters on a little keyboard with a stylus. I'll see if I can code up a slider.
Another option might be to have several real slider pots and read them in via the I2C bus and you can rename them in software. So you could have a group of pots/knobs/sliders above the display and text on the display saying what they are.
One idea I have is to bring out the I2C bus on some sort of socket. Maybe a 6 pin header with Gnd, 3V, 5V, Clk and Data. Then you can daisy chain that to things like a RTC, a pot, a MCP23008 expander etc.
Of course. And please understand, I was not attacking your work.
I'm interested in a variant of it as discussed back on March 11th.
Using fewer Propeller pins for a general purpose solution is better for me.
I don't want to waste any more money than necessary on re-spins.
This is why I ask questions.
I went for a 3 pins 138 select solution because it was quick and simple, but you are right, in a general sense, formally selecting whole groups of pins with an I2C chip may well be a better solution.
I say that also having emerged from from some high powered, caffeine fueled coding where some conflicts came up with the DIRA/OUTA registers in Spin and the DIRA/OUTA registers in the cog. It seems the best way to do handovers from groups of pins is to do a "DIRA = zero" at the end of blocks of code. Make all pins HiZ and have pullups for mission critical pins such as ram /wr and /rd pins.
So you are right about going back to that March 11th variant. I kind of kept to the concept of groups of pins on the current design eg memory plus display are one group, but I also strayed by using a couple of the 138 pins to do the /load on the 161 groups.
So in summary, thanks++ for those comments, they have got me thinking about a better variant where once the display has been loaded up with images and then needs no further attention, all the prop pins are free for whatever you want them for.
Ok, that needs an I2C driver for a MCP23008 - I think there are some spin ones in the obex. A pasm one should be a fairly short looking at the spin.
Reserved pins could be P28-29 which are i2c, 30-31 which are serial and 24-27 which are an SD card.
P0-P23 are selected in groups based on the output oaf a MCP23008 on the i2c bus. Call them 'boards' because they might be physical boards stacked one on top of each other. If a board is deselected it is up to the hardware to make sure that no pins are left floating and there are pullups etc.
So -
'board 0' would be to load the counters
'board 1' would be the memory and the display.
'board 2' could be the touch part of the touch screen (SPI bus) and audio output and MIDI and the like.
board 3 and up = for anything - P0-P23 free.
But other boards can be whatever you want them to be, including the external ram solutions for GCC.
Would it be ok to allow weak pullups on pins eg 100k, that are still connected to pins even when their board is not selected?
Oh, and yes, it would be cool to get GCC running on this.
Yea, right...
Ok, here is *another* version. Taking jazzed's idea of formally separating the propeller pins into groups.
Group 0 - load the 161 chips
Group 1 - move data from prop to ram, ram to prop, ram to display.
Group 2 - input/output eg keyboard, touching the touchscreen, midi
I was studying the MCP23008 chip and then figured that what if you selected two boards at the same time? So then you need to use just 3 pins and have a 3 to 8 decoder. And that is two chips, and could there be a chip that has a latch and a decoder all in one?
So I managed to find the 74HC237. Select it with prop pins P0-P2. This was something l looked at before, and I couldn't work out a way of avoiding a latchup whereby board n is selected and it so happens that board n has decided to put n on pins P0-P2 so you can't deselect this board. The answer is to connect the latch of the 237 and one of the enable pins together. Then, when you select the latch, it guarantees that all outputs are high, which then puts all boards into HiZ.
The 237 is latched with P29 which is also the eeprom data line. This will be pulsing at startup, but I think that the propeller boots up with DIRA all zero, so all pins are HiZ, so with some weak pullups on P0-P2 all the outputs of the 237 will be high.
There are a few pins where you definitely do not want there status to change if a board is not currently selected - eg the count of the 161 chips. So for those, there are some OR gates with the current 237 output. There is a special case with the 161 counter pin because either group0 or group1 can talk to this pin.
Another case is the ILI reset pin - even if the ILI chip is deselected with /CS, I am not 100% sure if it won't reset so there is an OR gate on that one.
Chips like the memory chips - if their /CS line is high, then it does not matter what the /RD or /WR lines are doing.
I removed the TV and VGA. There are plenty of really good propeller boards that have TV and VGA. I had put them in for debugging, but now we have the super simple font code using the propeller internal font, that can be used for debugging even if an SD card is not working. You can always add TV and VGA using HC240 and one of the HC237 outputs.
I think the code is going to end up even simpler.
There was a bit of room on the board so I thought I would put in stereo sound and MIDI in and MIDI out. Found some interesting info on midi here http://www.compuphase.com/electronics/midi_rs232.htm I think I have the polarity right - a zero is current flowing, a 1 is no current flowing. Deselected group will be no current flowing too. Hmm - maybe that isn't right, maybe need a transistor inverter in there or something?
Thoughts would be most appreciated.
Use P28 instead. It will never be driven by the EEPROM - you have control over it.
I'm constantly reminded that P28 needs a pull-up too ... 10K is fine.
The mux is much better than that I2C expander.
http://www.ucapps.de/mbhp/mbhp_core_v3.pdf
They use a slight modification, without the output inverters. Sounds like you have the right idea.
Re handing off between spin and pasm. Those pull-up resistors were the best way I could find to do this. Very interesting to see what's developing. Keep up the great work!
Good thinking re the other 10k resistor
Looking at this schematic http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/Propeller-ProtoBoard-v1.2.pdf
Can I just double check re pin 28 or pin 29?
My thinking was that if you toggled the data line but not the clock, the eeprom would not care, but if you toggled the clock line then you might accidentally send some data through to the eeprom and tell it to do something?
But that was just a guess - any advice on this would be much appreciated.
You must toggle both P28 and P29 in a correct sequence to get a response. It's just that P28 is always an output of the Propeller (without the obscure multi-master mode). I use P28 in one application as a clock.
Joe I also have an i2c/serial disconnect circuit though unproven (LS is really LVT).
RE ili reset. I can't PROMISE your controller is the same, but my display resets without /CS.
RE midi, again. I think it's best to leave midi off of your board for now. There are other more important things, like `245s between the display bus and prop. Doing a WHOLE screen draw, from RAM would give access to all 16 prop pins. Maybe more if smart about this.
We could use i2c for rotary encoders, but I've been thinking about rotary encoders with push buttons. Not that expensive. And I want A BUNCH. I think reading these, as well as updating a couple 4x40 displays justifies the isolation. At least that's my thought, I will know more in a couple weeks. I need to give that synth image a try. I have some ideas but need to get things working. As a side note, I still have some small bugs in my propFont *I THINK that's where they are*, but it runs MUCH faster. If you blink, you'll miss the blank screen.. Character reads could still be improved but this code is "throw away" at this point.. I'm almost happy with the schematic, I just need to try it out.
Ok, that will be fine with the new 'jazzed inspired' schematic.
Cluso99 is one of our interprop comms experts - on his triblade there are three props designed to work together.
Midi could be used for data transfer. It is essentially RS232 but with optoisolating. Indeed, in some ways it is even better than RS232 as it does not depend on a common ground. You could use the same hardware and run it at 115200 baud. How fast does you interprop comms need to be?
Another MIDI thought - just found some USB to MIDI adapters on ebay for $8 including shipping. Opens up some intriguing possibilities with a midi keyboard, a PC and one of these prop boards.
Can you explain that a bit more?
Attached is the "new" schematic. It isolates the RAM/Display bus from the propeller pins. This way once the first ram address is loaded and display has draw set, I can use pins 0-15 for banks of buttons, rotary encoders, 2x40 or 4x40 screens, even 16 bit DACs. *I have a couple PCM54's I want to play with* controller_fy.pdf
*edit*
Further experimentation has given some interesting results. I'm still scratching my head about where to go from here. The biggest issue is audio right now. Pin24 is out for audio, leading me to thinking about using pins 16,18 for audio. Once again, let me emphasize that midi will be best left off the board. I'm working on getting RolandSerial Midi driver to connect properly. The issue is getting my usb-serial converter on com 1-4. Once I get this figured out, I plan on using programming connection for serial midi to pc. Later versions may implement midi on-board, but I feel it's best left out at this point.
*aedit*
I ditched RSM because of device issues. I found serial Midi converter here. http://www.spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html It also includes a great tutorial about setting this up. I am also looking for free midi "studios" and have not found anything I like. I think I'm on to something with the serial midi. I can even turn the baudrate WAY up!
I have been working on some midi plugins and having total failure. I have also been toiling with a midi player. Everything is just so slow on this HW, and there's not much memory. I can't wait to get the new HW up and running.
Upon further inspection, it appears the tri-blade uses the eeprom ports in a ring topology. Verification would be nice so I can start playing with this soon. I have been thinking about starting an audio thread, because I feel some tests should be done. I would like to pin down the "best" sounding dac for line output. I would also like to pin down the 8 pins to use for audio on the "audio engine." I would like to include 4 ADCs on the Audio Engine as well. The tri-blade seems perfect for adaption to this system. My thought right now is "Prop 1 = Display Controller, Prop 2 = Audio Engine, Prop 3 = Expansion module?" I have some ideas for the expansion module but need to play around a bit more.
Things are getting exciting, although little progress has been made for the expo. I've tied up some loose ends with the guitar portion of the hardware. I have also done some work on drivers but am currently waiting for liquid electrical tape to dry before I can test those.
*more edit*
Here's a quick thought, what about using SPIDIF?
Movie is a bit blurry but gives an idea of the screen refresh time, esp when hitting the calculator off button.
There are formal handovers from the spi touchscreen to displaying, and this involves starting and stopping the SPI driver cog. I think the technique can be easily expanded so that a propeller can effectively drive hundreds of pins. It is just a matter of remembering to turn off things connected to pins before changing over to other groups of pins.
So re your thoughts on audio, the audio would be off when a screen is being redrawn. Unless you dedicate propeller pins to just audio?
So would you want to be drawing things on the screen while audio is playing?
What we do have on this board is a serial port. It is used for downloads but no reason it can't be then used for inter prop comms. Just a standard RS232 three wire crossover cable (swap pins 2 and 3 on a D9). Then you can use the standard obex objects to send data at 115200 baud between props. Those pins are always free.
I'd like to think it can fit in one propeller. Makes debugging and testing quicker.
I think we can get text faster by moving the "draw" routine into pasm?
hubtodisplayData ' send a block of data blocklen from hubaddr to the display (bypasses external ram) call #ram_open ' gets hubaddr and len (ignores ramaddress) call #setRShigh ' set pins for data output :hubdisploop rdword Display, hubaddr ' copy word from hub, not needed ? add hubaddr,#2 ' add 2 to hub address changed for word alligned call #ilidisplayword ' send these bytes to the display djnz len,#:hubdisploop ' loop until done jmp #init ' set pins to tristate hubtodisplayCommand call #ram_open ' gets hubaddr and len (ignores ramaddress) :hubdisplayloop call #setRSlow ' set pins for Command output rdword Display, hubaddr ' copy word from hub add hubaddr,#2 ' add 2 to hub address changed for word alligned call #ilidisplayword ' send these bytes to the display djnz len,#:data ' loop until done jmp #init ' set pins to tristate :data call #setRShigh rdword Display, hubaddr ' copy word from hub add hubaddr,#2 ' add 2 to hub address changed for word alligned call #ilidisplayword ' send these bytes to the display djnz len,#:hubdisplayloop ' loop until done jmp #init ' set pins to tristate setRShigh mov outa, #0 mov dira, DirsEnabled ' set rsHigh by tristate pin setRShigh_ret ret setRSlow mov outa, #0 mov dira, DirsEnabled wz ' set rsHigh by tristate pin muxz dira, RSpin ' set rsLow by enabling pin setRslow_ret ret ilidisplayword ' pass data out, sends out to the display add zero, #0 wz 'this add presets the data for control pins and primes WZ flag for mux operation mov outa, Display 'then make pins = data muxnz dira,EnablePin 'make enable pin low mov timeout, #$f 'set wait period :wait1 djnz timeout, :wait1 'and wait muxz dira, EnablePin 'make enable pin high ilidisplayword_ret retSetting draw is then done withPUB DrawASM(x1, y1, x2, y2) | HORIZONTALRAMADDRESSPOS ' sets the pixel to x1,y1 and then fills the next (x2-x1)*(y2-y1) pixels HORIZONTALRAMADDRESSPOS := x1 + (x2 << 8) word[@screen][0] := REG_HORIZONTALRAMADDRESSPOS word[@screen][1] := HORIZONTALRAMADDRESSPOS word[@screen][2] := REG_VERTICALRAMADDRESSSTART word[@screen][3] := y1 word[@screen][4] := REG_VERTICALRAMADDRESSEND word[@screen][5] := y2 word[@screen][6] := REG_SETGDDRxADDRESSCOUNTER word[@screen][7] := x1 word[@screen][8] := REG_SETGDDRyADDRESSCOUNTER word[@screen][9] := y1 DoCmd("Z", @screen, -1, 10)Not the fastest way to do things, but seems to work. PropFont has come a long way from 9 seconds, but still wastes at least 1 cog with character reads. I've been meaning to tune the drivers a bit more but have not had time of course. I keep thinking about pushing ALL the font work into PASM but I'm not sure I will see enough improvement to warrant the effort. Not worth the time right now, maybe later.
I have a few ideas on pin expansion, and need to finish up a schematic on existing "peripherals" which include a foot controller among other things.
I like the idea of using multiple propeller chips. Dedicate one as a display controller, another as audio generator. This will solve some of the problems of the propeller chip not being designed as a "audio / mixed signal" processor. Using the programming port was my though for a while, but then that adds more complexity. Debugging small changes then becomes a pain IMO. Cluso is ?*apparently*? using the eeprom pins, and I would like to do so as well. Could be as simple as 1- 4066 but still would like Cluso's input on his hardware recommendations. Also, I am using the programming port for serial midi now and this works quite well.
Re- audio and screen draws. For my design requirements, at least 1 stereo pair must be running at ALL TIMES! If audio is done on the display controller, it will NEED dedicated pins. To me the best solution is using SPIDIF. This is what I'm thinking right now. When I build the stinkin hardware and finally try it out, I should know more. With SPIDIF, I can have audio out AND IN *something I have been wanting for a while.*
I plan on doing screen refreshes while audio is running. How else am I going to make those keys re-draw active WHILE playing a sidcog?
I see our hardware taking separate, if somewhat compatible, paths. I'm thinking about "synth / audio platform" and it seems you're design is more "single board computer." Large portions of the software SHOULD be interchangeable with different low level drivers. I think the hardware will be different since single board computers don't make the best synths IMO.
I will be working on things a bit more when I get home. Rocklin is rainy and I love it! I spent several hours pinning down the last of the issues with my guitar switcher. Once again, drivers are tuned WAY slow and need to be sped up quite a bit. Still it seems to be working again, despite a testing accident that killed almost half the board. That happened during the last round of driver tuning. Much more rolling around right now, but my brain has that thing...
Plus it has been a difficult 20something hours. Not to be a buzzkill but my grandma passed away yesterday. Can't sleep even though I need it for tomorrow. Hopefully everyone will understand.
*Edit* I am thinking about changing the name of PropFont to ROMFont. Do we have any projects out there with ROMF out there? PF is already taken
P30,31 for serial port, P28-29 for the eeprom and switching the groups, P24-P27 for the sd card.
Then the shared pins
Group0 - load the 161 chips, uses P0-P18 for the address, P22 for load and P23 for clock
Group1 - P0-P15 for a data bus, P16-P19 for rd,wr,ilirs,iliwr, P20 for lilreset
Group3 - P0-P2 for the touchscreen and the rest are free at the moment.
I've just realised that P21 is free on all those. So you could use that for audio.
I have a feeling there is a way of reorganising those pins so that two are freed up to give you stereo audio.
Do you still need interprop comms as well as audio?
If so, I'm wondering if we can think about a protocol with more wires - something like RS232 with RTS and CTS as well. The group 2 could be doing the data comms, and when there is a screen refresh, it sets CTS high so the other prop knows not to send during those times. The serial drivers have buffers.
We can add more serial ports. Serial to MIDI is easy too.
Addit:
See attached schematic. I think this gives you stereo sound at the same time as the display.
Tell me more about SPDIF. I see there are objects in the obex. What does the physical connector look like? Is it just a led. Is this a two way comms protocol?
Alesis ADATs *industry standard audio recorders* use a form of TosLink that has 8 channels. I would like to study a bit more but having 8 digital channels would be AWESOME! http://en.wikipedia.org/wiki/ADAT_Lightpipe
I need to check on pins 22 and 23 but they should work? From my understanding, it would be best not to use two consecutive pins. I have heard rumors the 40-pin props are less susceptible to noise. I plan on doing quite extensive audio testing over the next few months. I do think staying in the digital domain is the best and easiest way to get audio out of the prop. This adds some complexity but that is usually the case in superior methods.
Now have a text keyboard working. Landscape is better than portrait - keys are bigger so you can type with few mistakes. So, why not a music keyboard and a wavetable synth?
All good fun!
PUB Keyboard | capslock, backspace,xval,yval,address,ascii Clearscreen(0) ' clear the screen SetOrientation(false) ' landscape view ILIloadfont(string("Arial30.ifn")) ' load this font RawSDToDisplay(string("KeyL.raw")) ' load this picture capslock := 0 ' default to off ' caps lock backspace := 0 'default to off ' backspace is zero str.builtstring(true) ' clear the working string SelectSPIGroup ' talk to the spi touchscreen ILISetcursor(margin,27) ' cursor to top left repeat xval := TouchValue >> 8 ' decode yval 0-100% and swap x and y as this is landscape mode yval := TouchValue & 255 ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress SelectMemGroup ' displaying now address :=255 ascii := 255 xval := (xval * 32) / 10 ' scale to pixels as can measure off the picture yval := 240 - ((yval * 24) / 10) ' scale to pixels and org top left case yval 133..162:address := xval / 32 ' top row qwertyuiop 163..188:address := 10 + ((xval-17) / 32) ' second row addres 10 up, offset 189..214:address := 19 + ((xval -47) / 32) ' third row, includes two buttons in one if xval<47 address := 255 ' non printing character capslock !capslock ' toggle capslock if xval >273 !backspace ' backspace character 215..239:if xval >64 and xval < 256 address := 26 ' space bar if xval>256 address :=27 ' carriage return (LF added below) if address < 255 and backspace == 0 ascii := lookupz(address: "Q","W","E","R","T","Y","U","I","O","P","A","S","D","F","G","H","J","K","L","Z","X","C","V","B","N","M",32,13) if (capslock == 0) and (ascii => 65) and (ascii =< 90) ascii += 32 ' lower case curx := ILIChar(ascii,curx,cury) ' only print if a valid ascii character str.buildstring(ascii) if ascii == 13 ' add line feed if this is a return ascii := 10 ' add LF curx := ILIChar(ascii,curx,cury) ' display line feed str.buildstring(ascii) ' and add to the built string if backspace <>0 ' backspace redraws the entire string buffer backspace := 0 ' backspace now zero str.buildstring(8) ' kye's string routine removes a character ClearFontBackground(0,22,319,132) ' clear an area the same color as the font background ILISetcursor(margin,27) ' top left of the screen ILIPrintstring(str.builtstring(false)) ' redraw text if xval => 0 and xval <45 and yval => 0 and yval <21 return ' cancel button if xval => 280 and xval < 320 and yval => 0 and yval <21 result := str.builtstring(true) ' the 'send' button returns the string including carriage return, line feeds (can do multiple lines of input) return pause1ms(250) ' debounce SelectSPIGroup ' wait for next keypressAdded a slider knob. @average joe, I think you were wanting these for controlling a synth, right?
[video=youtube_share;JRg1-_EnwwM]
PUB Slider | Percent,startx,starty,xval,yval Clearscreen(%00000000_00000000) ' background LoadSmallPicture(string("SlideBck.raw"),36,92,Pic1) ' size determined by paint shop pro, original bmp file (.raw loses the size data) LoadSmallPicture(string("SlideKnb.raw"),27,19,Pic2) ' slider knob startx:=100 ' location of the slider starty:=100 percent := 50 ' start percentage DrawSmallPicture(startx,starty,36,92,Pic1) ' size determined from original picture DrawSmallPicture(startx+5,starty+3+(percent*67/100),27,19,Pic2) ' scale for this particular slider image repeat until (yval >80 and yval<100) ' exit condition hit anywhere in the top of the screen SelectSPIGroup yval := TouchValue >> 8 ' decode yval 0-100% xval := TouchValue & 255 ' decode xval 0-100% if (xval <> 255) and (yval <> 255) ' valid keypress SelectMemGroup percent := (yval-30)*400/100 ' offset and scale if percent <0 ' make sure in range 0-100 percent :=0 if percent >100 percent :=100 DrawSmallPicture(startx,starty,36,92,Pic1) ' size determined from original picture DrawSmallPicture(startx+5,starty+3+(percent*67/100),27,19,Pic2) ' scale for this particular slider image pause1ms(10) ' small pauseAlso can you take a look at this schematic. I've taken on board the comments about going in different directions and I don't want to take it too far from something you are going to use. I guess it helps keep me grounded to building useful things. Plus, when I was a kid I spent all my pocket money for years trying to build a synthesizer. There is enough now on this board to make a software one. All the existing objects in the obex. A display. Stereo sound. Mass storage of sounds and pictures. The serial port can be turned into a midi port with just a few components. You can also stack another board on this and select this board with the 237 and get another 22 general purpose pins.
On the schematic I also added weak (100k) pullups to pins so that during the handover between groups of pins, the cog or the spin program does a dira:=0 and the default position is all groups deselected. So during a handover there is no chance of data clashes and pins being left over as outputs going into other outputs.
One thing that slider video demonstrates behind the scenes is flipping quickly between display mode and touchscreen mode. These are actually using different groups of pins (or to be more precise, they are both using the *same* propeller pins), so the handover back and forth needs to be seamless. Read the touchscreen, update the display, and repeat. There is even a 10ms delay loop in there which probably does not need to be there (the loop runs even faster than that). So you can think about looping between multiple groups. eg you could devote 22 propeller pins to reading footpedals, to reading drumpads etc. Then check the touchscreen. Then update the display. A full screen redraw is 30ms but just redrawing a bit of the screen is proportionally faster. So if there was a 10ms delay between hitting a drumpad and sound coming out of the speakers, would this be acceptable?
Re sliders, that is so much nicer than what I'm using now. Those should work quite nicely for controlling synths.
Re schematic. I took a quick glance but I'm honestly too tired to think, plus I have that brain thing... I will study it closely tomorrow and let you know my conclusion.
I totally understand not wanting to take it too far from what I'm working on. I would hazard to say this device should work as an entry level synth. A pro-sumer device would need some expansion and a second screen wouldn't hurt, along with some physical buttons and knobs. I've been thinking quite a bit about a full-blown professional synth and working on design requirements. Should have a basic idea in the next few months. I do think this board should be quite capable.
Now 10ms latency for a drum pad is PROBABLY noticeable. 5ms is PROBABLY about right and faster would be better. I know 10ms is SMALL and the entry to average level musician probably wouldn't notice. I, however, get very frustrated trying to play something with 10ms latency. My ASIO driver and software package allows latency compensation and right now I have about 3ms latency. Not noticeable at all. If I nudge it up to 5ms I can start to "feel" it and at 10ms it's practically impossible to play. I am very picky however. Most people are not quite so picky.
I do need to think on the latency a bit more and I will also do a small sample of my musician friends to find out what they actually notice and what they find un-playable. I would hazard a guess @ 7ms and 15-20ms respectively. It will be interesting to find out!
I will get some more info to you shortly. A couple more quick posts and it's bedtime! Keep up the great work!
Yea, Doc seems to be a very friendly, intelligent, and helpful person, which is definitely a huge asset to the forum. As this thread progresses, I just wonder where he is headed with this technology he is creating.
Could it all just be an experiment? I venture to guess a phone interface.
Bruce
What I really want to send to average joe is a PCB board, but the design keeps changing. The board I am using has too many wire links. There are two more recent designs on the way from the fab house and those are closer to the mark. Jazzed's idea of more formally having groups of pins has ended up making the design a lot simpler to think about. And there is the latest design which still I think needs a bit of work to make it into an audio synth. Getting close though.
Those comments about timing delays are extremely useful. I think this might be a situation where the multiple core part of the propeller comes to the rescue.
Ok - general concept - board design, audio, some pins doing video, and some inputs. The video is using too many pins. But... I have an idea. How about we use the I2C bus for all the inputs like drumpads and pots?
There are a wide range of I2C devices. Some, like the MCP23008/MCP23016 can (I think) even be set up so their pins act as interrupt inputs. So you could be reading the time critical inputs with those pins, and then less frequently you could be polling the A to D chips on the I2C bus for pot changes.
Any inputs from the I2C bus go to some hub ram locations, and then an audio cog reads them off the hub. Should get delays down under a millisecond?
So that part runs completely indepenently of the display. The display can be reading the same hub locations but that is less time critical. The display could even do clever things like detect a pot has moved, and bring up a new screen showing what the pot does, and then you can have a small number of pots doing a lot more things (my synth I built when I was 13 ultimately failed because there were so many pots that wires were falling off).
Another idea - say we have a generic board like the design we are working on plus some I2C i/o. You could have two of these boards, same board design, but doing different things. Communicate with the serial pins but that is not so time critical.
Though I still think it is worth trying to do a one propeller solution.
I've wondered sometimes if there is a physical standard for an I2C bus? And if not, how about a 6 pin header, 2 pins for the bus, and bring out Gnd, 3V and 5V and 12V and that should be enough to run lots of peripherals. Then think about a series of small boards, maybe just a MCP23008 and some sort of standard musical sockets (stereo 6.5mm plugs, RCA etc) so you can interface to other equipment. Daisy chain those boards which should work as long as there is not a long run (I2C is a 'local' comms system). Maybe some sort of DIN plug instead of a header? Addit - http://www.nxp.com/documents/data_sheet/P82B715.pdf I2C bus extender could be very useful.
It might mean we don't have to keep redesigning the main board.
@idbruce
I'm not entirely sure where it is going, but I think it can do more and more things an android phone or an iphone can do. And for less cost. And it can do other things that are more real world oriented. I'm thinking of a board that can be a synthesizer one day, and the next day can be controlling your quad copter. Fast real-time response is critical for both of these, and I think that little demo with the slider on the display shows it is very much real time now. (much faster than the original 9 seconds for a screen refresh!). I'd like to get a board design that is good enough and flexible enough that we can get some others contributing.
Like I have said before, "Go Doctor Go"
If average joe wants lots of inputs running in real time, I think the I2C bus is the answer.
But - I was using one of the I2C pins to control the pin groups. Hmm - that won't work. I checked the I2C bus specs again and according to what they say, you can't toggle either clk or data. Both have special meanings in the I2C world.
So - that means another prop pin. I think we can use P21 here. That means one less pin in the selectable groups, but I think we can live with that, as the ILIreset is only ever run once at bootup. So that can be toggled by a different pin group.
So - now there are P0-P20 = 21 pins in 7 groups (still a lot of spare pins there, I'm only using 52 out of 147).
I also thought I might bring out the I2C bus on a 6 pin header. Some intriguing circuits out there on the internet that can extend the wire length, even an optocoupled I2C isolator. So in general terms the I2C bus can talk to drum pads and slider pots and real world things like that.
Or if time is not so super critical (30ms or so, ie max time for a screen refresh), you can always use those propeller pins that are spare. Some things in music I presume are not so time critical, eg adjusting the Attack/Decay/Sustain/Release pots.
I started wiring up the breadboards this morning and all I can say is Thank You! *I can't say that enough!* My life is SO much easier now that I have the proper bread boarding tools to work with. Should speed up prototyping time exponentially.
Also, the R2R ladders just made me smile! I have been wanting to score a couple of these for testing for a while now.
*edit*
I have an android phone and have played with using it as a controller. There are some great free apps, but they require installing MORE software. *rolls eyes* Even with a 2ghz dual-core snapdragon processor and half a gig of memory, it is still slow IMO.
BTW, the 9 second screen refresh had more to do with me using the display wrong than anything else.
I'm still learning about I2C but it has a lot of potential.
re Android phones, I have an android 7" "pandapad" and I've written a few programs for it. One nice thing is wireless downloading with wifi. Development in Basic http://www.basic4ppc.com/forum/ However it is a bit slow to download and run. I have a few problems with Android though. No real world I/O. The device gets hot. And if it hangs and you need to do a reset and the reset process takes a long time and needs human intervention to get the program running again. Not something that is very practical on a quadcopter for instance.
So if that board looks ok maybe we can think about which I2C chips to use. MCP23008 I think is already in the obex. There are probably others in there too for A to D and D to A.
I2C has some very nice looking chips indeed. I'm not real familiar with the protocall as I have said, but I have looked at a few different chips from time to time. I always end up using spi instead.
The pandapad is very nice. I've been wanting a tablet to use as a midi controller. My HTC Incredible is a very nice phone, although I have no wireless coverage. I use gvoice and a few workarounds to have a wifi-only phone with poor quality. Thank my ISP for being lame.. When I use free wifi connections, like @Starbucks I get great quality. A few of the free apps I've played with for control surfaces are "FingerPlay" "touchDAW" *which I broke the other day? "Control v1.31" *my favorite. These take quite a bit of setup to use with the computer.
Ableton Live is a very nice program, but very expensive. Propellerhead's Reason is another very nice piece of software too. Also very expensive.. These are the programs I use for music production, but I'm looking for free alternatives for "Open Development" I'm not having any luck finding anything I like.
I have some `32's so that's not a problem but I don't think I have a `237. I'm going to Reno on Wednesday so I will make a list for the Sandy's Electronics.
The MCP23008 should work good for mux I2C bus. I don't have one but I think I have a workaround for now. Chip order will have to wait a while since I spent a bunch of money to go to the Expo.
Now, re the schematic. Here's my though after some close examination.
Swap Pins 19,20 on counter Load,Clock.
Move iliWr to Pin 20 if necessary.
Move AudioL to Pin 21
Move demux 4&6 to Pin 22 *was Pin21*
I can't promise this would be best, but all the hints point to this being the best pinout. So from my understanding, pin23 should be effectively shielded on one side by the supply. By moving AudioL to non-adjacent pin we can reduce crosstalk. Keeping the surrounding pins at lower clocks will help keep noise gremlins at bay as well. This is the reason for swapping pins 19,20. The cog layout may come into play at this point. I still come back to the though that this may not be of huge issue if we use SPIDIF out. We also get audio in as well this way. The only problem is you can't plug it directly into most speakers. So I keep going back and forth. Probably better to design for analog out. Worst-Case design and all that.. Just some things to think about.
Now you got me thinking about drum pads and keys and physical input schemes. I've played with using anti-static foam for weight/pressure sensors before. Makes me wonder what the best DIY method would be to have 16 TOUCH SENSITIVE pads. I was also wondering about a one-octave, touch sensitive, keyboard. They don't have to be "perfect" just a better solution than spending $60 bucks for each. I'm thinking of keeping this completely accessible to the "DIY synth" community.
Adapting the basic design to flying quad-copters wouldn't be too hard. A couple xBees, antennas, Maybe an RF amp? Makes me wonder...
Well every week brings more homework, so I will get back to you after that is done.
*edit*
I was just wondering, other than bit-banging, what would be the best way to do usb?
Excellent suggestions. I've made all the changes, see attached schematic.
Isn't this cool - a collaborative effort half a world apart?!
I just thought of something, say the audio is too noisy, well then take just one channel of the audio output say the left one, leave out the capacitor, leave in the 1k resistor, plug in a stereo plug and wire a led across the left channel inside the stereo plug and you have an SPDIF output. And use the other channel as audio in? Then just change the software. So that gives flexibility with both solutions.
This is quite exciting, working on a project with someone on the other side of the world. Very cool!
Coax to optical http://www.amazon.com/Digital-Coaxial-Toslink-Optical-Converter/dp/B001622FL8/ref=pd_cp_e_1 and optical to coax http://www.amazon.com/Digital-Optical-Toslink-Coaxial-Converter/dp/B000I98ZQY
So if you did want to do this, make up a 3 pin stereo plug to a RCA plug, and maybe there is a resistor or two inside that plug to divide the voltage down. I think there are circuits around for SPDIF to TTL and vice versa.
Anyway, I think this can be done off the board with other circuits so it shouldn't affect the board design. It would be cool to select between analog and SPDIF by touching an icon on the screen. Though the capacitor on the audio circuit might be a problem so ? a jumper next to each of those caps. Or would you just bring the pins out with no resistor or capacitor and then do the RC or R/R off board?