Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

I have fought this for the last 2 days. This routine looks for a bit
or bits that have changed since the last time the program read a word
from PortA.

Below ,I have shown, 1 of 7 "If (tmpBitMask And BitX) > 0" statements
and the parsing works perfect. Depending upon how many bits have
changed since the last read I should end up with :
ByteCount = #bits changed * 3

If I force a single bit (bit 0) to change I receive 144, xx (note
number, but not the 0 or 64.

When I change the same bit again, I finally receive the 0 or 64 and
then a 144. The rest of the message waits until the next bit change.

It seems like it has the correct data in the queue as it is not lost
but for some reason I only get 2 at a time. My receive event on my PC
is set to 1 so it fires with every byte sent. I tried setting it to 3
with no improvement. I slowed down the baud rate from 38400 to 9600
just in case the PC was the culprit. I even tried Hyperterminal to
verify I was only receiving 2 bytes instead of 3.

It seems I fight BX24 communications on every project so I must be
doing something wrong. NOTE: Sometimes if I press the "Reset" button,
I receive the missing byte.

The OutComm array is set to 30 (max bytes per scan = 21+9 overhead
bytes)
I have DIM'd QueueData (1 to 21)
================ Code Below ========================

If (tmpBitMask And Bit0) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 144 'channel 1 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit0) > 0 Then
QueueData(ByteCount) = 64
Else
QueueData(ByteCount) = 0
End If
End If
Call PutQueue(OutComm, QueueData, ByteCount) 'send data
================= End Code ===========================





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wurlitzer28" <craig.whitley@a...>
wrote:
> ...It just does not send the entire packet of 3 or 6 or 9
> ....21 bytes. It is always one byte less than I expect.
> The missing byte is the first byte sent in the next packet.

These comments bring to mind a couple of things.

- Inasmuch as RS-232 is not a packetizing protocol, the packets of
which you speak are entirely of your own creation/interpretation. How
are you determining that a given byte is in one "packet" when you
believe that it should be in another?

- A program can interefere with serial transmission if it disables
interrupts. This might explain a time lag between when you think a
byte ought to be transmitted and when it is actually transmitted.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

The PutQueue procedure uses a Count Type of Integer.
Arrays that start at 1 are treated differently than arrays that start with 0.
Manual says, "If the queue is full, PutQueue will suspend the task until there is enough room to insert the data."
Keep trying to fix it, and let us know what happens.

Eric
----- Original Message -----
From: wurlitzer28

Subject: [BasicX] BX24 Comm1 should send 3 bytes but only 2 received I have fought this for the last 2 days. This routine looks for a bit
or bits that have changed since the last time the program read a word
from PortA.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> I have DIM'd QueueData (1 to 21)

To what?

Have you initialized ByteCount to 0?

Ingvar



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Ingvar Esk" <ingvar.esk@s...> wrote:
>
> > I have DIM'd QueueData (1 to 21)
>
> To what?
>
> Have you initialized ByteCount to 0?
>
> Ingvar Thanks for taking the time to look at this Ingvar.

The QueueData is a byte array. I just listed the size in case I made
a DIM size mistake.

ByteCount is a byte and set to zero at initialization.
ByteCount is always set to zero right after the PutQueue command.

Again, the data is there and not corrupted. It just does not send the
entire packet of 3 or 6 or 9....21 bytes. It is always one byte less
than I expect. The missing byte is the first byte sent in the next
packet.

I can trigger the suspect event very slowly so I can see what I am
receiving at each transmission.

Is there a command to lubricate the UART? It must be sticky. {;0)





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "eserdahl@" <eserdahl@p...> wrote:
>
> The PutQueue procedure uses a Count Type of Integer.
> Arrays that start at 1 are treated differently than arrays that
start with 0.
> Manual says, "If the queue is full, PutQueue will suspend the task
until there is enough room to insert the data."
> Keep trying to fix it, and let us know what happens.
>
> Eric
Thanks Eric for taking the time to look at this. Yes, ByteCount is an
Integer, I posted it as a byte by mistake. The compiler will
complain if a byte is used.

Right now, I do not have a problem with the OutComm queue filling up,
and like you I am surprised that it does not.

The DataArray size of 1-21 is what I thought the BasicX-24 required.
I am use to using 0 as the first index but in reading the samples and
documentation I have always used the 1 to n size when programming the
BasicX-24.

The queue used by the UART is: Dim OutComm(1 To INPUT_BUFFER_SIZE)
As Byte where INPUT_BUFFER_SIZE = 30 (INPUT_BUFFER_SIZE is not just
for input but I use that constant elsewhere. Bad Name for it)

I am assuming that DataArray(1) goes into OutComm(1) and the UART
first sends out the value stored OutComm(1).

Your comment about PutQueue suspending the task if OutComm is full is
correct and I have had that problem in the past.

Before my program calls the suspect routine, it first checks the
number of bytes via: GetQueueCount(OutComm) and if it is NOT zero, I
simply do a few more things then check it again.

The program should never attempt to place DataArray(x) into OutComm
unless OutComm is empty.

In my testing right now, I should never attempt to place more than 3
bytes at a time into OutComm yet it transmits 2. Even if I wait for
any length of time, that 3rd byte will not be sent until the next
transmission and it will be the first byte.





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
>
> --- In basicx@basi..., "wurlitzer28" <craig.whitley@a...>
> wrote:
> > ...It just does not send the entire packet of 3 or 6 or 9
> > ....21 bytes. It is always one byte less than I expect.
> > The missing byte is the first byte sent in the next packet.
>
> These comments bring to mind a couple of things.
>
> - Inasmuch as RS-232 is not a packetizing protocol, the packets of
> which you speak are entirely of your own creation/interpretation.
How
> are you determining that a given byte is in one "packet" when you
> believe that it should be in another?
>
> - A program can interefere with serial transmission if it disables
> interrupts. This might explain a time lag between when you think a
> byte ought to be transmitted and when it is actually transmitted.
>
> Don Don you bring up a good point and thanks for looking at this.

Only if GetQueueCount(OutComm)=0, do I ever try to add more bytes.
Eventually when this program runs, I will be placing 3,6,9,...21
bytes (or multiples of 3) into DataArray then call:

PutQueue(OutComm,DataArray,ByteCount) where ByteCount will =
3,6,9...21 etc.

I do not use any interrupt calls in my program or any Time related
processing but the CPU, more than likely, does one 512 times a second
for its Tick count.

I can wait for hours and never get the last byte I expect. The
program continues to pulse some outputs so I know it is still
running.

Only at the next event, (value of PortA changed), and I have verified
that the OutComm queue is empty, does that last byte get sent. That
begs the question, why does the OutComm queue show a zero count yet
the missing byte is there?

Don, is it possible some register setting in the CPU is instructing
the UART to behave in this manner?

I have used a VB6 application to read data from the BasicX-24 before
and I know it reads correctly. If there is a byte in the receive
queue of the PC the program reads the byte and posts it to a list
box. Again, I did verify with Hyperterminal that the bytes are
received like my VB application shows. The VB application gives me
the actual values while Hyperterminal just displays characters.

I suppose I could save what little hair I have left and pad the
communication with a bogus byte, but that is a patch and this entire
program is being written to run as fast as possible so adding code
would not be my first choice.




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Craig,
I found the following in 'LCDPlusSerialPort.bas' - This might be the register that you were looking for. I remeber a previous discussion that mentioned that checking Ram location 21 (where NetMedia put the queue flag for Com3) was more effective than StatusQueue for COM3. Not sure if the same applies for COM1 since it is a hardware Com while COM3 is a software Com - give it a shot.

Const TXC As Byte = bx0100_0000
Do While StatusQueue(OutputQueue)
' Null
Loop
Do Until ( (Register.USR And TXC) = TXC )
' Null
Loop wurlitzer28 <craig.whitley@crai...> wrote:
--- In basicx@basi..., "eserdahl@" <eserdahl@p...> wrote:
Right now, I do not have a problem with the OutComm queue filling up,
and like you I am surprised that it does not.

---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., Thad Larson <highwayman_33402@y...>
wrote:
> Do Until ( (Register.USR And TXC) = TXC )

This is intended to determine when the UART has finished sending a
byte. It is a bit tricky to use because you must be certain, before
entering the loop, that the bit will eventually be asserted.
Otherwise, you'll be waiting forever.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wurlitzer28" <craig.whitley@a...>
wrote:
>
> --- In basicx@basi..., "Ingvar Esk" <ingvar.esk@s...>
wrote:
> >
> > > I have DIM'd QueueData (1 to 21)
> >
> > To what?
> >
>
> Thanks for taking the time to look at this Ingvar.
>
> The QueueData is a byte array. I just listed the size in case I
made
> a DIM size mistake.
>
The reason for why I'm asking is if the array would have been
integers, the data content would have been 144,0 xx,0 64,0 or
0,144,0,xx,0,64 depending if MSB is stored first or last (I don't
remember which for BX24). In the first case you put three bytes to
the queue, which whould have been 144,0,xx. 0 is often ignored by
the receiving application, giving that you would only see the two
first bytes.

Ingvar



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> The reason for why I'm asking is if the array would have been
> integers, the data content would have been 144,0 xx,0 64,0 or
> 0,144,0,xx,0,64 depending if MSB is stored first or last (I don't
> remember which for BX24). In the first case you put three bytes to
> the queue, which whould have been 144,0,xx. 0 is often ignored by
> the receiving application, giving that you would only see the two
> first bytes.
>
> Ingvar
>
Thanks Ingvar.

I have my VB application set to handle a byte value of "0" without a
problem. This same application has been used in the past without a
problem receiving data from the BasicX-24

From the NetMedia Documents:
====================
"Queues are also ideal for transmitting data between tasks, because
each queue operation is unbreakable. In other words, once a queue
operation starts, no other task is allowed to run until the
operation is finished."
=====================

From above, I determined that if I tell the PutQueue routine to send
3 bytes to the OutComm for Comm Port 1 it should send them as a
packet. And in fact using the same VB program on other projects it
has.

I think the tip off is if I wait for an extended period of time and
that last byte is not received (can be any value from 0 to 149) and
then I press the "reset" button on the development board the missing
byte is sent. Just one byte, no more, no less.

I am looking at any register setting that could cause this but so far
I have not found anything.

My VB application time stamps each packet and if all the bytes are
not received the time stamp has little meaning.

If I don't find this today, I am going to take a controller out of
another project and load this program just in case I am fighting a
hardware problem.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
>
> --- In basicx@basi..., Thad Larson <highwayman_33402@y...>
> wrote:
> > Do Until ( (Register.USR And TXC) = TXC )
>
> This is intended to determine when the UART has finished sending a
> byte. It is a bit tricky to use because you must be certain,
before
> entering the loop, that the bit will eventually be asserted.
> Otherwise, you'll be waiting forever.
>
> Don
>
Ah, this does shed some light on the problem (I think), it does hang
and thinking about it, it should. That last byte must still be
sitting somewhere in the UART buffer. Now the trick is to get it out.

Don, I appreciate you and the group taking the time to investigate
this with me.

Craig





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wurlitzer28" <craig.whitley@a...>
wrote:
>... this does shed some light on the problem (I think) ...

You might want to review the full source code from which that was
excerpted. The purpose of the module is to be certain that all
characters to be transmitted have been sent. You can find the source
code at:
http://www.basicx.com/codeexamples/files/FlushSerialPort.bas

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> You might want to review the full source code from which that was
> excerpted. The purpose of the module is to be certain that all
> characters to be transmitted have been sent. You can find the source
> code at:
> http://www.basicx.com/codeexamples/files/FlushSerialPort.bas
>
> Don Thanks Don!
Here is what I have done.

I pasted the FlushSerialPort.bas code into my project but remarked out
anything related to comm2 or 3.

Even though I have sent byte values of "0" with success before, I
changed the code so the byte value range was 1 to 149.

At the first attempt to send data the program halted.

Using the LEDs on the BasicX-24 I sequenced them to see where the
program halted.

As Green=On, Red=off when the program halted, I determined that the
device is hung up on the:

"Do While StatusQueue(OutputQueue)
' Null
Loop Here is the data to be sent to OutComm:
QueueData(1)=144, QueueData(2)=23, QueueData(3)=1, ByteCount=3

============= Code segment to determine hang point ========

Call PutPin(GreenLED, LEDoff) 'indicates PutQueue command
Call PutPin(RedLED, LEDon)
Call PutQueue(OutComm, QueueData, ByteCount)

I then called "FlushOutputBuffer" from the code you referenced.

Segment from "FlushOutputBuffer"
Call PutPin(GreenLED, LEDon)'
Call PutPin(RedLED, LEDoff)
Do While StatusQueue(OutputQueue)
' Null
Loop
Call PutPin(GreenLED, LEDoff)
Call PutPin(RedLED, LEDoff)

========= End Code Segment =========================




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> From the NetMedia Documents:
> ====================
> "Queues are also ideal for transmitting data between tasks,
because
> each queue operation is unbreakable. In other words, once a queue
> operation starts, no other task is allowed to run until the
> operation is finished."
> =====================
>
> From above, I determined that if I tell the PutQueue routine to
send
> 3 bytes to the OutComm for Comm Port 1 it should send them as a
> packet.

What the above stement means is that the PutQueue (and GetQueue) is
a so called atomic operation. If you would have two different tasks
trying to put A,B,C and 1,2,3 respectivily into the queue, there is
no risk that the queue will be filled with A,1,B,2,C,3 or any other
combination, only A,B,C,1,2,3 or 1,2,3,A,B,C is possible.

And in fact using the same VB program on other projects it
> has.
>
> I think the tip off is if I wait for an extended period of time
and
> that last byte is not received (can be any value from 0 to 149)
and
> then I press the "reset" button on the development board the
missing
> byte is sent. Just one byte, no more, no less.
>
> I am looking at any register setting that could cause this but so
far
> I have not found anything.

First check with Hyperterminal what the raw data stream looks like.
I think it could be that your application receives three bytes (not
exactly the ones you expect but with extra nulls or something in it)
then it starts to listen for the next three bytes and then it gets
the last byte but doesn't display it as it waits for more bytes.
When you press Reset you actully sends a continious stream of Null
bytes (without the stop bits). These null bytes fill up the rest of
your three byte receiving buffer and then shows the "lost" byte.

> My VB application time stamps each packet and if all the bytes are
> not received the time stamp has little meaning.

> If I don't find this today, I am going to take a controller out of
> another project and load this program just in case I am fighting a
> hardware problem.

I'm sure it's not a HW problem. You have a mismatch in the
communication. Use Hyperterminal or a simple VB app that displays
each byte as it is received, to make sure your BX-app sends what you
expect it to do.

Good luck
Ingvar





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Shouldn't the statement be:

Do While StatusQueue(OutComm)
'null
Loop wurlitzer28 <craig.whitley@crai...> wrote:

"Do While StatusQueue(OutputQueue)
' Null
Loop Here is the data to be sent to OutComm:
QueueData(1)=144, QueueData(2)=23, QueueData(3)=1, ByteCount=3

---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.

[Non-text portions of this message have been removed]



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., Thad Larson <highwayman_33402@y...>
wrote:
>
> Shouldn't the statement be:
>
> Do While StatusQueue(OutComm)
> 'null
> Loop > wurlitzer28 <craig.whitley@a...> wrote:
>
> "Do While StatusQueue(OutputQueue)
> ' Null
> Loop FOUND THE PROBLEM!!!!

Yes, Thad I guess I was being to literal in my postings by using
the " to indicate what I had written in the code and that is
confusing. I'll stop it.

To Thad, Ingvar Esk, Don Kinser, Eric Serdahl, I thank you all for
sticking with this thread.

Looking back to the NetMedia supplied SerialPort.bas file, I noticed
a remarked out statement:
=====================================================
' Com1 requires that the network be disabled. On the BasicX-01
' Developer Board, it may be necessary to raise pin 14, which can
be
' done here or in the chip I/O initialization.
'>>If (PortNumber = 1) Then
'>> Call PutPin(14, bxOutputHigh)
'>>End If
==========================================================

Now, I am running a BasicX-24 on the NetMedia development board not a
BasicX-01 however, by placing, Call PutPin(14, bxOutputHigh) into my
initialization for Comm1 the problem went away.

At this time I don't care if it should or should not be required it
works and I don't need Pin 14 for anything (I just have to move some
wiring).

