Older PIC16F firmware vs newer MIOS/PIC18F application capabilities

[alanjcastonguay]

I am in the planning stages for my own mios-based controller for Ableton Live. There are several points which I am slightly unsure of, and the available documentation doesn't appear to clearly answer these in a definite manner.

1. Would I be correct in assuming that MIOS and PIC18F452 support all of 128 digital inputs, 128 digital outputs, and 64 analog inputs at the same time? It appears that the pre-mios PIC16F877 applications such as MidiBox64 and MidiBox64E had various restrictions on the number and type of inputs, and the MIOS-based re-implementations of these applications (64 and 64E) carried those restrictions forward (like MB64E not supporting AIN), even though the underlying hardware and OS no longer carry those restrictions. It appears this was done to maintain pin-computability between an old PIC16F programmed with 64E firmware and a new PIC18F with the new 64E firmware. Thus, one can create a new MIOS-based application  using either C or asm without those artificial restrictions, and make full use of the features provided by MIOS and the PIC18F. Am I correct in my understanding? Is an example of such an application?

2. Digital inputs appear primed to handle single momentary-contact pushbutton switches, or pairs in rotary encoders or data wheels, which are tied internally to virtual pots. Analog inputs are geared to handle pots with absolute values 0-127. Is it possible to group more than 2 (probably consecutive) digital inputs to input some larger absolute value to a Virtual Pot? As in, instead of using a DAC <-> ADC combination to glue two pieces of purely digital equipment (with common vcc and gnd) together just to get a 0-127 value between them, I would prefer to provide output from digital_source on an 7-wire bus conveying a binary-encoded number 0-127 which is accepted directly by a DIN, and interpreted as above by MIOS. What provision for such inputing data with such an encoding over DIN is provided?

3. Is a complete list of the standard Logic/Mackie Control mappings available somewhere?

4. Are jog wheels (or datawheels) usually implemented the same as other rotary encoders (2 DIN lines, one pulsed for increment, one pulsed for decrement)?

Please post a url to required reading or liberally correct any mis-assumptions I am making.

[stryd_one]

2. Digital inputs appear primed to handle single momentary-contact pushbutton switches, or pairs in rotary encoders or data wheels, which are tied internally to virtual pots. Analog inputs are geared to handle pots with absolute values 0-127. Is it possible to group more than 2 (probably consecutive) digital inputs to input some larger absolute value to a Virtual Pot? As in, instead of using a DAC <-> ADC combination to glue two pieces of purely digital equipment (with common vcc and gnd) together just to get a 0-127 value between them, I would prefer to provide output from digital_source on an 7-wire bus conveying a binary-encoded number 0-127 which is accepted directly by a DIN, and interpreted as above by MIOS. What provision for such inputing data with such an encoding over DIN is provided?

4. Are jog wheels (or datawheels) usually implemented the same as other rotary encoders (2 DIN lines, one pulsed for increment, one pulsed for decrement)?

Hey welcome to the board!

2) You can combine the values in software. What did you have in mind?

4) Yep

:)

[TK.]

Hi,

