Re: The correct code

Good morning,

>>This code works fine. But I have the message "NO XTL port".
>>So it's not possible to test interactively.
>>That's why I think TESTER BUILD should always be immediately followed by
>>TESTER ACTIVATE.
>
>That message is an indication of a procedural error, that you have not
>established an XTL connection. Remember that with an AVR you need to do a
>new download and DEBUG every time you change your kernel.

There was an XTL connection, the code
had even been loaded with PROJECT-BUILD and then RELOAD!.
The code was accepted in the target,
in the flash programming box I could see the procedure was complete.
And it is after the load that the message came up
together with the COM option box.
But in the target everything went as I wanted: no flashing
until I pushed the start switch button, it
stopped when I pushed the stop button,
flash again when I pushed the start button, etc.
That's why I said the code worked fine - because
it worked better than mine (mine starts immediately
flashing).
When I said I could not "interactively test" that code,
I meant I could not type anything in the SwiftX windows - which I always do
for thoroughly testing all of the code, for instance, reading the contents of
the switches while pressing other buttons, etc .

I have that message "NO XTL PORT" usually when I
change something in the /TESTER word.

>There is no reason to immediately follow a task BUILD with an ACTIVATE;
>it's much better to do the BUILD with your power-up code and your ACTIVATEs
>in the control words.

Here I must say two things:
- The only other place where TESTER BUILD can move is
in the GO word in the App.f file, thus at start-up as you suggest.
It can't be moved to any other place or it will give
a message that the word is unknown, the ? mark, even if I put it
in a START word. And this is really the only change the
/TESTER definition allows.
- All the other changes in /TESTER most often
end up in the error message "No XTL port".
Usually nothing works then in the target or only badly - if load
completes at all. And after the
"NO XTL port" message I must always do a PROJECT-BUILD,
because PROJECT-DEBUG doesn't do it anymore, keeping saying
no XTL and asking for COM port. PROJECT-BULD with good
code solves this and from then I can again do PROJECT-DEBUG.

The feeling I have is the program wants at start up a
TASK that is ACTIVATED and nothing else. In other
words, it wants to start "in" a task, and not, for
instance, in a simple word like PIND C@ = that
would condition the starting up of the task.
Whatever it may be, I think I tried everything.

That's why I am now going to do another series of tests:
- limit the leds to six - this way I remove
the mask 255 in my SEQBITFLASH or DOFLASH words.
Maybe there is a conflict because of this.

Thanks anyway,
Viviane
----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe" to swiftx-request_at_forth.com
For list command help, send subject "help" to swiftx-request_at_forth.com
Message archives are located at http://www.forth.com/archive/swiftx
----------------------------------------------------------------------
This list is a forum for SwiftX users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Tue Aug 12 2003 - 12:53:49 PDT