Does anyone know if after initialization can pin 14 be used for all
normal digital I/O functions?

Thanks again gang!
Craig




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wurlitzer28" <craig.whitley@a...>
wrote:
> Does anyone know if after initialization can pin 14 be used for all
> normal digital I/O functions?
Well, since pin 14 SHOULDN'T affect Com1 (afaik), then its use for
normal I/O purposes should not be a problem.

Now that it is working, try taking the initialization back out and see
what happens....

-Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Thanks Tony, sorry it has taken so long to reply. Removing the code
as you suggested did bring back the problem, 3 bytes should have been
sent but only 2 received. While that problem seems to be addressed
another underlying problem surfaced and I did not want to bother the
group until I had pushed it as far as possible

If I leave the BasicX Downloader program running after a download, I
can generate as much traffic as I want and the X-24 keeps right on
trucking. While I cannot read the byte data (just a bunch of ''',
squares and @), I can tell that I am getting the group of 3 bytes as
expected. No problem at all.

However, if I close the BasicX Downloader program and launch either
my VB application, Hyperterminal or Teraterm, I still get the groups
of 3 bytes sent (at least with the VB program I can read the actual
data), but if I try to push a bunch of transmissions quickly, the
program halts right where I call the PutQueue statement.

This is getting to the point where I may give up on the BasicX-24.

Before I even call the sub-routine that will call PutQueue, I do the
following check:
============================================
QueCount = GetQueueCount(OutComm)
If QueCount = 0 Then
'call routine which contains the
' PutQueue(OutComm, QueueData, ByteCount) statement
========================================================

As you can see, I should never do a PutQueue unless QueCount=0.
I even tried putting a 2nd check for an empty queue right before the
PutQueue with the same result. It hangs on 3 different PC program but
not the BasicX Downloader monitor program.

I even rewrote the program to make sure the scan,transmission sub-
routines were the only parts of the program that could ever be
called. No help.

I am beyond grasping at straws. This is just RS232 communications and
it should not be that difficult.

Craig --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
>
> Well, since pin 14 SHOULDN'T affect Com1 (afaik), then its use for
> normal I/O purposes should not be a problem.
>
> Now that it is working, try taking the initialization back out and
see
> what happens....
>
> -Tony




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> I am beyond grasping at straws. This is just RS232 communications
and
> it should not be that difficult.
>
How about to publish all of your code, instead of snippets. It would
be much easier to help you then.

Ingvar





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Wow, that is weird.

I do not see how pin14 should have any bearing on the functions of
Com1 within the BX hardware.

You clearly find that something about the pin is causing your
program to glitch. So what is it? It really seems as if you have
checked it out pretty well.

But, the IDE terminal is only a very simple Serial terminal. No
translation that I know of. So, if the data is coming in over to
the IDE terminal (or so it seems) and other PC terminal programs do
not work, then I would suspect that it is data translation on the PC
side that is hanging things up as fas as losing the last byte goes.

When I really get screwy results, I try to simplify the program as
much as possible and try to isolate the problem that way.

I delete all the code that I can and run just barebones. In this
case, I would delete everything except the serial communications.
Just write 3 bytes of dummy data to the queue. I would write it at
about the same timing as the real stuff would come. I would use
values similar to the real stuff.

Then I would see what happens on the PC end. IF that works, then I
would add stuff to generate the real data, but no other bells and
whistles.

Usually when I strip it and add stuff function by function, I get
the problem....usually. Not so with my latest project of trying to
interface a MMC card to the BX.

.........
I just had a thought. I have had Com1 problems when I used com1 for
debug.prints AND queue-type I/O Try using Com3 for the data
transmission. This way there can be no collisions of the data. You
would have to move the serial cable from the com1 plug to another
plug. As for giving up on the BX-platform. I have done stuff with a bunch
of microcontrollers. The BX is one of the MOST forgiving around.

It does have program space and RAM limits, but it is decent, with
very little hardware and software overhead.

-Tony





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Ingvar Esk" <ingvar.esk@s...> wrote:
>
> > I am beyond grasping at straws. This is just RS232 communications
> and
> > it should not be that difficult.
> >
> How about to publish all of your code, instead of snippets. It
would
> be much easier to help you then.
>
> Ingvar
>
Ok! Here are the only active sub-routines. I have gutted the normal
play and playback modes from the code.

Main will always switch to RECORD MODE:
Different values for Baud rate have been tried. Eventually, it will
have to be the stupid 31.2k rate for MIDI.

This code sends all the characters expected but will hang on
Hyperterminal, TeraTerm, and my VB application if I change the value
of port A quickly. It will NOT hang using the BasicX Downloader
Monitor window.

==============MAIN=======================
Public Sub Main()
'InitializeMain 'CHANGE THIS AFTER TESTING
OperationMode = PLAY
'Do'CHANGE THIS AFTER TESTING
If GetPin(PinRecord) = 1 Then 'active low NOTE:CHANGE THIS AFTER
TESTING
OperationMode = RECORD
End If
'If GetPin(PinPlayback) = 0 Then 'active low
'OperationMode = PLAYBACK
'End If
Select Case OperationMode
'Case PLAYBACK
'ClearKBArray 'reset array for all keys off
'InitializePLAYBACK
'PlaybackMode 'go into playback loop and stay there until
playback is done
Case RECORD
InitializeRECORD
ClearKBArray 'reset array for all keys off
RecordMode
'Case PLAY
'InitializePLAY
'PlayMode
End Select
'LOOP 'CHANGE THIS AFTER TESTING
End Sub

Public Sub InitializeRECORD()
Register.DDRA = bx0000_0000
Call OpenQueue(InComm, 10)
Call OpenQueue(OutComm, INPUT_BUFFER_SIZE)
Call PutPin(14, bxOutputHigh) 'may be required to initialize port.
see SerialIO.bas MAKES NO SENSE BUT WORKS
Call Delay(1.1)
Call OpenCom(1, COMM_BAUD_RATE, InComm, OutComm) 'port for PC
communication
Call Delay(1.1)
Call ClearQueue(InComm)
Call ClearQueue(OutComm)
OperationMode = RECORD
End Sub '==[[[[ This routine generates clock and strobe signals
'and looks for any changed data from one scan to the next
'on Port A]]]]]]]]]
Public Sub RecordMode()
Dim ScanClockCount As Byte
Call PutPin(GreenLED, LEDon)
Call PutPin(RedLED, LEDoff)
Do
'============= Send out single data high to start scan ============
Register.PORTC = cl_sl_dl 'Clock Low, Strobe Low, KB Data Low
Register.PORTC = cl_sl_DH 'Clock Low, Strobe Low, KB Data High
Register.PORTC = CH_sl_DH 'Clock High, Strobe Low, KB Data High
'************** End ***********************************************

'============== Compare KB Input after first clock pulse =========
If Register.PINA <> KBArray(1) Then 'compare with last scan data
QueCount = GetQueueCount(OutComm)
If QueCount = 0 Then
KBArray(0) = Register.PINA 'Store data for comparison
Call FormatMidiBytes(1) 'prepares MIDI data to be sent at end
of pipe scan
KBArray(1) = KBArray(0) 'Store data for comparison
End If
End If
'************** End first clock pulse compare ********************

'============= Scan rest of notes 2 to 61 and compare the KB common
for changes ======
Register.PORTC = cl_sl_dl 'Clock Low, Strobe Low, KB Data Low
For ScanClockCount = 2 To 61 'complete Keyboard scan (61) and full
pipe update (96)
Register.PORTC = CH_sl_dl 'Clock High, Strobe Low, KB Data Low
Register.PORTC = cl_sl_dl 'Clock Low, Strobe Low, KB Data Low
If Register.PINA <> KBArray(ScanClockCount) Then 'compare with
last scan data
QueCount = GetQueueCount(OutComm)
If QueCount = 0 Then
KBArray(0) = Register.PINA 'Store data for comparison
Call FormatMidiBytes(ScanClockCount) 'prepares MIDI data to
be sent at end of pipe scan
KBArray(ScanClockCount) = KBArray(0) 'Store data for
comparison
End If
End If
Next
'*************** End of KB scan **************************************

'============== Finish clock pulses required to update pipe drive
boards =========
For ScanClockCount = 62 To 96
Register.PORTC = CH_sl_dl 'Clock High, Strobe Low, KB Data Low
Register.PORTC = cl_sl_dl 'Clock Low, Strobe Low, KB Data Low
Next
Register.PORTC = cl_SH_dl 'end of KB scan and Pipe driver update
send latch data to outputs
'*************** End of pipe driver update and end of this complete
scan ********

If GetPin(PinRecord) = 0 Then 'record mode has been switched off
NOTE:CHANGE THIS AFTER TESTING
Exit Sub
End If
Loop
End Sub
'NOTE this routine ONLY entered if current PortA value is
'different from last scan
Private Sub FormatMidiBytes(ByVal NoteNum As Byte)
Dim tmpBitMask As Byte, Q_count As Integer
tmpBitMask = KBArray(0) Xor KBArray(NoteNum) 'sets tmpBitMask to any
bits that have changed
If (tmpBitMask And Bit5) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 149 'channel 6 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit5) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
If (tmpBitMask And Bit4) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 148 'channel 5 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit4) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
If (tmpBitMask And Bit3) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 147 'channel 4 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit3) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
If (tmpBitMask And Bit2) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 146 'channel 3 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit2) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
If (tmpBitMask And Bit1) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 145 'channel 2 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit1) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
If (tmpBitMask And Bit0) > 0 Then 'this bit has changed since last
scan
ByteCount = ByteCount + 1
QueueData(ByteCount) = 144 'channel 1 message
ByteCount = ByteCount + 1
QueueData(ByteCount) = NoteNum 'Note Number
ByteCount = ByteCount + 1
If (KBArray(0) And Bit0) > 0 Then
QueueData(ByteCount) = 0
Else
QueueData(ByteCount) = 64
End If
End If
Call PutPin(GreenLED, LEDoff) 'indicates transmitting
Call PutQueue(OutComm, QueueData, ByteCount) 'send all data for this
note
Call PutPin(GreenLED, LEDon)
ByteCount = 0
End Sub

Public Sub ClearKBArray()
Dim Lc As Byte
For Lc = 1 To 61
KBArray(Lc) = 255 'all keyboard commons are high when no note is
played
Next
End Sub

Option Explicit
'/////////////////////////////////////////////////////////////////////
///////////

Const PinClock As Byte = 5 'interrupt pin Port C bit 7 OUTPUT 128
Const PinStrobe As Byte = 6 'Port C bit 6 OUTPUT 64
Const PinKBDataBit As Byte = 7 'Port C bit 5 OUTPUT 32
Const PinRecord As Byte = 8 'Port C bit 4 INPUT ACTIVE LOW 16
Const PinPlayback As Byte = 9 'Port C bit 3 INPUT ACTIVE LOW 8

Const GreenLED As Byte = 26
Const RedLED As Byte = 25
Const LEDon As Byte = 0
Const LEDoff As Byte = 1

Const PLAY As Byte = 0
Const PLAYBACK As Byte = 1
Const RECORD As Byte = 2
Const INPUT_BUFFER_SIZE As Integer = 30 '33 'data bytes + 9 overhead
bytes

Const cl_sl_dl As Byte = 24
Const CH_sl_dl As Byte = 152
Const cl_SH_dl As Byte = 88
Const cl_sl_DH As Byte = 56
Const CH_sl_DH As Byte = 184
Const Bit0 As Byte = 1
Const Bit1 As Byte = 2
Const Bit2 As Byte = 4
Const Bit3 As Byte = 8
Const Bit4 As Byte = 16
Const Bit5 As Byte = 32
Const Channel_1 As Byte = 144
Const Channel_5 As Byte = 149
Const SysCommonLo As Byte = 240
Const SysCommonHi As Byte = 247
Const RealTimeLo As Byte = 248
Const RealTimeHi As Byte = 255

'=====================================================================
=======
Dim InComm(1 To INPUT_BUFFER_SIZE) As Byte 'handles NUMBER_DATA_BYTES
plus 3 system bytes and 9 overhead bytes
Dim OutComm(1 To INPUT_BUFFER_SIZE) As Byte
Dim QueueData(1 To 21) As Byte 'used to store data for xfer in or out
of communication queues
Dim KBArray(62) As Byte 'image of Keyboard
Dim OperationMode As Byte
Dim ByteCount As Integer
Dim QueCount As Integer
Dim blBlink As Boolean
Const COMM_BAUD_RATE As Long = 19200





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I can't see that ByteCount is initialized before the first use. Can
cause you to overwrite other parts of the memory, with unpredictable
results.

Ingvar

> Private Sub FormatMidiBytes(ByVal NoteNum As Byte)
> Dim tmpBitMask As Byte, Q_count As Integer
> tmpBitMask = KBArray(0) Xor KBArray(NoteNum) 'sets tmpBitMask to
any
> bits that have changed
> If (tmpBitMask And Bit5) > 0 Then 'this bit has changed since last
> scan
> ByteCount = ByteCount + 1
> QueueData(ByteCount) = 149 'channel 6 message
> ByteCount = ByteCount + 1
> QueueData(ByteCount) = NoteNum 'Note Number
> ByteCount = ByteCount + 1
> If (KBArray(0) And Bit5) > 0 Then
> QueueData(ByteCount) = 0
> Else
> QueueData(ByteCount) = 64
> End If
> End If




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

You are right Ingvar that was sloppy on my part. It did not fix the
problem but it sure could cause an error with the very first
transmission if ByteCount was at some large value. ByteCount was set
to zero after the first transmission but that is not right. I moved
it to the top of the FormatMidiBytes sub.

I'll keep digging.

Thanks again Ingvar. --- In basicx@basi..., "Ingvar Esk" <ingvar.esk@s...> wrote:
>
> I can't see that ByteCount is initialized before the first use. Can
> cause you to overwrite other parts of the memory, with
unpredictable
> results.
>
> Ingvar
>
> > Private Sub FormatMidiBytes(ByVal NoteNum As Byte)
> > Dim tmpBitMask As Byte, Q_count As Integer
> > tmpBitMask = KBArray(0) Xor KBArray(NoteNum) 'sets tmpBitMask to
> any
> > bits that have changed
> > If (tmpBitMask And Bit5) > 0 Then 'this bit has changed since
last
> > scan
> > ByteCount = ByteCount + 1
> > QueueData(ByteCount) = 149 'channel 6 message
> > ByteCount = ByteCount + 1
> > QueueData(ByteCount) = NoteNum 'Note Number
> > ByteCount = ByteCount + 1
> > If (KBArray(0) And Bit5) > 0 Then
> > QueueData(ByteCount) = 0
> > Else
> > QueueData(ByteCount) = 64
> > End If
> > End If




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Ingvar Esk" <ingvar.esk@s...> wrote:
>
> I can't see that ByteCount is initialized before the first use. Can
> cause you to overwrite other parts of the memory, with
unpredictable
> results.

Ingvar, as I posted a little while ago, this did not fix the problem
but it sure pointed me in the right direction.

When I was looking at the initialization issue I though, what if the
routine was called even though there were not bits that had changed.
It was my intention to never call this routine unless data had changed

I would have been calling PutQueue(OutComm,DataArray,ByteCount) with
a ByteCount=0. PutQueue does not like that at all.

Again, thanks to all on the BB who took the time to help me.

The RecordMode sub now looks like this: All subsequent processing
uses KBArray(0)
================================================
KBArray(0) = Register.PINA 'Store data for comparison
If KBArray(0) <> KBArray(ScanCount) Then 'compare last scan data
QueCount = GetQueueCount(OutComm)
If QueCount = 0 Then
Call FormatMidiBytes(ScanCount)
KBArray(ScanCount) = KBArray(0) 'Store for next scan comparison
=========================================================

Here is the original code where data could change before the
processing was completed:

=============================
If Register.PINA <> KBArray(ScanClockCount) Then
QueCount = GetQueueCount(OutComm)
If QueCount = 0 Then
KBArray(0) = Register.PINA '!!!DATA COULD HAVE CHANGED ERROR
Call FormatMidiBytes(ScanClockCount)
KBArray(ScanClockCount) = KBArray(0) 'Store data
End If





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )