Sign in to follow this  
Followers 0
robinfawell

Push Button Handling

50 posts in this topic

Hi Robin,

very good progress!

Normaly I'm trying to group all BANKED registers which are used directly (without the use of pointers), so that the BSR can always be restored with SET_BSR *_BSR (replace * by the application name). So, for MIDIO128: "SET_BSR MIDIO_BASE"

more details about the addressing methods I used can be found here: http://www.ucapps.de/mios/mios_ram_handling.txt

You could also save and restore the BSR by writing it into a temporal register --- but in this case you have to know which register (address) is not used by the application itself.

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

I am in the process of implementing the Din Mode Entry Table.  As you may remember I have extended the Din Mode Jumptable and have now increased the No of entries to 12.

There will be a mixture of Din functions. Some are Midi for the 32 note pedalboard.  Some will be used to trigger the Radio Group Sysex. Others will be used to send simple Midi Control Changes to the Sound Module.

I need also to store various combinations of stop selections in Memory.

I believe that it is feasible to extend the table MIDIO_Presets_DIN_MODES in Midio_Presets.inc past the 0x0F address.  I propose to use 0x80 to 0x86 for Table Entries. There are no Input Pins associated with these table entries.  Actually they will be used to trigger "Sysex cancel" messages.  Please comment.

I see that you to fill in the unused area with 0's. Could you clarify the question of entries in the table for spare or unused Din's.  Should I use 00 or FF. I am using Mode 00 for @OnOff At present FF is unused.  Does it really matter in any case what the entry is because without the unused input being switched the table won't be addressed.

Best Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

I wouldn't use this configuration area for such extensions, the implementation is too difficult for that what you are doing, and I don't think that you are planning to enhance the perl script (mk_midio128_syx) in order to edit the modes.

It's easier to define special MIDI events for radio groups, and to handle them in a similar way like program change events. You could use "0xf0"-"0xff" for such extensions, such "Meta Events" are automatically forwarded to midio_meta.inc (read the comments in this file)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

Thankyou for putting me straight.

I am beginning to see how the radio groups (I have 7) can be implemented. I am assuming that I can use F0 to F6 as follows

F0 for radio group1

F1 for radio group2

...

F7                7

Each of the above can have a jump table. (Jumptable RadioGroup 1, 2, 3 etc.

Then using the second meta event byte, I can use its number in the following way

MIDIO_DIN_RADGRP1

;; checks whether current Table number is equal to this RADGRP Last Entry Number. 

;;If not, send Din No Sysex. If so get table entry No of this RADGRP Cancel Sysex.

;; In: Current_Table_Entry (somehow)

SET_BSR MIDIO_BASE

movf Current_Table_Entry, W, BANKED

cpfseq MIDIO_LAST_Table_Entry_RADGRP1

rgoto MIDIO_BANKSTICK_DUMP_GET

movwf MIDIO_LAST_Table_Entry_RADGRP1

movlw 0x80; Table entry No of RADGRP1 Cancel ;; 0x80 chosen as I am getting short on Din's

rgoto MIDIO_BANKSTICK_DUMP_GET

Question

I have shown the table entry of 0x80 2 lines above. Is this value OK, or am I limited to 7F?

I need to store setups of specific sound selections, pot values.  Maybe up to 12 sets and then recall these to re-setup the sound module.  Without going into any real detail will this be practical?

Thanks for your help.  I think I'm learning (Slowly!)

Regards Robin

Share this post


Link to post
Share on other sites

I think I'm learning

I see! :-)

The tables in midio_presets.inc are limited to 128 entries due to the static sysex structure, but you can always create new tables at different places (e.g. directly in midio_meta.inc)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

I am proceeding with completing the Midio128.ini files.  I am not completely sure that I understand what I'm doing.

The answers to the following should help.

I have 9 pots. One of these is the Tremelo rate.  I need to send the value to Channels 0 and 1. In my case B0 and B1.  I have 2 Push Buttons that need to operate in Toggle Mode.  I have called them TremF_PB and TremS_PB.  Each channel should receive the same modulation value when selected (vv) and (00) when deselected.  ie B0 01 vv  B0 01 00 and B1 01 vv B1 01 00.

What entries should I make in the MIDI_OUT and MIDI_In sections of  the .ini file forthe pot and the 2 Push Buttons.

Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

you cannot specify such variations in an .ini file which is fixed to the application specs...

How to use pots: this is described in the ain* examples (read the comments in main.asm and do some experiments with this application before integrating the required code into the midio128)

Toggling buttons via MIDI: do you really want to implement this in this way? It would mean that the remote side would never know if the button state is "on" or "off" - it's normaly better if the MIDI transmitter toggles the state (0x00 -> 0x01 -> 0x00)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Hi Thorsten

Thanks for the information. The Ain comments will be useful. I have read quickly the test applications and understand superficially the concepts.

It seems to me that because I am using the Midio128 to send Midi messages to the Roland Sound Module and that no midi messages are received that I only need to complete the Midi Out table in the ini file. 

Is this correct?

If I am not requiring Midi In do I leave the values as they are?

Toggling buttons via MIDI: do you really want to implement this in this way? It would mean that the remote side would never know if the button state is "on" or "off" - it's normaly better if the MIDI transmitter toggles the state (0x00 -> 0x01 -> 0x00)
 

You are right .  As I understand you,  I need to send  single messages  each time the button is pressed.  ie @Toggle mode.

I'm sorry to keep returning with more queries.

Regards Robin

I have now loaded the 128 ini file and was very pleased to see that the LCD  is showing both  @Ononly and @Toggle messages.  Most of the table is correct looking at the LCD

Share this post


Link to post
Share on other sites

Dear Thorsten

I have been trying now for two long days to find the cause of failure of my button handler.  Initially it looked as if was working (sort of).

I can generate sysex files of nearly the same length as the originals by pressing the relevant PB.  Usually each button needs pressing twice to get a fairly close match in Byte count. The first Byte count (using Midi-Ox) is usually smaller.  Sometimes the file is an exact match of the original but rarely.  Often the count is 1 byte greater.  Sometimes the cause is an additional F0 at the beginning of the file. ie F0F0 XX YY........F7

At your suggestion I am using the Meta Handler.  I am using a jumptable to sort into groups based on F0 F1  ....FA (EVNT0).

To simplify things a little I am keeping the radio groups based on F0 F1 etc very simple at present and only generate a MIDI_EVNT1 based on the PB value and send this via "rgoto MIDIO_BANKSTICK_DUMP_GET" to the Table Address generator and thence to the Sysex files stored in the  Banksticks.

I suspect that I have made a simple error. I have used your checkpoint methods to try to resolve the matter but no luck as yet!

Do the symptoms above suggest any  possible causes of error.

Yours in Desperation!

Robin

By the way all the organ pedal notes located on this core

module, 32 in number are OK.

Share this post


Link to post
Share on other sites

Hi Robin,

you could modify the sysex dump sending routine so that it doesn't send the dump itself, but all input parameters instead within a "dummy" sysex stream (I mentioned this method above).

This helps you to find out if the code which calls this routine has an error (input parameters are not always the same), or if the dump sending routine itself doesn't work properly (input paramters are stable)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

Thanks for your last tip.  I was able to verify that the bankstick address was correct and that the problem lay in the MIDIO_SYSEX_Send_Block routine.

I now have the Radio button behaviour that I want.  Each button concerned with the sound selection works with 2 exceptions.

1) Reset.  This is a long sysex message with a count of 16470 (0x4056).

As you suggested I have used the clrwdt instruction as below.  The TremF and TremS work OK.  Their count is 2756 (0x0AC4)

They probably don't need the WDT.  Do you agree?

;;GrpF0 sends Reset and TremS and TremF

MIDIO_META_Handler_F0

movf MIDI_EVNT1, W

clrwdt;; Reset Count = 5 secs, Trems = 0.9 secs

rgoto MIDIO_BANKSTICK_DUMP_GET

I observe that the LCD display shows that the system is rebooting.  The  Midiox recorded sysex  shows a count of about 6350 dec. This figure varies a little.

Have you any suggestions?  I suppose I could split up the message. But I'm not sure how to introduce the delay(s).

2) Extra F0. This seems to affect all PB's. The behaviour is inconsistent. Mostly there is an extra F0, sometimes not.  The Sysex message is preceded by an additional F0. ie

F0 F0 xx yy zz .. ..F7.

I have designed the organ so that it is possible to extend the PB's in each radio groups and have several cases where I have an address with a  Count 0000.  In these cases instead of sending nothing I send a Sysex message "F0" only.

I don't think it is switch bounce.  The PB bounce spec is typically 0.5 mS <2.0mS.  I am worried about the random behaviour.

Any thoughts on these problems will be appreciated.

Best Regards Robin

PS Since sending you this message I tried an experiment.  Before pressing the PB, I disconnected the power to the core. In each case the Sysex message was correct.  ie No extra leading F0.

To me this is difficult to explain!

Share this post


Link to post
Share on other sites

Hi Robin,

to 1) the watchdog timer will issue the reset after ca. 0.5s - therefore I would suggest to place the clrwdt instruction within the loop which sends the MIDI data (e.g. before the MIOS_MIDI_TxBufferPut)

to 2) Sending a single F0 without F7 violates the MIDI spec, therefore the behaviour of your MIDI interface or monitor can be random. You could send a "0xfe", this means "active sense" and is a single-byte event. Note that some MIDI monitors don't display this byte (search for the filter option of your MIDI monitor in this case)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Hello TK

Thanks for Answer 1) I will do some experimentation along the lines you suggest.

Re2) Extra F0

I have no control over the leading additional and unwanted F0. It just happens.  It is not really random.

It only happens on the 2nd and subsequent button presses after rebooting.

The first button press after a reboot always gives a correct Sysex message. 

I cant think of what is different with the logic before 1st press and afterwards.  Could it be a carry bit or something ?  The midiox display shows that the decremented count is behaving properly.

On more consideration,  are you suggesting that I just accept that the sytem will produce a spurious 0xXX and that I should precede all Sysex messages with 0xFE ?  Hence if the 0xFE occurs or not, it  will not matter.

Best Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

no, this is not what I saying. I assumed that sending a single F0 was your intention.

Forget this about FE (don't feel confused ;-)

It must be an error somewhere in your program, thats all what I can say

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Hi Robin,

there is new hope:

I now have the Radio button behaviour that I want.  Each button concerned with the sound selection works with 2 exceptions.

1) Reset.  This is a long sysex message with a count of 16470 (0x4056).

As you suggested I have used the clrwdt instruction as below.  The TremF and TremS work OK.  Their count is 2756 (0x0AC4)

during my USB experiments I noticed a similar effect

The reason was the "Low Level Input Buffer" setting of MIDI-Ox (View->SysEx, SysEx->Configure), which was not large enough for long data bulks.

Try 32768, this should work better

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

I've increased the Midiox setting and included the clrwdt in the address  loop counter. It works well  apart from my "Extra F0" problem.

As you may recall some of my sysex byte counts are relatively small 480 bytes.  Will there be any disadvantages using clrwdt in this way for these smaller counts?

Regards Robin

Share this post


Link to post
Share on other sites

Dear Thorsten

Extra F0 Problem

After too many hours, trying various changes without any luck, I am coming to the idea that I may have an inteference problem caused by ringing or oscillation in one or more of the components.

Core; DinX4; Bankstick; Push Buttons.

As a start I will provide power supply decoupling to all (except the PB's) of the above.

My reasons are as follows:-

A) The sysex messages are corrupted only at the beginning.  I have now found that my large byte sysex is preceded consistently by F0 XX YY.

At the moment I cannot remember the exact codes.  However it is the first 3 bytes of the "Reset" sysex message.  The other sysex have a repeated F0 at the beginning.

B) Perhaps the noise spike and/or oscillation  coincident with the press of the PB causes the leading code(s) to be read spuriously from the  BS and then this routine is repeated with the correct code.

C) The checks of countdown using checkpoint show the correct decrementing of TMP[12]

D) The BANKSTICK DUMP routines were those emanating from your good self. If they were mine then I would not be so confident!

Sysex generated following reboot are 99% correct. (No leading errors)

