midio128 customization

[John_W._Couvillon]

TK, Stryd_One,

Having read through the wiki details I'm still confused about altering, changing, adding code. If an APP using midio128 does not deal with encoders, pots, etc.  Is the applicatble code just deleted, Semi colon placed in front of the code lines, or what.  I did notice that on some apps, VOID was at the beginning of some of the lines of code, but I assume that was just for example purposes.

As a newbie to assembly code, it can be confusing, especially the more complicated code snipits. 

In my years of reading and posting on this forum, answers to questions have always been quick and thorough with sensitivity for those newbies that or short on background.  Personally, I would rather be told, "go read this or that, dumbie" rather then no comment at all.

Please don't leave those of us who struggle with  the software behind in the dust. 

Midibox with all of its ramifications has opened up many, many opportunities for me to learn new things.  I applaud your work TK and you to Stryd_one, and greatly appreciate what you have developed.

Thanks again,

Johnc

[John_W._Couvillon]

Anyone.

If you are using DIN4x with 128 input pins.  Will mios function MIOS_DIN_SRGet output a hex number that in binary form, represents the status of each of the 128 input pins?  The intent is to read the status of 128 input pins and save in the form of a number which can be recalled, transferred to the dout SR register and output to devices.  Output pin status to match original input pin status.

Or,  do you have to read the status of each DIN pin save to memory, then recall and set the Dout pin.

Hardware would be:

Input:

  1 din pin called  "set"

  117  maintained contact, on/off switches,  one per DIN pin.

  10  momentary contact on/off switches.

Output: 

  127  Magnet coil drivers, ULN2803

Program sequence:

1.  "set" input starts cycle

2.  117 input maintained contact sw's are set in random pattern.

3.    Program has 10 memory levels, each capable of storeing a hex number, which when retrieved from memory by one of the 10 momentary switches returns the stored switch pattern  sets the appropriate pins in the dout  and outputs to the receiving magnet coils.

Each of the ten levels can have different arrangements stored.

Perhaps there is a macro or code segment already written that can perform this function.

Your help will be appreciated.

Thanks,

Johnc

[stryd_one]

If an APP using midio128 does not deal with encoders, pots, etc.  Is the applicatble code just deleted, Semi colon placed in front of the code lines, or what.

It's just not there :) midio128 is an app itself, and it only includes the very basic code needed to handle digital inputs and outputs. Anything beyond that (like encoders etc) needs to be added in by you.

I did notice that on some apps, VOID was at the beginning of some of the lines of code

Those will be C apps - that line is there to specify the type of value that the function will return.

For a highly simplified example, let's say I have a function to write a variable to a bankstick. The function can be called "WritetoBS", the variable we write could be an 8-bit value - known as an "unsigned char" in C terminology. We could define the function like so:

void WritetoBS(unsigned char myVariable) {     // this says 'void' which means this function does not return anything, it just does what it's told and that's all

// your code goes here

// in C, lines starting with "//" are comments - they are just for humans to read, and ignored by the compiler
// just like a semicolon in assembly

/* with most compilers, you can also start a comment section like this
and then everything after it is a comment
until you close the comment section like this */

}

Then you can use that function to write your variable like this:

WritetoBS(123);

Now this is all well and good, but, what if the write to the bankstick fails? It would be nice if your application were aware of it, so that it could retry, or notify the user or something, right?... well to do this, we can use a return value. In that case, we could define the function as so:

unsigned char WritetoBS(unsigned char myVariable) {     // note that this function returns an unsigned char
// your code goes here

// we will somehow determine the success of the write to the bankstick
// and we will set a variable called 'writefailed' accordingly
// so that we can use it like this:

    if (writefailed == 1) {
        return 1;     // this is where we return the value to the caller. it's 1 if something failed...
    } else {
        return 0;     // ...and it's 0 if everything went OK
    }

}

Now we can call this function like so:

thereWasAnError = WritetoBS(123); // this function will now know, whether the write to bankstick function was successful
if (thereWasAnError) then doErrorHandling(); // and if it failed, it can do some error handling

Personally, I would rather be told, "go read this or that, dumbie" rather then no comment at all. Please don't leave those of us who struggle with  the software behind in the dust. 