First I must say, that I'm happy about the fact, that you've looked into the ucapps.de website before asking these questions. I can read this between the lines, and I think it must be highlighted, because most people just ignore the existiting documentation (thus I mostly don't feel motivated to bring it up-to-date)

Would I be correct in assuming that MIOS and PIC18F452 support all of 128 digital inputs, 128 digital outputs, and 64 analog inputs at the same time?

yes, thats correct. The ain64_din128_dout128 application demonstrates these capabilities.

This is just a simple example application, but it works sufficient so long your PC software is able to "learn" MIDI events.

It appears that the pre-mios PIC16F877 applications such as MidiBox64 and MidiBox64E had various restrictions on the number and type of inputs, and the MIOS-based re-implementations of these applications (64 and 64E) carried those restrictions forward (like MB64E not supporting AIN), even though the underlying hardware and OS no longer carry those restrictions.

thats partly correct. The restrictions exist, because I wanted to prevent an update of existing tools (not written by myself).

But in general it's possible to write a new application which gets use of all capabilities provided by MIOS. A lot of combinations are possible, and I hope that sooner or later the users will provide their fully customizated controllers to the community.

(like MB64E not supporting AIN)

there is a hidden feature in the MB64E application which allows you to get use of the AINs, as well of the motorfader feature (see ChangeLog and comments in main.asm file)

Thus, one can create a new MIOS-based application  using either C or asm without those artificial restrictions, and make full use of the features provided by MIOS and the PIC18F. Am I correct in my understanding? Is  an example of such an application?

Exactly!

2. Digital inputs appear primed to handle single momentary-contact pushbutton switches, or pairs in rotary encoders or data wheels, which are tied internally to virtual pots. Analog inputs are geared to handle pots with absolute values 0-127

(with MIOS 0-1023: 10 bit resolution)

Is it possible to group more than 2 (probably consecutive) digital inputs to input some larger absolute value to a Virtual Pot? As in, instead of using a DAC <-> ADC combination to glue two pieces of purely digital equipment (with common vcc and gnd) together just to get a 0-127 value between them, I would prefer to provide output from digital_source on an 7-wire bus conveying a binary-encoded number 0-127 which is accepted directly by a DIN, and interpreted as above by MIOS. What provision for such inputing data with such an encoding over DIN is provided?

In general you have to take into account, that the serial DIN chain is scanned each millisecond. This is fast enough for buttons/switches/encoders, since the resulting reaction (normaly a MIDI event) isn't much faster (the transfer of a 3-byte MIDI event takes 960 uS).

So, your question is a little bit too abstract. What kind of data do you want to handle with the DIN pins exactly? How fast does it change?

3. Is a complete list of the standard Logic/Mackie Control mappings available somewhere?

Yes, this page http://www.midibox.org/dokuwiki/doku.php?id=midiboxlc contains a link to the Logic Control spec

4. Are jog wheels (or datawheels) usually implemented the same as other rotary encoders (2 DIN lines, one pulsed for increment, one pulsed for decrement)?

yes, but I must say, that these terms are mixed very often in MIDI controller specs. Even in the MIDIbox LC application, I've called the rotary encoder "Jog wheel" to keep it aligned with the Logic Control spec.

Normaly it should be differed between a jog wheel, which is just a multi-state switch, and datawheels/rotary encoders, which are techically called "quadrature encoders".

Best Regards, Thorsten.

[alanjcastonguay]

Thanks for the clarification, Thorsten.

Hey welcome to the board!

2) You can combine the values in software. What did you have in mind?

4) Yep

:)

Thanks for the welcome.

2) I plan to utilize an Alps touchpad 808-874649-002-A as an X/Y controller. It outputs trackpad data in accordance with the PS/2 protocol. Rather than burden MIOS with interpreting the PS/2 data, I was going to write a handler into another dedicated microcontroller. Specifically, an Atmel AVR microcontroller (chosen because I have experience writing assembly for it). This microcontroller will buffer the incoming PS/2 data, decode the absolute X and Y coordinates, and make available on its outputs two 7-bit numbers corresponding to the X and Y coordinates last touched. I think that the inbound data should map to a pair of virtual pots.

In general you have to take into account, that the serial DIN chain is scanned each millisecond. This is fast enough for buttons/switches/encoders, since the resulting reaction (normaly a MIDI event) isn't much faster (the transfer of a 3-byte MIDI event takes 960 uS). So, your question is a little bit too abstract. What kind of data do you want to handle with the DIN pins exactly? How fast does it change?

The data on those 7x2 lines is not going to change at a faster rate than someone can swing their fingers over the X/Y pad, and missed information (aka, PIC reads value d[0] on first pass, data available is updated to d[1] between passes, and PIC reads value d[3] on second pass) is of no concern, as there wouldn't be enough time to push that data over midi anyway. It would be a concern were the pad to be put in relative mode, and expected to link to a relatively-positioned vpot. As it is, I think it makes more sense to just override any associated value already assigned to the vpot.

The only issue I'm struggling with is how to avoid the (rare, but bad) situation where one device is updating the state and the other reading, resulting in mismatched chunks of data, and thus wildly swinging data errors. Updating the output registers in a synchronous fashion would solve this. To that end, I propose flipping the data over to the AVR's output registers when RC on J1 on the DIN goes active, using an hardware interrupt in the AVR. At present, I am not sure how much latency this would add.

