I suggest if you are interested in this system you make
 a folder and drag over all the many future messages on this
 subject otherwise delete it.

I did a bit of testing to see how much time
certain communications routines and other routine took
to send data to the PC. When the engine
is running at 7500 RPM the program
has only 8 ms to do everything in needs to do in
one rev of the engine.

One of the longest job is sending data to
the netbook in the cockpit due to the limitations
of the USB serial interface.

While RPM is high it may be necessary to suspend
sending data and store the data in RAM and send
it out later.

Debug.Print is one way of sending data.

Here is the simple command that sends data to the netbook:
Debug.Print CStr(x)

CStr() converts the integer to an ASCII number character
to make it human readable. That too takes time of course

x is an integer number limited to +/- 32000

It takes .3 ms to convert and send a four digit integer (say RPM).
Just sending four ASCII characters takes only .1 ms
at a bit rate of 57,600.  Each ASCII character is made up
of 8 bits roughly. The other two .1 ms times was due to conversion.

BTW my HP notebook computer was not fast enough to display
these characters. The characters were just a garbled blur on
the screen. The would have to be stored in a file of some
sort. Perhaps on a USB stick

Debug.Print will also send the data out without converting
it to ASCII (32 bit binary number) for but it takes the same time
for some strange reason. You might as well send it out in ASCII
so people can read it.
Here is what my test program looks like. I triggered the scope
on the rising edge of the pulse.

-----------------------------

WARNING<<<<<<

Do not change the baud rate in the serial options menu.

------------------------------------------------------

Mark,

I talked to Don and he said it is essential to start
with a project. One can program with out a project
but a lot of error messages do not show up. The project name
must not be the same as the program name.

Here is what he said. I'll fool with it some and give
you more info later.

Posts: 1957
Location: Portland, OR
    
Posted: 18 May 2010, 19:45 PM    Post subject: Re: errors occurred in the back-end build process     Reply with quote
Paul Lamar wrote:
What could that be?
The back-end build process is the final stage of converting the ZBasic code to AVR executable code. Normally, this phase will complete without error but there are a number of things that can go awry. To determine what's going on we need more information.

One way to get this information is to add the --verbose option to the project file. You do this by selecting the "Open Project File" entry from the Options menu of the IDE. Your project file will appear in one of the tabbed windows. Add the following line near the the top of the project file:
Code:
--verbose
. Now, when you press F7 to compile the project you'll get a stream of command lines and other information appearing in the Output window of the IDE. If an error does occur in the back-end build process, it will be visible in that message stream. The entire block of text can be selected using the mouse and copied to the clipboard using ctrl-C. Then, you can paste it in the edit box (surrounded by "code" tags) in a forum post.

It could be that your reader is using an older version of the compiler that might have a bug in it that your newer version doesn't have. You can determine the version of the compiler being used by selecting "About ZBasic IDE" from the Help menu. The compiler version is shown on the line below the IDE version number.