Propeller and Address/Data busses

zero the hero

Hi to all, I'm new to the forum, so sorry if it has already been asked before.

I'm developing a music synthesizer based on the Propeller, and I'm new at multicore programming.
So far, I designed and built on a breadboard a basic circuit to test the I/O protocols I'm developing, and I would like to ask some questions to be sure I'm doing thisng right.

I planned to divide the tasks among the cores and so far there are three cores working on the interface:
- the first core acts as a display controller - there will be four 16x2 displays and one dot matrix graphic display
- the second core is the main interface controller, it controls the leds, reads and updates the status of the keys, reads an ADC for potentiometer and sets the address for potentiometer scanning (the ADC will read one pot per loop)
- the third one is fully used for controlling the sound chip (a Yamaha LSI)
- the main core starts and controls the other cores; shared memory locations are used for communication between cores, I used the Propeller guide as a reference for this part.

Every section has dedicated pins for driving the peripheral devices, and all the data is sent serially, ie the leds are driven by a lot of 74HC595, the keys are readed serially by 74HC165; even data for the displays, which have parallel interface, are sent serially with the same scheme used for led, a 74HC595 stores the D0/D7 values, and then the propeller directly manages the display number address and the Enable, Read/Write pins for each display.
I thought that this solution would be the correct one in order keep each core indipendent - every core uses its pins for data transfer - and there are no pauses in the execution of each core program, but I almost run out of available pins and this is a major issue, expecially in terms of expandability.
I think that classic Data/Address scheme (all leds, pots, keys, display, soundchips connected to the same data and address busses) would be very useful in term of pin counts, but I don't know if this design would be "Propeller-friendly" since all the cores will access the busses one at time, resembling time-shared processes of classic microcontrollers.

Does anybody faced this problem before? Which solution is best?
Later, I'll post some schematics I've drawn, in order to better explain the situation. Actually, there are about 70 leds, 40 pushbuttons, about 20 potentiometers, and I still have to implement MIDI in/out and a DAC for a voltage controlled filter... I would like to plan everything carefully!
The Propeller manual doesn't face this problem, and I would like to hear if there's a correct way of solving it.

Thanks!

Alessandro

Mike Green

One of the main advantages of the Propeller is, by using multiple cores, you can simplifiy the programming since each core takes on one task or type of tasks. When you start combining different tasks into one core, you complicate the programming. Similarly, when you share I/O pins among several different cores (cogs), you have to add locks (semaphores) to your program to prevent two or more cores from attempting to change the same I/O pins from two cores at the same time. If this isn't done properly, it's possible to lock up the program. Have you considered using two or more Propellers? One could manage all the displays, LEDs, and keys, maybe reading the pot settings as well and the other would be the "master" and do the other stuff. The two could communicate back and forth using serial I/O over two I/O pins.

Ahle2

Welcome to this fabulous forum Alessandro!

I'm interested to hear what kind of "Yamaha LSI" chip this is?
The Propeller is powerful enough to emulate many sound chips from the 80s in high quality.
I'm guessing that you are talking about a much more powerful sound chip though.

zero the hero

Thanks for your replies!
Actually, the Yamaha LSI is an ancient OPL2, the YM3812, and I plan to switch to the OPL3 soon. I would consider to move to more recent LSI, once I finish this project. I consider this work as a "homework" for multicore programming...

I never thought to use more than one microcontroller, I think that the Propeller is powerful enough for this synth; now I used just four cogs for the basic structure of the synth, I didn't mean to complicate the programming since tasks are actually divided by their function, for example, the second core does tasks which are similar; maybe, that's where I'm wrong, but isn't reading an 8 bit value from the ADC and reading 8 pushbutton both from two 74HCT164 something similar?

I think I'll work on optimizing pin usage, that's the only solution I thought in 3 weeks.

As soon as I put my hands on a scanner, I'll post some schems and code... I promise!

AntoineDoinel

Ciao omonimo, e benvenuto!

I believe both the HC165 (for input), and HC595 (for output) can be considered to be "quasi-SPI", so if you're reading pots from an SPI ADC, sure the two tasks can be considered similar.

When you say "the keys are read serially by 74HC165" you mean the keybed also or just the user I/O buttons?

If you're not yet familiar with Ahle2's work already, I'd suggest to look at the links in his signature. The single COG objects he made are register compatible with the original chips, and while there is no OPL2 it could still make sense to replace the OPL chip with another propeller (unless you're targeting 4op FM specifically).

Alessandro

kwinn

It is possible to share one set of serial I/O pins between several serial devices provided you can select the individual devices and have one cog do all of the serial communications for the rest. There are several approaches to doing this but they are fairly lengthy to explain so I will only do so if you are interested.

zero the hero

Thanks again, and ciao Ale!
Ahle2, these objects are fantastic! I'll take a closer look tonight. I was wondering too if a Propeller could emulate the OPL family since the only way of obtaining them is to disassemble old soundcards...

So, here we go!
Sorry for the bad quality, I took the pictures with a digital camera, but at least they are readable!
In the attached zip there are four pictures of the preliminary schematic (the one I tested on breadboard), a summary of the Propeller pin usage and a preliminary image of the panel.

Pic 1: Propeller, YM3812, audio DAC and output. The soundchip is hardwired to write mode (no register reading from it); data from D0 to D7 are serially shifted and latched on a 595, while RESET, A0 and CS pins are directly controlled by the uC.
Pic 2: 16x2 display controller. Again, data are shifted through a 595, displays are hardwired to write mode, uC controls the Data/Register pin and a 138 decodes the address enabling one display at the time.
Pic 3: Data input: a 165 reads and latches the button status, while another 165 stores the ADC result from the pot. I chose a ZN449D for this prototype for no reason. It was the only one I had at home... Serial data are shifted to P2 of the uC. There's a small pic which shows the data stream from/to P2.
Pic4: Data output. A 595 and a 138 select which pot should be read by the ADC. Several 595 are chained and configured as led driver.

The keys I was referring to, are actually pushbuttons, sorry. It will be a keyboardless module - for now.
There are 8/10 unused ports on the Propeller right now, I hope they will be enough!