Serial problems

[peter247]

As anyone managed to get the serial working the way I want it ?

I want to get the bv513 to receive to command via serial from a second
microcontroller ( a Arduino ) and act on the command.
I’m using some processes so I can’t use any blocking functions.

I’ve check with the key? function every few ms, to see what’s in the
buffer and outputting it.
I don’t get my test message which I’m sending every two second @ 9600.
I’ve tried the below which worked partly.

Any help

function init
opencom 1 9600 0
dim a$
keep
process check_serial every 1
endf

function check_serial
a=inp(1,a$,2000,13)
if a > 0 then
print a$
endif
endf

[peter247]

I think it`s a bug !!!!

I`ve sending out "TEST" evey 2 seconds from the other computer @ 9600

with the below code , check_serial1 gives only T where check_serial2
gives TEST, but just add a extra print and I`ve lost a char and get
TES

So I think the buffer is getting killed too quick to do any work with
the incoming data .

Which makes the serail fuction useless !!!!!!!

function init
opencom 1 9600 0

process check_serial2 every 500
endf

function check_serial1
dim b&
while key?(1) <> 1
b& = key(1)
print chr$(b&) <-- this give only t
wend
endf

function check_serial2
while key?(1) <> 1
print chr$(key(1))
// print "-" <--- add this and it give t-e-s-
wend
endf

[Ian macdonald]

Hi Peter,

Not really an answer to your problem, but I was wondering if you had
tried using the bv513 sending serial to processing? It might be an
idea to make sure both boards can send the correct data to a
processing sketch running on your pc first and then work on getting
them to talk with each other.

I am wondering if I can port something like the firmata or Messenger
toolkits to the bv513

Cheers

Ian

[peter247]

I think the bv513 has major buffer problems.
the buffer is very fast to get killed , So it’s impossible use.

I think sending data from the bv513 will work because You are relying
on the Ardunio`s buffers and interrupts, which are tried and tested to
work.
The only way I can think of getting around it is to make an Arduino
Serial-2-i2c buffer unit, but that’s getting a little silly have a Co-
processor just to handle serial communication correctly.

On Oct 1, 9:41 am, Ian macdonald <ianma...@googlemail.com> wrote:
> Hi Peter,
>
> Not really an answer to your problem, but I was wondering if you had
> tried using the bv513 sending serial to processing?  It might be an
> idea to make sure both boards can send the correct data to a
> processing sketch running on your pc first and then work on getting
> them to talk with each other.
>
> I am wondering if I can port something like the firmata or Messenger
> toolkits to the bv513
>
> Cheers
>
> Ian
>

[Jim]

There is an issue with serial buffering and this is to do with the
PIC32 itself which doesn't have any, other than
the single receive byte. It is a problem that is going to be resolved
in the next release by implementing a software
buffer, I just haven't worked out the best way to do it.

The work round is to use hardware handshaking like this:

constant CTS "e1" // can use any free ports for these
constant RTS "e2"

opencom 1 9600 0, CTS,RTS // note the comma's

RTS is an output and the BV513 will hold this low when it is ready to
accept characters, the sending processor
(Arduino in this case) must check that this line is low before sending
anything otherwise it will be ignored by the BV513.
What will happen is that the BV513 will receive the charter and set
RTS high, it will remain high until it is read by the inp()
command so no characters will be lost. Even with a single buffer
transfer rates exceeding 115200 should be possible.

CTS is the opposite, the BV513 will not send out a byte unless this is
low, to implement just RTS so the BV513 will
send out a byte as soon as it gets one from Basic the syntax is:

opencom 1 9600 0,,RTS

Jim

On Sep 30, 7:58 pm, peter247 <peter224...@gmail.com> wrote:

[Jim]

Opps
should be:
constant CTS$ "e1"
constant RTS$ "e2"
Jim

[peter247]

I`ve looked at that , but the devices I`m going to be using it with as
only rx and tx and flow control.

[peter247]

oops No flow control

[Jim]

Peter,
if you can't do flow control then the other alternative is to increase
the time out on the inp() from
say 2000 to 5000 to 10000. Although the numbers are big the actual
delay is quite small. I find that 5000
works with the ASI devices that don't have flow control but there are
occasional problems.

Come to think of it, that was the reason why the inp() statement had a
time out because of the single hardware
buffer that was provided with PIC. The inp() is a kind of pseudo
buffer.

I have put a few thoughts down here more of a discussion than an
actual solution which may clear up a few points, if I could use your
code as an example,
my comments are followed by !! as I can't change the colour of font.

