Visual MIOS Menu Builder ..anyone ?

[Artesia]

Hi,

Another thing thats crossed my mind, in the process of getting quite stuck in trying to do the apparently simple task of Changing some button assignments on SID Interface Step B ...to allow exhisting menu buttons to select the sids used, when in 'base' menu mode 'patch select'... In the end wilba came to the rescue on that one.. Please see this post if those matters interest you at all:

http://www.midibox.org/forum/index.php?topic=7854.45

Right, Well getting to the point, a really handy Coding Tool to have (assuming Recent developments with Code Blocks doesnt already cater for this).. is a tool for building MIOS asm Menu systems in a visually orientated fashion. Ie: to have a program which for instance has on one side the menu tree... and a stack of value / code boxes to define perameters & functions of the various things that go on; in as plain a language as possible. The visual structure of the program layout should clearly show the visual structure of the MIOS program & the resources its using & where.

Surely such a tool would be useful for real coders, as well as the less well aquanited ? ..as im sure that building menus in asm (or c) is very time consuming & uninspriing. ...and a little time spent making a program that throws togeather these structures in a fashion like a html page builder (ie dreamweaver) ..would save alot of time on future projects.. leaving the coder to concentrate on the 'fun' things.. like writing a new interface protocol for talking to a new bit of hardware (CEM3396 synth chip anyone ?).

On the less experienced side, it would of could of course leave the average user free to configure the interface layout to meet their needs.. and with further development, completely contain all the code modules needed to build a mios app (drop connections between User Interface / Midi Protocols & interface librarys with cables and nodes like in reaktor maybe ?).. without needing to get into the nitty gritty.

[stryd_one]

..as im sure that building menus in asm (or c) is very time consuming & uninspriing.

You bet.

I'd love a tool like that but it wouldn't really work with existing apps, and so far there are only a handful of custom apps starting from scratch. If you make an app like the one you described I'll surely be a beta tester for some future projects! ;)

[Wilba]

I don't know if a "visual tool" is feasable... there are similar things in application software development, like editors for menus and dialogs and such, that ultimately generate source files that get compiled into the application. So while there's nothing impossible about doing the same thing for a MIOS app, it's a lot of work to build such a tool.

What perhaps you are wanting is a code skeleton demonstrating how to code a simple menu system like MB-SID. Imagine you take the menu code out of MB-SID and generalize it so it's not specific to MB-SID... then it would be easier to see how the buttons and menu encoder handlers work, how the "selected" parameter is determined, shown on the LCD, changed by the menu encoder handler, etc. Then you'd see how to edit the ASM (or C) code to do what you want, and drop it into whatever application you're working on. That's time-saving enough, and cuts down on the not-so-fun bits.

Ultimately, if you're going to write a MIOS application to do something, you'll have enough coding ability to do the menus too, either from scratch or by coping from example.... just like I was able to help you out before by knowing how to copy a line from here and stick it there.

[Artesia]

well.. i came to this conclusion about menus specifically

..because for one item in a menu to work & be placed correctly.. code relating to it (specifically) seems to need to be in at least 10 places at once ...and often across files ..not just the same one.

For the sake of spending afew seconds clicking a tab or two & typing some values to create the same content without spending potentially tens of minutes doing the same manually (and greatly reducing the likelyhood of debugging); it seemed to make more sense investing a little time making a tool which Strifes through defining really rigid & logical elements of programming like this. From experience with things like (ugh !) ..visual basic ...its the sort of thing that could be put togeather in a couple of evenings at worst... Assuming a good understanding of the actual assembler involved ..and that unfortunately i dont have right now; otherwise i'd be diving in and building this tool myself right now.

[Wilba]

You're totally underestimating the complexity of such a tool... and how it must integrate with the rest of your source code and add the required code when you click and type a bit of text. Even sophisticated IDEs like Visual Studio only do the bare minimum for you, and you still have to go and edit the code manually and make it do what you really want.

The problem is, coding for a microcontroller in ASM (or very, very lightweight C!) requires code that would be considered ugly hacking in higher-level languages like C++ and Java... all variables being global, no use of classes, storing state in a couple of bits of one memory address instead of a nice set of named variables. The code for one menu item is in a few places, because its grouped by function, and it has to be that way, grouping it the other way would involve a lot of extra code.

