Pin allocation

[lylehaze]

In my MBMix application, I'm now using J10 for the PGA mixer chips, The code that drives the PGAs must disable interrupts while sending, so that MIOS can't scan J8 and J9, which share the RD3 pin, used as a shift clock (SC).

As a result, I cannot support larger arrays of PGA chips, because disabling interrupts for more than 250us may cause MIOS to lose incoming MIDI.

I also want to add drivers for new hardware like a Vinculum chip, and I will have to make sure that MIOS doesn't try to play with the pins I'm using.

Is there any approved method for asking MIOS to ignore stuff that isn't being used? If I could "take over" J5, I would have eight I/O pins that I'm not planning for anything else, as I have no need for AIN modules. I can re-configure them as digital and have my way with them, but only if MIOS won't fight back.

I could also move my MBMix hookups to J5 and then remove the IRQ_DISABLE so that larger PGA arrays can be supported.

If this is already documented, please point me in the right direction.

Thanks,

LyleHaze

[bugfight]

...As a result, I cannot support larger arrays of PGA chips, because disabling interrupts for more than 250us may cause MIOS to lose incoming MIDI.

you might try splitting your update into 2 sends...

...I could also move my MBMix hookups to J5 and then remove the IRQ_DISABLE so that larger PGA arrays can be supported.

If this is already documented, please point me in the right direction.

Thanks,

LyleHaze

this should work fine. just disable ain.

but it would be cool to combine motorfaders with a mixer...

there's a nice pin ref in the wiki...

[lylehaze]

Thanks!

updating in 2 parts (or more) would not work.

I can _pause_ in the middle of an update while MIOS handles it's needs, but if any of the pins I'm using are shared with MIOS functions, my update will be scrambled and the volume levels will go wack.(Hmm, could be fun!)

Since some folks want bigger PGA arrays, I really can't disable interrupts for the entire update, so I need to be sure that MIOS won't use my pins for anything else.

Regarding motorfaders, I'm not sure I see the need.

My first goal in the design was to have a mixer with no moving parts (especially pots). This means no opportunity for scratchy noise as it gets older. There are no real pots anywhere in the design of this mixer.

Now, if you want to build a control surface with motorfaders, and use that to control MBMixer, then absolutely! That would work great. but why put them in the same case, when you can get the advantage of splitting them with only a MIDI cable or two in between? Keeping the CS and the audio separate is one of the advantages of having a digitally controlled mixer. It just takes a little time to get your head around the difference.

Getting back to the topic, The other application I'm adding may also have delay times that might interfere with MIOS, so my need to have "private" IO that MIOS won't try to play with is probably the best way around this.

I'll look for info on disabling AIN.

Thanks,

LyleHaze

[Narwhal]

There is a module called j5_io that sets up the J5 pins to be inputs and/or outputs.

[lylehaze]

I'm still looking for better ways to solve this. I may have found something in the function reference.

The problem: I need to disable interrupts for slightly longer than a few bytes at MIDI_BAUD, so that MIOS will not try to scan DIN and DOUT while I'm transmitting. J10 shares pins with DIN and DOUT, as well as my hardware.

Disabling interrupts for more than one byte-time may cause a loss of data from MIDI_IN.

Perhaps a better solution:

Can I use MIOS_System_Suspend and MIOS_System_Resume instead of disabling interrupts? If I am correct, this will forbid IO scanning without locking out the serial port handler. Is this right?

Since my app makes very little use of DIN, and NO use of DOUTs, a few ms of delay is a much better option than giving up the analog ports.

Thanks,

Lyle

[TK.]

Can I use MIOS_System_Suspend and MIOS_System_Resume instead of disabling interrupts? If I am correct, this will forbid IO scanning without locking out the serial port handler. Is this right?

Yes, it could be used.

Alternatively, just use MIOS_SRIO_NumberSet(0) to disable SRIO accesses, and set it back to the original value to allow SRIO accesses again

Best Regards, Thorsten.

[lylehaze]

I made some progress.

I tried it my way, and the mixer died. No controls, no display, not good.

I must have been doing something inside that section that is shut down by MIOS_SystemSuspend.

So I tried it TK's way, now it works like a charm.

Thanks, TK!

(apparently this TK guy knows MIOS pretty well) :-)

This saves me from having to support alternate interface ports for those who want lots of PGA channels attached.

Happy Happy, back to software testing.

LyleHaze

[stryd_one]

Sweet.

FWIW, supporting other pins for connection is trivial. You just use a #DEFINE to specify the pins in the driver, wrapped in an IFNDEF. This means that if the pins are already defined elsewhere (say, in the makefile using a -D switch) then the definition is not overwritten, and the user-specified pins are used. So, if some dude wants to use J5, they specify the J5 pins in the makefile, and initialise the J5 port correctly in their app's init function.

Edit: an example would help:

driver sram.inc

#ifndef	SRAM_PORT_CS
#define	SRAM_PORT_CS			PORTA
#endif
#ifndef	SRAM_PIN_CS
#define	SRAM_PIN_CS				5
#endif

Sets the CS pin to the default (PORTA.RA5 in my case) driver sram.mk

# make rule for relocatable version
$(OUTDIR)/sram.o: $(MIOS_PATH)/modules/sram_512/sram.asm
	$(GPASM) $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) $(SRAM_DEFINES) $< -o $@

so that when the app builds the driver module, it passes the SRAM_DEFINES to GPASM (yep, works with native C drivers and SDCC too) app makefile

SRAM_DEFINES += -DSRAM_PORT_CS=PORTA
SRAM_DEFINES += -DSRAM_PIN_CS=6

Overrides the defaults shown above To PORTA.RA6

HTH!