use of MIOS_DOUT_PinGet

MIOS programming (C)
1

I am finding that Midi-ox is locking up and sending a stream of system resets.

This problem started when I introduced (MIOS_DOUT_PinGet(6) ==0)) into the following conditional logic statements.

        if (pin_value == 0)// only react when switch is pressed

if (pin >= 1 && pin <= 5) group = 1;

if(pin == 6) group = 2;

if ((pin >= 19 && pin <= 25) && (MIOS_DOUT_PinGet(6) ==0))  group = 3;

if (pin == 28) group = 4;

Can anyone suggest what the reason might be.

Thanks

Robin

2

Hi Robin,

it’s me, the bracketizer, again ;D

I could imagine, that SDCC is not at all capable of differenciating between deeply nested logical structures.

To investigate this behavior in depth, one should take a look in the generated .asm file, located in the “_output”-folder.

However, as we had strange issues in the past with brackets (such as [tt]myFunction[x+y][/tt] is not working whereas [tt]myFunction[(x+y)][/tt] is working) , I would suggest to express this line as followed:

[tt]

if( ((pin >= 19) && (pin <= 25)) && (! MIOS_DOUT_PinGet(6)) ) { group = 3; }

[/tt]

Does this help?

If not, what sais the generated .asm file?

Best regards,

Michael

Edit:

and one more question:

  • is this the first time you’re accessing the DOUT-module?

just a thought, maybe it’s hardware-related…

3

Hello Michael

Answer to last question:

The MIOS_DOUT_PinGet is working properly in other parts of the code.

I will try your suggestions.

Regards Robin

4

Michael

I have tried your suggestion and it behaves the same.  I should emphasise that the code compiles OK; the system reset appears afte the relvant switches are pressed.

Robin

5

hm, that’s strange;

can you post some relevant lines of the generated .asm file?

we could check there if the result is software based –

a reset of the box should not happen to my understanding.

Here’s another suggestion: If you have MIOSStudio running, you could setup your Midi-Connections and then go to the debug-window and call the MIOS_DOUT_PinGet(pin) function with pin 6.

What happens? Does the box reboot?

What happens if you poll other pins?

Also rebooting?

If yes, it is most likely there’s a wiring-error on the DOUT-module.

If it reboots only on pin 6, it’s likely there’s a wiring error only on that pin.

If both pins are polled and no reboot happens, we know at least, that the problem is software based.

Best regards,

Michael

6

Michael

There is no compiler error.

There is no hardware error until two buttons are pressed.  Another button then pin 6, then Midi-ox locks out.  If I switch applications to something else then when I switch back to Midi_ox then a stream of system resets appear on the Midi-ox input monitor.

I know that the hadware is OK from other tests.  I have a test program that tests all the switches and Leds.  Also an earlier version of my program execises the same pins and switches it is fine.

I am not claiming that my current software is OK, by the way.

I have not used MIOS Studio yet.  Would it help in this case do you think?

What sort of software error could cause a problem like this.  Might the problem be with Midi_ox?

Robin

7

Michael

I think that there might be a problem with Midi_ox.  I have tried a larger number of buffers eg 400 and it does not seem to lock out. I need further work tomorrow.  I need to think about this some more.

Robin

8

Hi Robin,

I have not used MIOS Studio yet.  Would it help in this case do you think?

Yes, I think so. MIOSStudio provides two very good helps:

First, you have an MIDI I/O Monitor, that means you see what goes in and you see what comes out (similar to MidiOx). In that case, where you’re experiencing strange behavior of Midi_ox, it would be ideal to test wheather it’s the software or not.

Second, MIOSStudio has a very good implementation of MIOS Function Calls. You just have to select the function, type a parameter and press Send. Then you’ll see the return values. (Of course you first have to setup the In- and Out-Midi Port, but that’s all that has to be done to get this program running).

So, in your case, you could separately check where the problem is. Send a single MIOS_DIN_PinGet(6) Function call and see what happens.

If everything works, you’ll know for sure, that it’s in your code, then we’ll see what to do next…

What sort of software error could cause a problem like this.

Very strange behavior like this could be also a buffer overflow. Any variable storing a too high value for its datatype (eg. an unsigned char wants to store the number 1024, but unsigned chars are 8bit and therefor can only store values up to 255), puts the 3bit overhead-value just somewhere. And that’s pretty unpredictable where the garbled data goes…

In other words: think of filling 2 cans of water in a coffe machine that only can hold 1 can of water. The additional 1 can if flowing over. If it flows into the power-plug: BANG!

However, when you change the code and the result is every time exactly the same, it is more likely to be another kind of error, because the overflow would happen somewhere else.

All right, let’s summarize:

  • the MIOS application crashes, the pic reboots if you press button 6 and (some button from 19 to 25)

  • DIN_PinGet(6) is working in some other parts, but no in DIN_Notify()

  • the MIOS app does not crash when pressing only pin 6

  • the MIOS app does not crash when pressing any pin between 19 and 25

  • the MIOS app crash shows in rebooting the pic and sending a sysEx string by the 2nd level bootloader

right?

I would first check MIOS_DIN_PinGet(x) with MIOSStudio.

If this reveals no new insights, you should post a bit more of your code…

I hope this helps,

Best regards,

Michael

9

Michael

I reset the Midi-ox buffer values to the recommended ones.  Now I have no Midi-ox lock outs.

I haven’t solved the problem but I have a strong suspicion that I am committing a bracket error or some other logical fault.

Robin