TK has put a lot of work into generalizing things, hence the use of tables to "connect" a button's DIN pins with a function to call if it's pressed. So in your example of making "Select 1" do something different, here's how you could have worked it out:

In cs_menu_io_tables.inc:

	DIN_ENTRY	CS_MENU_BUTTON_Sel1,	 1,	 7

Now do a "find in files" with your favourite text editor for the function CS_MENU_BUTTON_Sel1. There it is, in cs_benu_buttons.inc:

CS_MENU_BUTTON_Sel1
	;; select button #1, set cursor to 1st position
	movlw	0x00
	;; 	rgoto	CS_MENU_BUTTON_Select_Cont

CS_MENU_BUTTON_Select_Cont
	;; do nothing if button has been depressed
	IFSET	MIOS_PARAMETER2, 0, return
	;; set cursor to: CS_MENU_PAGE_OFFSET + number in WREG
	addwf	CS_MENU_PAGE_OFFSET, W

	;; branch to the CS_MENU_Select function
	goto	CS_MENU_Select
[/code]


Note the commented-out "rgoto CS_MENU_BUTTON_Select_Cont", it "drops-down" into that function.

So, depending on which select button is pressed, it sets the number of the button in W register, which is then added to the current offset into the menu (you can scroll the menus, so Select 1 isn't always the first displayed menu item), and then calls CS_MENU_Select. Go have a look at that then...

In cs_menu.inc
[code]
CS_MENU_Select
	;; if in name editing mode, branch to CS_MENU_Select_NameFunc
	IFSET	CS_STAT, CS_STAT_MODIFY_NAME, rgoto CS_MENU_Select_NameFunc

	;; if in main page (CS_MENU[7] set), branch to root menu
	IFSET	CS_MENU, 7, goto CS_MENU_EXEC_GoToRoot

	;; store new position in CS_MENU_CURSOR_POS
	movwf	CS_MENU_CURSOR_POS

	;; store cursor pos in CS_MENU_PARAMETER_L
	movwf	CS_MENU_PARAMETER_L

	;; clear CS_SELECT_CTR (so that new message appears immediately)
	clrf	CS_SELECT_CTR

	;; now request a display update so that we see the new parameter on screen
	bsf	CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ	; (see cs_menu.inc)
	;; clear counter so that cs_menu_timer.inc counts from zero and the menu entry is marked for a short time
	clrf	CS_CURSOR_CTR
	;; clear "CS_STAT_CURSOR_FLASH" bit (see cs_menu.inc for the handling)
	bcf	CS_STAT, CS_STAT_CURSOR_FLASH

	;; leave function if cursor pos >= max entries
	movf	CS_MENU_ENTRIES, W
	IFGEQ	CS_MENU_CURSOR_POS, ACCESS, return

	;; branch to EXEC handler

	;; get pointer to entry which has been selected
	rcall	CS_MENU_Hlp_GetCursorPosEntry

	;; get handler IDs
	rcall	CS_MENU_GetHandlerIDs

	;; EXEC ID in MIOS_PARAMETER2
	movf	MIOS_PARAMETER2, W
	rgoto	CS_MENU_EXEC_Handler

Oh, lots of code! But the interesting thing is, in the second line of code is:

	;; if in main page (CS_MENU[7] set), branch to root menu
	IFSET	CS_MENU, 7, goto CS_MENU_EXEC_GoToRoot
[/code]


So the comment tells you it's testing if you're in the main page and to do something different.
So you can copy how that's done and put it in your button handler, so that Select 2 to Select 5 can work as an "alias" to SID 1 to SID 4 buttons, like I showed you.

Look at the rest of the code there... it's actually quite generalized, there's no references to exactly which menu it is showing, and there's no code there to draw the menu. This is because handling a button or encoder event happens at one time of the MIOS event loop, and writing to the display happens at another. A flag is set to get the display updated, and in that event handler, it works out what it should write to the display. Just look at how neat it is. It looks up the menu tables to work out what it should do, so the menus themselves are already generalized into separate tables elsewhere.

And here's the elsewhere, for example, see how the Filter menu is handled.
In cs_menu_tables.inc:
[code]
	CS_MENU_ENTRY	CS_MENU_FIL,               "FIL",  0x00, PRINT_NOP,        EXEC_MENU,       R2PP2R_NOP

One line to define the "menu" as it appears in the "root menu"... labelled "FIL", given an ID called CS_MENU_FIL. Futher on, some code to define what's in the filter menu:

; ==========================================================================
;  The filter menu
; ==========================================================================
CS_MENU_TABLE_FIL
	db	(CS_MENU_TABLE_FIL_End-CS_MENU_TABLE_FIL)/CS_MENU_ENTRY_LEN, 0x00

	;;              Register (00=dummy)         |<->|  max   print ix          exec ix          parameter transfer
	CS_MENU_ENTRY	CS_SID_FILTER_CHANNELS,     "Chn", 0x07, PRINT_FILTER_CHN, EXEC_SELPAR,     R2PP2R_FILTER_CHN
	CS_MENU_ENTRY	CS_SID_FILTER_CUTOFF,       "Cut", 0x7f, PRINT_DEC,        EXEC_SELPAR,     R2PP2R_CC
	CS_MENU_ENTRY	CS_SID_FILTER_RESONANCE,    "Res", 0x7f, PRINT_DEC,        EXEC_SELPAR,     R2PP2R_CC
	CS_MENU_ENTRY	CS_SID_SUSKEY,              "KTr", 0x3f, PRINT_KTR,        EXEC_SELPAR,     R2PP2R_KTR
	CS_MENU_ENTRY	CS_SID_FILTER_MODE,         "Mod", 0x07, PRINT_FILTER_MOD, EXEC_SELPAR,     R2PP2R_FILTER_MOD
	CS_MENU_ENTRY	CS_SID_FILTER_CHANNELS,     "Ext", 0x01, PRINT_FILTER_EXT, EXEC_TOGPAR,     R2PP2R_FILTER_EXT
	CS_MENU_ENTRY	CS_SID_FILTER_MODE,         "3Of", 0x01, PRINT_FILTER_3OF, EXEC_TOGPAR,     R2PP2R_FILTER_3OF
CS_MENU_TABLE_FIL_End
[/code]
Another nice table, each line defines a menu item, a "register" (used to identify a parameter in the patch) with text for that menu item, the max value and which functions to handle the printing, selecting and transferring of the parameter to/from the patch.
That is really generalized, and this generalization not only avoids a lot of repeated code for every possible parameter, it makes it really easy to extend, if you wanted to add new parameters.
The point of going into all this detail is to show you exactly what you're suggesting could be replaced (or just edited easier) with a visual tool to make life easier, as well as give you a quick overview of the code should you want to make your own menus. I'm also suggesting that once you learn a bit more ASM and work out how this code all works, then you'll discover that it really isn't that hard to change it to do what you want, be that make a new application or just make changes to the MB-SID application.

[stryd_one]

FBAP!!!!!

That's great info Wilba!

[MRE]

the beginings of a really good tutorial...

hint

[Artesia]

Thanks for the in depth explaination wilba :) gives a little more insight...