I suppose I could instead replace the last two 74HC165's with a direct connection to the AVR chip, and shift out the last 2 bytes of DIN-age myself, but this would require the other microcontroller to keep pace. However, as I don't really care about the cost of extra 74HC165 shift registers (cheap as dirt), and the smallest AVR chips I have on-hand are going to have at least 16 free output pins, there's no significant advantage to providing a direct serial shift interface to the data other than pretty-ness.

I think that using another processor to pre-cook the input ps/2 data makes sense, and providing the data in a form that the PIC18F can sample whenever it feels like doing so significantly simplifies implementation.

edit:

Yes, this page http://www.midibox.org/dokuwiki/doku.php?id=midiboxlc contains a link to the Logic Control spec

The midi implementation detail in that older manual is simply perfect. Gracias.

[TK.]

Short answer: an even more powerful method is the use of the I2C protocol. In the last days I've worked out just another demonstrator, which shows, that this protocol is not only useful for accessing EEPROMs and LCDs from a MIOS core, but also to exchance data with other microcontrollers (see http://www.ucapps.de/mbhp/mbhp_iic_midi.pdf and http://www.ucapps.de/mbhp/mbhp_iic_midi_preview.jpg - this is a II<->MIDI bridge which allows to control multiple MIDI interfaces from a "master" core via I2C

I will write some documentation and especially programming examples to this project after my holidays. In the meantime you could work on the I2C slave routines for Atmel (for PIC I can provide a tested template) - MIOS already provides MIOS_IIC_* functions for I2C master accesses (an OS change is not required)

Another hint: Duggle has worked out a PIC based application for PS/2->MIDI some time ago, you could contact him in order to prevent double-effort. I think that a modification for PS/2<->I2C isn't that difficult

Best Regards, Thorsten.

[stryd_one]

2) I plan to utilize an Alps touchpad 808-874649-002-A as an X/Y controller. It outputs trackpad data in accordance with the PS/2 protocol. Rather than burden MIOS with interpreting the PS/2 data, I was going to write a handler into another dedicated microcontroller.

Someone did write a PS2 interface for MIOS once... At least it was talked about... Anyone know if it was finished??

[johnh]

First I must say, that I'm happy about the fact, that you've looked into the ucapps.de website before asking these questions. I can read this between the lines, and I think it must be highlighted, because most people just ignore the existiting documentation (thus I mostly don't feel motivated to bring it up-to-date)

Hey, I read ucapps.de often!  :)  Some of us value the information there!!!  ;D

[alanjcastonguay]

First thing I did after registering this account was to send Duggle a PM. I havn't heard anything back, nor can I find evidence on the forum that a finished solution was published.

Thorsten, are those PIC16F88's just forwarding all data they recieve down the line, with J3 being the I2C interconnect?

[TK.]

Thorsten, are those PIC16F88's just forwarding all data they recieve down the line, with J3 being the I2C interconnect?

No, they "prepare" the incoming data in form of packages, the master has to poll for updates. This is a complex topic which cannot be explained in a few number of lines (therefore: please wait for the documentation). There is a I2C specification available on the Philips website which helps to understand the common approach

Best Regards, Thorsten.

[alanjcastonguay]

Back to one of the first questions for clarification;

yes, thats correct. The ain64_din128_dout128 application demonstrates these capabilities.

This is just a simple example application, but it works sufficient so long your PC software is able to "learn" MIDI events.

Those 64 ains, 128dins, 128douts are the limitations on (the handling of) the physical number of pins, right? Is there a higher limit to the number of virtual banked pots as well, or does the internal virtual controller max out at 64/128/128, with that example being intended for a full 1:1 mapping of physical to virtual pots/buttons?

[TK.]

Those 64 ains, 128dins, 128douts are the limitations on (the handling of) the physical number of pins, right?

yes

Is there a higher limit to the number of virtual banked pots as well,

this heavily depends on the memory consumption of the data structure which stores the "virtual" states/positions

or does the internal virtual controller max out at 64/128/128, with that example being intended for a full 1:1 mapping of physical to virtual pots/buttons?

The example is really simple (it should help to get a general understanding of the approach) and doesn't provide mapping.

Please note that this example exists twice, one assembly based version, and a C based version

Best Regards, Thorsten.