!! This sets up a schedule to check the incoming serial stream which
is one way of doing it
!! As it stands the check will take place every 1/2 second

function init
opencom 1 9600 0

process check_serial2 every 500
endf

!! The while statement should not be used within a schedule: what
happens if it is still in this loop
!! and gets called again? The schedule itself is the loop process
function check_serial2
while key?(1) <> 1 !! I don't think this is correct as when a key is
available key?(1)=1 **

print chr$(key(1))
// print "-" <--- add this and it give t-e-s-
wend
endf

** This will print the char when there is no key available??

!! This is an alternative; when this is called if no key is available
then it does nothing and returns
!! if a key is available then it gets the string using the while
statement. There are two possible problems with this
!! 1) The while could take longer then 1/2 second and get called twice
!! 2) A key could be missed if the while returns between characters,
inp() statement would help to prevent that see **** later
function check_serial2
if keyq(1) = 1
while key?(1) = 1

print chr$(key(1))
// print "-" <--- add this and it give t-e-s-
wend

endif
endf

!! Another alternative, but because there is only a single byte buffer
calling this every 1/2 second
!! will miss some characters. At 9600 a character will be received
every 1 ms so reducing the time may
!! help
function check_serial2
if key?(1) <> 0

print chr$(key(1))
// print "-" <--- add this and it give t-e-s-

endif
endf


**** The first post was nearly the solution, I suspect that what was
happening with this is that the 1ms schedule time and the 2000 delay
did not match up and the function was being called whilst still in the
function
I have not tested the function below but the theory is that if a char
is not available then it simply returns, if a char is available then
it will attempt to get the whole string until #13 is received. The
value of 400 needs to be found by trial and error and should be set to
that it does not time out between characters. It is not really
practical to call this on a schedule as the length of time this
function takes to execute will depend on how many characters it
receives.

function check_serial
if key?(1) <> 0 then
a=inp(1,a$,400,13)

if a > 0 then
print a$
endif

endif
endf

Yet another solution: how about implementing the buffer in Basic?
Using key?() as soon as a charter is received then put it into an
array, this could be done with a tight schedule and at 1ms should be
able to catch all characters for 9600 Baud. The down side is that it
would need a circular buffer implementing which complicates matters. I
have done a similar thing with the keypad example.

I hope this was informative and there are probably a few mistakes for
which I apologise, none of the code mentioned was tested so it may not
work (theory only). As I mentioned before the next release which is
due very shortly will have software buffers implemented and so much of
the above is academic but possibly interesting.

Jim

[peter247]

O.k., I may have got confused about a function, so I’m just checking
for clarification.

Is process a interrupt ?

Eg

process Task_1 every 1
process Task_2 every 1000

If Task_2 is a bubble sort which takes half a second to complete and
Task_1 is a very fast check the Rx buffer.

Will Task_1 stop running for the half a second when Task_2 is Blocking
it ?.

My idea is that it would but from your last statement I may have got
it wrong.

Now I know what the problem is I`m sure I fix it !!!

[Jim]

Peter,
the process is an interrupt and yes the schedule will only process one
interrupt at a time, there is no priority that can be set.

I was wrong about the PIC, it does actually have a 4 byte depth
buffer, not much so I am still contemplating increasing this in
software. Whilst looking at this subject I also noticed that some
documentation information is missing from key?() (now fixed) and that
is it will return -1 when an overflow occurs. The following will work
but only at 9600 Baud, anything over 4 characters causes an overflow
if the Baud rate is increased.

//
-----------------------------------------------------------------------------
// sending device
function out_send
out$ 1 "test"+*13
endf

function sending
opencom 1 9600 0
process out_send every 2000
endf

//
-----------------------------------------------------------------------------
// Receiving device
function init
dim a$[:20]=""
opencom 1 9600 0
ia_clr
keep
process check_serial every 5
endf

function check_serial
dim k
k = key?(1)
if k <> 0 then
if k > 0 then
inp(1,a$,2000,13)
print a$
else
print "overflow"
endif
endif
endf

User interrupts are in the next release so I suspect that something
like

on com1 do function xx

would be useful. But what is more useful, a bigger input buffer or an
interrupt? The interrupt function is still likely to need some
buffering by the user.

[peter247]

I’ve tried a two stage process trying to read from the buffer every
1ms and put that in a string variable, even that doesn’t have time to
work.

I think if got to be a bigger buffer filled by a high priority
interrupt with code written in c / c++ assembler etc.