Problem in general with getting to grips with these things, is that no-one fully explains what is going on.. from the people who explain the microchip ASM (that is espially poorly documented so far) ..and those who write programs that sit on top of it; assume that the next person to have a go; could make sense of the ASM explaination. Added crucially, to explaining code segments functions right next to their lines of code.. though not giving a really clear overall breakdown on how the data is flowing and moving throughout the entire structure.

In summary Grasping these things is difficult, because everyone throughout the chain of events; automatically assumes That the viewer has a clear understanding of how certain things happen & work ...usually that missing information overlaps so much ..that its impossible to visualize how it works.

From a tutorial point of view, so that everyone has a grasp of learning whats going on... everything needs to be layed out clearly & completely in a visual way. Thats how your mind tends to map out these interactions. And if you cant plot exactly how something happened ...the explaination is not complete.

In order for anyone to pick it up:

1st a short primer on how the electronics get the signals in and out...

2nd (Cpu Exposed) the exact way the assembler language instructions relates to what the PIC is doing.. needs to be layed out.

3rd The exact nature and breakdown of the midi protocol needs to be layed out bare to show what is available.

4th (hardware perspective) The perameters, limitations & program structures from the point of view of data coming in and flowing back out needs sketching out in a detailed flow chart (with exact mios name tags - &/or typical naming convention).