Sorry you had to wait... real life is kicking my ass right now. You can be sure, that if you get my attention like you did, you'll get an answer... sometimes it might just take a while. Of course you can feel free to give me a friendly reminder if it seems like I have forgotten you, as sometimes my memory fails, and even more often, my PC that arranges my schedule fails too ;)

Midibox with all of its ramifications has opened up many, many opportunities for me to learn new things.  I applaud your work TK and you to Stryd_one, and greatly appreciate what you have developed.

You're very kind, but I'm just a janitor :) TK gets all the credit here. Although, it is tempting to try and bask in his glory ;)

If you are using DIN4x with 128 input pins.  Will mios function MIOS_DIN_SRGet output a hex number that in binary form, represents the status of each of the 128 input pins?

It will only return the number that represents the state of 8 pins == one Shift Register == DINx1.

The intent is to read the status of 128 input pins and save in the form of a number which can be recalled, transferred to the dout SR register and output to devices.  Output pin status to match original input pin status.

You can do this easily with a for loop in C, somethng like so: (pseudocode, check it first for errors!)

unsigned char DIN_States[NUM_DINS];     // declare an array to hold the DIN pin states. Do this in your header file, or at the top of your C file, not inside a function where it would be temporary! NUM_DINS is a #define which tells the app how many pins you use. In your case, it would be 128.

....
....

// here is your function to read all the pins
unsigned char counter; // a declaration
for (counter = 0, counter < NUM_DINS; counter++) {     // do the below until you have all the pin values
DIN_States[counter] = MIOS_DIN_SRGet(counter);     // store a SR's pin states in your array
}

However, that's just one way to do it. You could also use the USER_DIN_NotifyToggle() functions, to set only the pins you change, rather than all of them, which could be better for performance. It really depends on what you need....

Does that help at all?

[John_W._Couvillon]

Stryd_on,

Thanks so much for the reply.

Although I am not into "C",  I can follow your answers and examples, I'm incouraged by what I read and am confident that What I am attempting to do, can be done.

Personally,  I have spent much more time reading, following and getting to know assembly and can work my way through the code pretty well.  Mios is again another story.  I guess that I have two problems,  Understanding mios, how it is structured and what a complete application has to contain, and the detailed code to implement the app.  I keep looking for the main block of code that dictates the program loop and keeps the cycle going. My conclusion is that the Main. inc is now where that takes place.  Everything that happens is a spin off, sub routine, whatever from main.inc.

As a start,  I am looking to use midio128 with minimum change to the default, out of the box application.  However, knowing that some of the code won't apply, to simplify things, why not just delete that part of the code.  If the call to the routine, subroutine etc., is not there, then it won't be included in the program. Other reasons for staying with MIOS and midio128, is that there may be a need in the future to include other typical features found on a pipe organ console, and from my reading, the basic routines needed are already included in mios. 

Sorry about the duplicated posts, and the length therein.  I am interested in your comments as well as those of TK concerning this application.  Actually,  I truly believe that a combination/capture action application using mios and midio128 could have as big an impact on use of midibox as the original app for the Orchestron (sp) that started the ball rolling with midio128.  Existing commercial systems that perform the same functions start in the $5,000 to $10,000 range.

Thanks again, and I look forward to your reply.

Johnc

[stryd_one]

I keep looking for the main block of code that dictates the program loop and keeps the cycle going. My conclusion is that the Main. inc is now where that takes place.  Everything that happens is a spin off, sub routine, whatever from main.inc.

That's pretty much right... In fact, the mainloop is in MIOS itself, and not the application. You don't really need to be concerned with MIOS, it 'just works' (like when writing an app for windows, you don't need to know about window's source code). Instead, the functionality you need is exposed via a handful of functions, which are the ones you can see in the application's main.inc (or main.asm / main.c in the skeletons, etc). The comments in those files explain what those hooks do; and you can combine them with the stuff from the function reference to make up your own app - or modification of an existing app of course :)

[John_W._Couvillon]

Hey thats great! The fog is lifting.

So I could write an app called "comb_action.inc" to do the capture/combination action functions, and put a hook in the main.inc program to get to it, eh?  If I wanted to use one of the existing DIN or DOUT pins that are available on the pic as a dedicated I/O, is that permisable.

One last question, Will mios run an app that utilizes only the DIN and DOUT pins on the pic with appropriate code, no shift registers, etc.? 

Thanks loads!

Johnc

[lylehaze]

Hi John,

All your DIN and DOUT modules use shift registers to communicate with the core.

This lets you get a LOT of IO from a few core pins. If you are looking for a hundred

odd inputs and a hundred-odd outputs from a single core, you NEED those shift registers to make it happen.

Enough preaching. Yeah, if you aren't using DIN or DOUT modules and you want to get those pins for your private use, you can call MIOS_SRIO_NumberSet with a value of Zero, and MIOS will stop scanning DIN and DOUT signals.

That's what I needed for the MBMixer, and the thread we discussed it in is:

http://www.midibox.org/forum/index.php/topic,11977.0.html

Once that is done, you can re-assign pins as inputs or outputs with TRIS registers, and read the pin values directly from the PORT registers, or set output states from the LATCH registers. This is all straight PIC ASM code.

At least, that's how I understand it.. If I've got it wrong, smarter people will step in and correct me.

Have Fun,

LyleHaze

[John_W._Couvillon]

Lylehaze,

Thanks for the input.  Yes, I agree and for this project all of the 128 inputs and outputs will be needed. Just wanted to know if it was legal to do that.  Evidently,  from you reply, you have to go one way or the other, not both ways at the same time.

I will look at the url ref. you provided. Hope you won't mind my asking some questions later.

Thanks,

Johnc

[stryd_one]

Just wanted to know if it was legal to do that.  Evidently,  from you reply, you have to go one way or the other, not both ways at the same time.

I think lyle's just saying, that you'll need to use the SRIO for your project... but yeh, it's 'legal' to manipulate PIC pins directly, if you are careful - Take a look at the mios_pin_list to see how pins are assigned...

Also search for J5_IO as an example. It's a MIOS module (software, not a MBHP module) that wraps all the ASM lyle already described, in convenient function calls to use the 8 pins of J5, usually used for the analog inputs - it also disables those analog ins, and if you wanted to do similar with other pins, you would need to disable any associated drivers.

For example, looking at the pin list you can see that if you wanted to use RC0 (PORT C pin 0) then it would conflict with the AIN MUX. You can disable that driver by calling MIOS_AIN_UnMuxed, but of course there is the trade-off that now you may only use 8 pots connected directly to the core, and no AINx modules.

Anyway, blah blah, that's just for educational purposes - in most cases, J5_IO would do the job.

[John_W._Couvillon]

Questions;

Is the default midi trigger table in "mios_mt_table.inc"  overwritten with the configuration for DINs and Douts that are specified in the midio128 .ini file? 

All through the .inc files, the  term "SET_BSR  MIDIO_BASE" appears.  Where is the value of MIDIO_BASE specified?

Thanks,

Johnc

[stryd_one]

Is the default midi trigger table in "mios_mt_table.inc"  overwritten with the configuration for DINs and Douts that are specified in the midio128 .ini file? 

Nah, that's part of MIOS, and not the app - nothing you need to worry about. Look to the application files - in this case, its midio_presets.inc

All through the .inc files, the  term "SET_BSR  MIDIO_BASE" appears.  Where is the value of MIDIO_BASE specified?

Again this is fairly easy to find if you just search through the application files (using grep or your IDE or similar) - I found it quickly in app_defines.h

In the vast majority of cases (ie, unless you are doing something crazy/stupid/weird) MIOS can be ignored and you only need to worry about the app itself. Hopefully that info will save you from searching through so many files :)

[John_W._Couvillon]

Stryd_one,

Yes, I found "Set_BSR  MIDIO_BASE" and as I read the "apps_define.h", its located in register location 0x80. My question is what number is stored in register location 0x80, and which of the  .inc files puts the number in the register, or does it matter. If the midio_base address is only used to calculate other banked register addresses, then it doesn't matter.  Hey, sorry to be "thickheaded" on this, but would like to get it straight in my thick head. 

You said I could search the application files using "using grep or your IDE or similar" . What is "grep" and "IDE"?

Thanks for your patience!!!!

Johnc