www.coridium.us/forum

> FTDI's handshake to Armmite

While the BASIC program is running there is no handshaking between the
2103 and the FTDI232 part.

On the 2103 inbound side, there is a 16 byte hardware FIFO and an
interupt serviced 128 byte buffer. So there should not be an overun
on receiving data, unless the BASIC program never reads it.

Internal to the 2103 there is an outbound 16 byte FIFO, which will
accept a character from the BASIC program until that FIFO is full, at
which point the BASIC program sending bytes out UART0 (via PRINT or
the like) will wait until the bytes can be accepted.

The DTR and RTS lines asserted by the FTDI232 are used for controls.
DTR low will reset the ARMmite, and RTS is used for download control
by the GCC downloader.

PS we have posted a very preliminary version of the GCC for the
ARMmite/ARMexpress. The MakeItC program and compiler are working, but
the documentation is still being revised. If you do switch to C it
will overwrite the BASIC support on the ARMmite/ARMexpress

> Hi Guys,
>
> Was there ever a resolution to this problem?
> Whats the story with the second serial port?
>
> Kind thanks,
> Serge


Hey Serge.

I'll defer to basicnode (Bruce) to speak to ARMbasic's support of the
2nd serial port.

I can tell you that the serial data stream reception on a GPIO pin had
frustrated me for some time, but with Bruce's patient counsel, was able
to get past it.

His team was kind enough to make some changes to the compiler and
firmware for both the ARMmite and the ARMexpress (Yes, I got an
ARMexpress / USB eval board too! .

The changes were the way SERIN ceased data collection and returned to
the user program upon receipt of a CR, LF, or null (Bruce, chime in here
if I am in error). Originally, the code waited to exit until a delay of
.5 seconds had elapsed. With a delay like that in my control loop, I
was experiencing substantially lower updates per second than what I
needed.

However, finally, with some help and gentle nudging by the kind Sir
Bruce, I had gotten the simple control loop executing >10000 Control
Loops Per Second (CLPS) between GPS sentence reception iterations.
(That high CLPS rate has since decreased since I have expanded
functionality of the control loop, however, the reduction is not due to
the serial data reception on the GPIO pins, but rather the increased
functionality of the control loop...)

The problem that I was experiencing after Coridium updated SERIN, did
not have it's roots in the underlying hardware/'OS', but rather in three
other contributing factors:

1) The GPS receiver module does not support a query/response protocol,
and

2) The GPS receiver module sends ALL data once per second in a single
burst with any delay between sentences being minimal (non-existent,
really), and

(i.e. all of the delay was between the last sentence and the first
sentence of the next burst - depending on the baud, anywhere from
no-delay (at really low baud rates with all sentences turned on, and
burst-to-burst periods of nearly 850 milliseconds when operating @
115.2K)

3) I was taking each sentence received, and trying to parse it and
return to the 'listening' only after the previously received sentence
was fully parsed - a fundamental error that Bruce was kind enough to see
on the front end, and used that knowledge to guide me toward
'discovering' it myself near the end of my struggles.

Later today (or tomorrow as I have to get some other work done first), I
will post up the appropriate portions of my source that deals with the
GPS serial data stream reception. I'll include the parsing portions as
well, in the event that it may be of interest/use to someone.

...

If I get enough feedback here, I may post all of the code modules.
However, before I post any code, I will need to go through and edit the
commenting as I have changed things quite a bit, and have been remiss on
adding/editing comments accordingly...

(Yes, code-modules: My source code, with quite a bit of commenting, had
grown to ~80K for a single file. Editing it was becoming cumbersome,
finding specific sections of code in all the 'noise' of a large
well-commented file was becoming difficult. I had quietly suggested to
members of the Coridium team that it would be nice if the user community
could make use of an #include compiler directive and be able to break
the source up across several files, and a few hours later, TCLterm was
modified to facilitate exactly that through the use of an existing
preprocessor! Excellent customer service response by providing a needed
feature in response to a simple suggestion. Download the latest files
from the website...)

Let me know if there is interest in seeing all of the code, and how I am
using the GPS provided data, and implementing ARMbasic navigation
algorithms, to begin the process of facilitating control of a mobile
system.

I hope that this helps to answer your question, Serge. Please review
and advise if additional information is needed.

Have a good one!

-t