Can you think of a way of determing by measurement or code manipulation the reasons why I get these errors.

Best Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

in order to find out if this is a electrical, or a software problem, I would suggest an extension in the program which checks if two F0 are successivly sent.

The best place for such a routine is the "USER_MIDI_NotifyTx" hook, which will be called by MIOS before a MIDI byte is sent out. Note that this is an interrupt routine, therefore you have to take some special things into account (see the explanations below).

However, just try the following (search for the label in main.asm and replace it by:)


;; --------------------------------------------------------------------------
;;  This function is called by MIOS before the transfer of a MIDI byte.
;;  It can be used to monitor the Tx activity or to do any other actions
;;  (e.g. to switch a pin for multiplexed MIDI Outs) before the byte will
;;  be sent.
;;  Note that this is an interrupt service routine! Use FSR2 instead of FSR0
;;  and IRQ_TMPx instead of TMPx -- and make the routine as fast as possible!
;;  Input:
;;    o transmitted byte in WREG
;; --------------------------------------------------------------------------
USER_MIDI_NotifyTx
;; save received byte in IRQ_TMP1
movwf IRQ_TMP1

;; don't continue if byte is != 0xf0
movlw 0xf0
IFNEQ IRQ_TMP1, ACCESS, rgoto USER_MIDI_NotifyTx_End

;; don't continue if last byte was not 0xf0
movf LAST_RECEIVED_BYTE, W
IFNEQ IRQ_TMP1, ACCESS, rgoto USER_MIDI_NotifyTx_End

;; error regognized, set a debug pin (RD4 - CORE::J14)
bsf LATD, 4

USER_MIDI_NotifyTx_End
;; save byte for next call of this routine and exit
movff IRQ_TMP1, LAST_RECEIVED_BYTE
return
[/code]

This will set pin RD4 to +5V if an error has been regognized. If this pin is always zero, even when your monitor shows two F0, then a cross-check is required (e.g. check for 0x00 instead of 0xf0)

If this pin goes to +5V, then you know that there is really an electrical problem (or a problem with your PC MIDI interface...)

Note that "LAST_RECEIVED_BYTE" has to be located to a free address in app_defines.inc, it should be below 0x80

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

I've rebuilt my BS, neater this time, tried a few things, decoupling, grounding all Ain pins. and No luck!

I've tried your test for Double F0. It shows none!

However the test to cross check also failed.

I confirm that I measured pin 27 for RD4 and that I substituted 0x00 for 0xF0 in movlw 0xF0 (3rd active line). I located the LAST_RECEIVED_BYTE EQU 0x019 in app defines...

I guess that at this point there may be a problem with the test or my modifications.

Midio_Meta.inc

I've wondered for some time how I should exit  my "meta" program.  The original program shows 2 methods:-

goto MIOS_MIDI_BeginStream

goto MIOS_MIDI_Tx BufferPut

I am just using "return". ie

call MIDIO_SYSEX_Send_Block

return

I've tried the first goto above, it seems to behave the same ie F0 F0!

Here is the code extract from my version of Midi_Meta.inc that follows the derivation of BS, Address and Count

;;-----------------------------------------------------------------------------------------------;;-----------------------------------------------------------------------------------------------

movf TMP3, W

call MIOS_BANKSTICK_CtrlSet

call MIDIO_SYSEX_Send_Block

return;; Is this OK? Midi_Stream?

MIDIO_SYSEX_Send_Block

MIDIO_SYSEX_Send_BlockLoop

;;clrwdt;; used for Reset large file

call MIOS_BANKSTICK_Read ;; Expects Addr in ;;MIOS_PARAMETER[12], Read byte from BS

call MIOS_MIDI_TxBufferPut

;;Decrement 16 bit loop counter, loop until counter is zero

decf TMP1, F

skpc

decf TMP2, F

bc MIDIO_SYSEX_Send_BlockLoop

return;; This may need changing

BANKSTICK_DUMP_TABLE

;;BS No  Addr  Count

dw 0x0000, 0x0000, 0x04D4

dw 0x0000, 0x04D4, 0x04D4

dw 0x0000, 0x09A8, 0x04D4

dw 0x0000, 0x0E7C, 0X09A8