5th (software perspective) the typical program cycles (screen update, button scan ..etc) need laying out in a flowchart.. with direct reference to the files involved when this is happening.

..that sort of thing.

Right, on with today..

[MRE]

Having not dug into the include files myself, I can only offer a limited opinions:

Midibox gets developed rather quickly. Being that it is an 'open source' project increases this development speed, and puts more 'hands in the pot.'  TK is under no obligation to deep comment his code either. In fact, I think most would prefer he didnt, as time spent commenting is time wasted coding. Not to say that comments wouldnt be helpful. But ASM is a bear, and a lot of damage can be caused here.

Anyone interested in coding ASM for the Midibox should have a strong grasp of asm in the first place. No point making it your first attempt at ASM, you would only cause havoc in your pic.

So my argument on ASM is that anyone who feels they have a good grasp of ASM (enough to wrangle new features out of MIOS) wont need a load of comments anyway, and could always ask TK for details when they get a bit lost.

My argument for C on Midibox is roughly the same. You sould have a good grasp of C before attempting new features. Now, in the case of C, more comments would be better then less. Most of the 'user' and 'application' layer is done from the C portions of code, and is the area most people are likely to want to change something.

Now, Im not saying that if you dont know C, you shouldnt have need to change something. A menu edit is a good example here.

Bottom line with code (ASM or C): Excessive documentation would only slow development. If someone wants to side-project commenting the C source, that would be mighty usefull, but doesnt necessarily need to be TKs responsability.

Most of your qestions boil down to (and I hate to sound mean here):

RTFM

and by that I dont mean the midbox/mios manuals. I mean 300 plus page datasheets at Microchip.com.  Much of the questions/points you have addressed here are clearly layed out in that datasheet.

ASM language - all your questions about MIOS ASM can be cleared up in the Microchip manual or with a direct Q to TK

How Electronics get the signals in and out - well..umm.. as far as the ASM side, its in the manual. As far as the actual electronics within the chip, and the limitations there of (example: how the ADC works for the AIN board).. you guessed it: In the manual.

How the AIN board itself works.. Get a chip datasheet for the IC used on the board. Its pretty simple. If you cant wrap your head around it, you shouldn't be modifying Midibox too much. Ask a specific question and someone can easilly walk you through it.

CPU exposed and how ASM intructions work within the PIC: Absolutely read the Microchip manual. No one here can concisely explain that one. Its a 300 plus page manual.

Midi protocol: Thats one that absolutely could be addressed here. A few links to the midi spec itself, with a few pages dedicated to how it all works in MIOS would be useful to SOME programmers. But, If you are getting this deep into Midibox though, you are likely talking to TK a lot anyway.

4 Harware parameters etc:  not exactly sure I understand you here, but I think your questions could be cleared up with a combination of..  drum roll please..  reading the Microchip manual, along side a comprehensive chart of the MIOS registers. So, good idea there. Where everything "sits" in the MIOS memory would be nice. A MIOS memory/IO map..  Anyone interested in starting that?

5 Software Program Cycle:  Another nice thing to have. Not sure exactly how helpful it would be to anyone but an advanced MIOS asm programmer, but still...  Only one who could concisely answer that would be TK. Likely he has several hand scribbled ones laying around from revision after revision..  if we were to be so lucky.

I think what would more immediately be usefull is an index of functions, and their purpose in a nice handy chart..

Something like:

Function | file name |  purpose (taken from comments) |  send and return values |  example of modification

CS_MENU_BUTTON_Sel1  |  cs_benu_buttons.inc  |  select button #1, set cursor to 1st position  |na|  na - part of menu system

[MRE]

By the way, the table system implemented in C and many of the other features TK built into the whole Midibox system are quite advanced for a PIC application.

