MIDI Serial In problem

Wurlitzer

I used an object from the forum for MIDI and I was only interested in the bit bang serial input code.

I kept (I thought) intact, the original code for building the midiByte but it seems like most serial communications with micros I get garbage.

Using a standard MIDI Keyboard sending single Note On/Off messages I should be building a·long of HEX: 00_90_0C_(40 or 00)

What I get is 3 bytes but nothing close to what I expect. Almost like the baud rate is wrong. Byte #2 of this long seems to be $FF more often than not when it should be $90. Bytes 1,0 make no sense at all.

I am using a Crystal and have set the clock as follows:
_clkmode······· = xtal1 + pll16x
·_xinfreq······· = 5_000_000

Also, the circular queue tail pointer does not always increment with each message making me think the baud rate calculation is wrong. 31,250 is the standard MIDI baud rate.

NOTE: I just edited the mov midiBits, #8 to read mov midiBits, #9 and the: ·shr···· midiByte,#32-8 to shr···· midiByte,#32-9

PUB start(_midiPin, _Ptr_HubRamStartAddr): okay   '_Ptr_HubRamStartAddr contains the starting address of array in hub
 tmpCog :=cogid
  midiPin      := _midiPin                                           ' Move the SPIN parameters to the DAT section 
  bitticks     := clkfreq / 31_250                                   '   command.
  halfticks    := bitticks / 2
  okay := cog := cognew(@entry3, _Ptr_HubRamStartAddr) + 1   
 
DAT
''************************************************
''* Assembly language MIDI serial driver/decoder *
''************************************************
                        org
entry3
 
getMidiByte             waitpne midiMask,midiPin                    ' Wait for a start bit.
                        mov     midiBits,#9                          ' Set the number of bits
                        mov     bitClk,cnt                           '   and initialize
                        add     bitClk,halfticks                     '   the clock to the          
                        add     bitClk,bitticks                      '   middle of the first bit
                         
:midiBit                waitcnt bitClk,bitticks                      ' Wait until the bit is there
                        test    midiMask,ina            wc           ' Receive bit on the MIDI in pin,
                        rcr     midiByte,#1
                                                '   rotate it into our MIDI byte
                        djnz    midiBits,#:midiBit                   '   and go get the next bit
                        shr     midiByte,#32-9                       ' Justify and trim the received 
                        and     midiByte,#$FF                        '   MIDI byte
 
'After this code, I just collect 3 bytes then write them as a long into a circular Queue with the 8 MSbits=0.

Post Edited (Wurlitzer) : 1/30/2008 10:06:11 PM GMT

Wurlitzer

I would appear, that somehow the Prop is sensing that pin #26 (midiPin) is not equal to the midiMask as if I force the routine to just write any byte it sees, I am getting constant data. I placed a scope on pin # 26 and it is clean (2.5mv). I tried pulling it up to Vss with a 1k to minimize anything coming from the opto-isolator with no help. I then removed the opto-isolator and still I was processing bytes but the waitpne should have never released.

I have 5mv of noise on the 3.3 volt supply and 2.5 mv noise on pin 26 (serial input midiPin)

deSilva

Wurlitzer, there are many things unclear to me... Are there really 9 bits in your MIDI byte? I also do not like the way you use 6N138... I should propose a 4.7k between Vcc and V0 and just reading from V0 - it makes little sense to run 20 mA through the collector resistor and then just tapping it though a 1k.... This will additionally load the input ESDs with 1 mA which is marginally...

When you do not sense any input to pin 26 (or read random results) , then the software does not seem to be the issue...

Edit:
This also looks strange:

waitpne midiMask,midiPin

Both parameters have to be "masks"

Post Edited (deSilva) : 1/31/2008 6:54:36 AM GMT

steve_b

Take a look at the attached schematic in this Nutz/Volts issue.

Here's a page that shows something similar: http://www.borg.com/~jglatt/hardware/pc_intfc.htm

They aren't using the 1k resistor that you use. They go right to the pin with a pullup resistor doing their work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<FONT>Steve



What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
Lee Travino after the second time being hit by lightning!

Wurlitzer

deSilva and Steve, thank you both for your responses. When I get home tonight I'll look at everything you suggested.

deSilva, you wrote:

"This also looks strange:

waitpne midiMask,midiPin

Both parameters have to be "masks."

I took at face value what was in the opject on the prop board and you might be right. I'll verify this tonight.

The same with your question of 9 bits. I did not question that because the first bit would be the stop bit followed by 8 data bits (stop bit???????)

Steve, thanks for the PDF file. Looks like a lot of good information and a different hook up for the opto-isolator (deSilva mentioned this also.) I had used the exact wiring that was supplied in the .zip file for the Midi object but it is easy enough to change.

Thanks again, I'll post my findings.

Wurlitzer

deSilva: You spotted it. The waitpne line was the culprit. I had been copied from what I thought was working code. Thanks for the extra pair of eyes.