etc, etc

dw 0x0002, 0x21CC, 0x04D4

dw 0x0002, 0x26A0, 0x03C0

;;-----------------------------------------------------------------------------------------------;;-----------------------------------------------------------------------------------------------

Most of the code above is yours. I would be very pleased if you could check it esp. the returns.

Thanks Robin

Share this post


Link to post
Share on other sites

Hi Robin,

I've wondered for some time how I should exit  my "meta" program.  The original program shows 2 methods:-

goto MIOS_MIDI_BeginStream

goto MIOS_MIDI_Tx BufferPut

I am just using "return". ie

call MIDIO_SYSEX_Send_Block

return

I've tried the first goto above, it seems to behave the same ie F0 F0!

First of all - this cannot cause such an error.

A "goto <function>" behaves exactly like "call <function>" and then a "return". I'm mostly using a "goto" at the end to save one instruction (2 bytes saved which can be used for something else ;-)

"MIOS_MIDI_BeginStream" will send a 0xf9, "MIOS_MIDI_EndStream" a 0xfe - but only, when "MIDIbox Link" is enabled.

It is not required for your software - and it will do nothing so long the Merger Mode is either "enabled" or "disabled" (ignore these functions)

Here is the code extract from my version of Midi_Meta.inc that follows the derivation of BS, Address and Count

;; ...

return;; Is this OK? Midi_Stream?

it's ok

;;clrwdt;; used for Reset large file

you've commented out the "clrwdt" instruction - this is dangerous and especially this could cause the problem!

If the watchdog is not serviced within a certain time, the core will be reset, and a MIOS upload request will be sent - did you notifce something like this?

This could also explain why pin 27 never toggles on two following F0 bytes (the PIC is reset after the first F0)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

At this point in time I have not included the long byte messages such as "reset"  (0x4560 count) in the BS tables.  Mostly the bytes are 1000 2000 and less.

I am aware that long messages can cause the core to be reset.  I dont think that should be the case with sysex messages 1000, 2000.  But maybe this is a bad assumption.

The clrwdt function was in the loop when I was checking the transmission of "reset" above.  I took it out to eliminate this as a possible cause of the 'extra F0' error.  I had assumed that it was mainly required for these long messages.

When does the WDT normally operate?

I have only seen the core upload with "reset"

Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

you are possible right, the transfer of 2000 bytes takes 640 mS, this should be ok. The watchdog resets the core after ca. 2 seconds in this configuration (it's an independent timer which is not clocked by the external crystal)

So, I've no idea what could cause such an effect. You've already checked for the second F0 in the software at a place where all transmitted MIDI events are reported (USER_MIDI_NotifyTx) and haven't detected the failure. This means that the PIC software cannot be the reason...

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Dear Thorsten

This is proving to be a very difficult project.  It seems as if I may be suffering from noise spikes due to long leads between DIns, 1st Din to Core , Core to BS, Push buttons to Dins.

The system works perfectly following a reboot. 

It does give proper results sometimes, only with about 10 of the 56 Radio group PB's.

Plan

I propose the following:-

To connect one EEprom only, as directly as I can to the J4 connecter.

To connect all unused inputs and outputs to GND using a 4.7k resistor (using a connecter).

Have 1 Din connected  as close to the J9 connecter as possible.

Have no Douts connected at the beginning.

Keep the PB_ Din leads short.

I can then check for extra F0.

Have you any comments?

Regards Robin

Share this post


Link to post
Share on other sites

Hi Robin,

before this thread runs endless, I would suggest that you send me your code + the BankStick dumps, so that I can try this with my hardware.

An unrelated note: did you ever think of programming the application in C instead of assembler?

The SDCC wrapper is already available - the implementation should be much easier, and it is

especially not required to use the MIDIO128 as a framework.

I guess that your whole application could be put into a single main.c file, which gives you a

much better oversight - I think it's worth a try! More infos can be found under:

http://www.ucapps.de/mios_c.html

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Thanks Thorsten

I really appreciate your offer.

I will clean up some of my work so that it is straightforward.

The C programming will be new to me.  However I will look at the files.

Best Regards and Thanks again!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0