Remember, back in its humble days, the PIC was only ment to be an intelligent Peripheral Interface Chip!

The 877 is the grown up version of that little processor in your computer keyboard.

TK crams, maximizes, minimizes, and otherwise bludgens code into a pretty small space. It borders on immaculate conception.

The tricks involved often defy 'conventional' thinking in ASM to streamline things. Commenting such work would still get the reader nowhere. You have to intuitively understand the processor core.

You would not catch the fact that he may be using a strange carry flag behavior caused only by a certain circumstance in order to save 3 instruction cycles.

Us NORMAL guys just cant think that way.  ;)

[Artesia]

well ..we can but try.

(just noticed that you actually put two posts in..)

yeah.. i know pretty much whats happening from the electronics side ..except some people may not. and thus why i meantion it.

Fair comments on all of the above, yup filling in some gaps on uncharted terratory would be helpful; if someone feels compelled to do so..

Ill go hunting for that Microchip ASM manual ..as i think it would be more useful for me to learn that right now.. aside of getting to the very bottom of this mios business; i also have a good number of small things i want to build as pic projects. That have nothing to do with mios; which would benefit from no nonsense coding.

ah yes, before pics it was programmable logic cascades i beleive ...found a newer relative of one of those as part of the control circuitary for a waldorf pulse of all things !

[Artesia]

think this is the right docs for picking appart 18F series...

Anyone else also want to read too, please go ahead :)

a detailed look at how the pic is programmed; still useful tho.. (continues looking.

http://ww1.microchip.com/downloads/en/DeviceDoc/39576b.pdf

mplab manual (280 pages):

http://ww1.microchip.com/downloads/en/DeviceDoc/51025e.pdf

Pic 18f datasheets (332 pages):

http://ww1.microchip.com/downloads/en/DeviceDoc/39564c.pdf

..oh btw, the reason im so insistent in getting a good grip on the programming side of things here... is i am on a mission to adapt the MB CV & afew other things to make a fully automatable, modular Filter / analog processor bank (already well into building the filters & the initial MBCV's). And need to customise afew things in order for it to be a complete, coherent solution.

[stryd_one]

Yeh I agree with you both on this one. It is very hard to get a thorough, and 100% complete chain of events, but in general, it's not worthwhile to make such an illustration.

Here's the results of a brainstorm I was involved in at work recently. I thought it was very interesting, so I'll share a very condensed version of our conclusion: The primary consideration when preparing documentation (such as instructional or informational texts) should be the intended audience.

To use this situation as as example, we could start with all about C code, and then ASM, and how the compiler translates C to ASM, and then how ASM is converted into binary, and then we'd have to talk about binary, and then how bits are represented by electricity, and all about electricity, volts amps, resistance, capacitance transistors, and then how electrons are passed from atom to atom, and what they are built from, and....

But hangon.... Who really needs to know how atomic particles behave to write an app? OK I personally wanted to know so I went out and learned but I'm weird geeky like that. Point is, how deep the documentation needs to go, depends entirely upon the reader, and because of that, it's more practical to assume a certain amount of knowledge and only go that deep.

I personally think that the level of documentation is pretty darn good for a noncommercial project. You'll be hard done to find many that are better :) I do agree that sometimes it's hard to add everything up, but hey, MIOS is a text adventure^TK, I think that even though it takes a lot of time and effort to go on that adventure (Fly Google Airways and use the search engines here) it is something that you should really enjoy.

Just thank goodness it's not 1995, or we'd all have to fish through 50000000000 altavista hits to find what we want.

[MRE]

the 18F is  bit diffent, but if you want some good reading, check out the 16F84/877 manual (it actually covers most of the 16F series). You can get a lot done with that machine as well.  Many original MBs are built on the 877.

Technical documentation?!  Hell.. 99% of the commercial products out there have less tech documentation than MidiBox.

[stryd_one]

Technical documentation?!  Hell.. 99% of the commercial products out there have less tech documentation than MidiBox.

LMAO so true!

[Artesia]

yup.. tho none of those expect or encourigee you to 'lift up the bonnet..' ;)

[MRE]

true true!