amforth-devel

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[D N. <dny...@at...>]

Okay, the problem seems to have been a combination of wrong fuse bits, 
plus my hardware is running at 17.5 mHz instead of 18.4 as the crystal 
is marked. I'm thinking maybe the caps attached to the crystal are funny 
or something. But now it works, even from startup.

Now to better re-learn forth :)

Thanks, Erich!

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[D N. <dny...@at...>]

Yes, my fuse settings were wrong, and that was part of the problem. 
Also, for reasons I don't understand, the 18.4 mHz crystal isn't making 
it run at 18.4, but rather I measure it (crudely) at around 17.5. I'll 
try to make a more precise measurement with oscilloscope in a little 
while. Adjusting the uart divider value, I empirically found a value 
that works, then adjusting F_CPU in the source made it part of the code. 
So now I'm getting coherent responses out of the serial port. The scope 
may tell me a better value for F_CPU than one I calculated by 
experimenting with the uart counter register, though, so I'll do that 
shortly. Also less tedious! :)

On 3/26/2011 12:48:07 PM, Marcin Cieslak (sa...@sa...) wrote:
 > >> D Nyberg <dny...@at...> wrote:
 > > Issue 2: With the console running, I can do a few really basic things
 > > such as 1 . yields a correct response of 1 <cr> ok, but... If I 
enter 1
 >
 > > 2 + . I get the strange response "?? -13 6" <cr> ok.
 >
 >
 > Does the "words" command work? If not, there may be different issues.
 >
 > First, did you upload also EEPROM file ("filename.eep.hex") as well?
 > Many control variables etc. are set using EEPROM.

I have made this mistake in the very recent past! :) Fortunately not 
right now, though.

 >
 > Or alternatvely, you fuses may be wrong. Apart from the clock,
 > there may be something with the size of your bootloader area (BOOTSZ0,
 > BOOTSZ1) or the "Boot Reset vector Enabled (BOOTRST).
 >
 > I am using this to determine correct values, I think Erich gave
 > you those that are okay:
 >
 > http://www.engbedded.com/fusecalc
 >
 > //Marcin
 >
 >
 > 
------------------------------------------------------------------------------
 > Enable your software for Intel(R) Active Management Technology to 
meet the
 > growing manageability and security demands of your customers. Businesses
 > are taking advantage of Intel(R) vPro (TM) technology - will your 
software
 > be a part of the solution? Download

I believe I have figured out the cause of the really mysterious -13 6 
error. For example, I could enter "1" and "1 1" but it would fail if I 
entered "1 1 + ." I think the error was because I am using tera term, 
which sends a whole line at once. Combine that with the imperfect clock 
setting, and I think the atmel uart saw unprintable characters by byte 6 
or 7 in a string because of timing problems. Or possibly it's still set 
to polled serial (I set that a while ago to reduce variables, when I was 
having trouble getting it to run at all); the pc may be overruning 
characters. Anything I did in 4 or  5 characters worked ok, anything 6 
or more failed. Now that I have adjusted the clock value, I'm able to 
enter long lines. Sneaky problem, huh? But I think it's fixed now.

Thanks!

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Marcin C. <sa...@sa...>]

>> D Nyberg <dny...@at...> wrote:
> entered "1 1 + ." I think the error was because I am using tera term, 
> which sends a whole line at once. Combine that with the imperfect clock 
> setting, and I think the atmel uart saw unprintable characters by byte 6 
> or 7 in a string because of timing problems. Or possibly it's still set 
> to polled serial (I set that a while ago to reduce variables, when I was 
> having trouble getting it to run at all); the pc may be overruning 
> characters. Anything I did in 4 or  5 characters worked ok, anything 6 
> or more failed. Now that I have adjusted the clock value, I'm able to 
> enter long lines. Sneaky problem, huh? But I think it's fixed now.

Thank you, too, since sometimes those problems pop up in a while,
now we have a solution. 

//Marcin

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[<ken...@al...>]

My thanks to all who worked on this problem.  I have had an almost
identical problem on a low cost arduino clone, the BBB by Modern Device.
 It uses a ceramic resonator rather than a crystal, so I expect the
clock frequency to be a little off.  I'll know whether that is the
problem when I solder up one with a crystal instead.

Good trouble shooting.  You displayed more patience than I did.

Ken

On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
wrote:
> >> D Nyberg <dny...@at...> wrote:
> > entered "1 1 + ." I think the error was because I am using tera term, 
> > which sends a whole line at once. Combine that with the imperfect clock 
> > setting, and I think the atmel uart saw unprintable characters by byte 6 
> > or 7 in a string because of timing problems. Or possibly it's still set 
> > to polled serial (I set that a while ago to reduce variables, when I was 
> > having trouble getting it to run at all); the pc may be overruning 
> > characters. Anything I did in 4 or  5 characters worked ok, anything 6 
> > or more failed. Now that I have adjusted the clock value, I'm able to 
> > enter long lines. Sneaky problem, huh? But I think it's fixed now.
> 
> Thank you, too, since sometimes those problems pop up in a while,
> now we have a solution. 
> 
> //Marcin
> 
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet
> the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your
> software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[D N. <dny...@at...>]

I have few resources but the advice I can ask for here, and patience. 
There's only so much you can lean on others who are not on payroll, so 
I'd darn better be able to scrape up buckets of patience,  or I'll get 
frustrated and make no progress! :) This would have been more fun with a 
digital storage scope, but we make do with what we have.

You could also test the theory on your hardware, if you can run it under 
a debugger, by adjusting the uart divider register up and down in 
increments, to see if a nearby value would work better than what it's 
using now. That assumes the resonator is stable, but possibly operating 
at a different freq than expected, ie not varying moment to moment. I 
don't know if that's their behavior or not though.

On 3/27/2011 11:07:25 AM, ken...@al... wrote:
 > My thanks to all who worked on this problem. I have had an almost
 > identical problem on a low cost arduino clone, the BBB by Modern Device.
 > It uses a ceramic resonator rather than a crystal, so I expect the
 > clock frequency to be a little off.
 > I'll know whether that is the
 > problem when I solder up one with a crystal instead.
 >
 > Good trouble shooting. You displayed more patience than I did.
 >
 > Ken
 >
 > On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
 > wrote:
 > > >> D Nyberg <dny...@at...> wrote:
 > > > entered "1 1 + ." I think the error was because I am using tera 
term,
 > > > which sends a whole line at once. Combine that with the imperfect 
clock
 > > > setting, and I think the atmel uart saw unprintable characters by 
byte 6
 > > > or 7 in a string because of timing problems. Or possibly it's
 > still set
 > > > to polled serial (I set that a while ago to reduce variables, when I
 > was
 > > > having trouble getting it to run at all); the pc may be overruning
 > > > characters. Anything I did in 4 or 5 characters worked ok, 
anything 6

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[<ken...@al...>]

Hi, I soldered in a crystal and a couple of caps and it's working fine
now,  Amforth seems much more sensitive to clock frequency than the
Arduino C programs. 

I've had no trouble with the serial interface running C programs on the
BBB. That sent me on some wild goose chases trying to figure out what
was wrong with Amforth.

Thanks again for solving this one.

Ken

On Sun, 27 Mar 2011 21:08 -0600, "D Nyberg" <dny...@at...> wrote:
> I have few resources but the advice I can ask for here, and patience. 
> There's only so much you can lean on others who are not on payroll, so 
> I'd darn better be able to scrape up buckets of patience,  or I'll get 
> frustrated and make no progress! :) This would have been more fun with a 
> digital storage scope, but we make do with what we have.
> 
> You could also test the theory on your hardware, if you can run it under 
> a debugger, by adjusting the uart divider register up and down in 
> increments, to see if a nearby value would work better than what it's 
> using now. That assumes the resonator is stable, but possibly operating 
> at a different freq than expected, ie not varying moment to moment. I 
> don't know if that's their behavior or not though.
> 
> On 3/27/2011 11:07:25 AM, ken...@al... wrote:
>  > My thanks to all who worked on this problem. I have had an almost
>  > identical problem on a low cost arduino clone, the BBB by Modern Device.
>  > It uses a ceramic resonator rather than a crystal, so I expect the
>  > clock frequency to be a little off.
>  > I'll know whether that is the
>  > problem when I solder up one with a crystal instead.
>  >
>  > Good trouble shooting. You displayed more patience than I did.
>  >
>  > Ken
>  >
>  > On Sun, 27 Mar 2011 01:55 +0000, "Marcin Cieslak" <sa...@sa...>
>  > wrote:
>  > > >> D Nyberg <dny...@at...> wrote:
>  > > > entered "1 1 + ." I think the error was because I am using tera 
> term,
>  > > > which sends a whole line at once. Combine that with the imperfect 
> clock
>  > > > setting, and I think the atmel uart saw unprintable characters by 
> byte 6
>  > > > or 7 in a string because of timing problems. Or possibly it's
>  > still set
>  > > > to polled serial (I set that a while ago to reduce variables, when I
>  > was
>  > > > having trouble getting it to run at all); the pc may be overruning
>  > > > characters. Anything I did in 4 or 5 characters worked ok, 
> anything 6
> 
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet
> the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your
> software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[D N. <dny...@at...>]

On 3/27/2011 8:22:27 PM, ken...@al... wrote:
 > Hi, I soldered in a crystal and a couple of caps and
 > it's working fine
 > now, Amforth seems much more sensitive to clock frequency than the
 > Arduino C programs.
 >
 > I've
 > had no trouble with the serial interface running C programs on the
 > BBB. That sent me on some wild goose chases trying to figure out what
 > was wrong with Amforth.
 >

As I understand it, the amforth way of dealing with interrupts on the 
serial port is to have the ISR set a flag, and the uart is truly 
serviced when the inner interpreter steps to the next word. There is an 
elegance to that approach, as it allows secondary ISR to be written in 
forth, but it has more latency than a traditional ISR (grab byte and 
stuff into ring buffer immediately). Without hardware drtiven serial 
handshake, that increased latency may account for the greater  
sensitivity to timing?

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Matthias T. <mt...@we...>]

Hi,

> As I understand it, the amforth way of dealing with interrupts on the 
> serial port is to have the ISR set a flag, and the uart is truly 
> serviced when the inner interpreter steps to the next word.

You are right that the inner interpreter can deal with interrupts (to
some extent), but the usart communication for the command interpreter
does not use it. The reason is simple: I initially wrote it in assembly
language. I tried to redesign it to use the forth interrupts, but never
really succeeded for many and varying reason...

The interrupts amforth can handle with the current inner interpreter
hook are restricted to _not_ require any hardware access during the
interrupts. That means: if an interrupt is triggered and needs to be
cleared by reading some special address (e.g. reading the received
character from the USART data register), that read operation does not
happen.

That means, that the interrupt sources does not get cleared and re-fires
immedieatly, making the system unusable (looks like a crash). Details
are outlines in the docs (somewhere).

Serial communication has to aspects: sending and receiving single
characters.

Sending characters is trivial since the application knows when and what
to send. The hardware module does the lowlevel task for the shifting
out of the bits and framing etc.

This is pure forth code and there is no timing problem (IMHO). Just have
a look at the usart-tx-poll.asm file.

There is an interrupt based routine as well (usart-tx-isr.asm), but
avoid using it. It works but gives no benefit while making the code more
complicated.


Receiving characters is a completly different thing. The characters
can come at any time, therefore the code needs to deal with the
situation relativly fast (at least before the next character
arrives).

The USART receiver can be polled for a character and set a flag if
anything is available. The same flag can be used to trigger an interrupt
that reads the character and handle it. If the polling is done often
enough, it works surprisingly well. This is what the usatz-rx-poll.asm
code does.

A better solution is usart-rx-isr.asm. This code uses interrupts and
an internal ring buffer (16 characters long) to keep the characters.
The KEY and KEY? words simply check the length of the (used) ring
buffer and extract the characters from it.

Matthias

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Kalus M. <mic...@on...>]

Hi.


Am 29.03.2011 um 21:33 schrieb Matthias Trute:
..
> Receiving characters is a completly different thing. The characters
> can come at any time, therefore the code needs to deal with the
> situation relativly fast (at least before the next character
> arrives).

If you just want to connect a terminal to type in commands, amforth  
is fast enough to handle this situation: Wait for a key, grab it, put  
it in inputbuffer, wait again.
amforths accepts keys till end of line, then interprets the line.
See: uart-rx-poll.asm
Since you - the user - wait for the ok of amforth to appear, there is  
no overflow.
I use 12Mhz chrystal, 14400 Baud, atmega168, works fine this way.

But to download a file you have to make shure your sending program  
will immediatly stop sending if a CR is echoed, and continues after  
OK is encounterd. Terminals usualy can not handle this situation.  
That is why Mathias is using a Phyton script for downloads.

I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF  
character is echoed, and continues after XON. So my amforth CR sends  
xoff to the Terminal too, and the OK is followed by XON.
(Typing mode: copy&paste forth souce into ZTerm window, do not use  
ZTerms file transfer feature. Setup the ZTerm as VT100 with line  
prompt character ^C ($13 = xoff)).

There may be about two characters on its way down to amforth till  
terminal finaly stops sending more characters. I allways insert 4 or  
more blanks at the beginning of each line in my forth sources to  
handle this situation. This way interpretation of a line stays  
successful even if some characters are lost in the handshaking process.

     : hallo ." hallo world" ;
^^^^

Maybe this helps.
Michael

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[pito <pi...@vo...>]

I've been using "Mosaic Terminal" (free download, designed for
forth)under XP. Just set "Wait for Echo" ON and "Binary Char Delay"
0.005 (or less). It runs 115200 8N1 without a problem (when your
crystal allows such speed, of course). Copy/paste sources. This
terminal is the only one I can use with amforth. For FlashForth the
Tera Term (FF supports Xon/Xoff) is the one which works fine any
speed. Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 4:47:21

> Hi.
> 
> 
> Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> ..
> > Receiving characters is a completly different
> > thing. The characters
> > > can come at any time, therefore the code needs
> > to deal with the
> > > situation relativly fast (at least before the
> > next character
> > > arrives).
> 
> If you just want to connect a terminal to type in
> commands, amforth  
> is fast enough to handle this situation: Wait for
> a key, grab it, put  
> it in inputbuffer, wait again.
> amforths accepts keys till end of line, then
> interprets the line.
> See: uart-rx-poll.asm
> Since you - the user - wait for the ok of amforth
> to appear, there is  
> no overflow.
> I use 12Mhz chrystal, 14400 Baud, atmega168, works
> fine this way.
> 
> But to download a file you have to make shure your
> sending program  
> will immediatly stop sending if a CR is echoed,
> and continues after  
> OK is encounterd. Terminals usualy can not handle
> this situation.  
> That is why Mathias is using a Phyton script for
> downloads.
> 
> I use ZTerm with Mac OSX. In typing mode, it stops
> sending when XOFF  
> character is echoed, and continues after XON. So
> my amforth CR sends  
> xoff to the Terminal too, and the OK is followed
> by XON.
> (Typing mode: copy&paste forth souce into ZTerm
> window, do not use  
> ZTerms file transfer feature. Setup the ZTerm as
> VT100 with line  
> prompt character ^C ($13 = xoff)).
> 
> There may be about two characters on its way down
> to amforth till  
> terminal finaly stops sending more characters. I
> allways insert 4 or  
> more blanks at the beginning of each line in my
> forth sources to  
> handle this situation. This way interpretation of
> a line stays  
> successful even if some characters are lost in the
> handshaking process.
> 
> : hallo ." hallo world" ;
> ^^^^
> 
> Maybe this helps.
> Michael
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[pito <pi...@vo...>]

.. there is an issue with Mosaic Terminal - the BackSpace issue I've
addressed in one of my last year's topics - the fix is easy (just a
small change in one amforth word). P.

----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mic...@on...,
amf...@li...
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 10:03:58

> I've been using "Mosaic Terminal" (free download,
> designed for
> forth)under XP. Just set "Wait for Echo" ON and
> "Binary Char Delay"
> 0.005 (or less). It runs 115200 8N1 without a
> problem (when your
> crystal allows such speed, of course). Copy/paste
> sources. This
> terminal is the only one I can use with amforth.
> For FlashForth the
> Tera Term (FF supports Xon/Xoff) is the one which
> works fine any
> speed. Pito
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Kalus Michael" <mic...@on...>
> Komu: "Everything around amforth"
> <amf...@li...>
> Předmět: Re: [Amforth-devel] Progress and More
> Difficulties with
> Hello
> Datum: 30.3.2011 - 4:47:21
> 
> > Hi.
> > 
> > 
> > Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> > ..
> > > Receiving characters is a completly different
> > > thing. The characters
> > > > can come at any time, therefore the code
> > > > needs
> > > > > > to deal with the
> > > > situation relativly fast (at least before
> > > > the
> > > > > > next character
> > > > arrives).
> > 
> > If you just want to connect a terminal to type
> > in
> > > commands, amforth  
> > is fast enough to handle this situation: Wait
> > for
> > > a key, grab it, put  
> > it in inputbuffer, wait again.
> > amforths accepts keys till end of line, then
> > interprets the line.
> > See: uart-rx-poll.asm
> > Since you - the user - wait for the ok of
> > amforth
> > > to appear, there is  
> > no overflow.
> > I use 12Mhz chrystal, 14400 Baud, atmega168,
> > works
> > > fine this way.
> > 
> > But to download a file you have to make shure
> > your
> > > sending program  
> > will immediatly stop sending if a CR is echoed,
> > and continues after  
> > OK is encounterd. Terminals usualy can not
> > handle
> > > this situation.  
> > That is why Mathias is using a Phyton script for
> > downloads.
> > 
> > I use ZTerm with Mac OSX. In typing mode, it
> > stops
> > > sending when XOFF  
> > character is echoed, and continues after XON. So
> > my amforth CR sends  
> > xoff to the Terminal too, and the OK is followed
> > by XON.
> > (Typing mode: copy&paste forth souce into ZTerm
> > window, do not use  
> > ZTerms file transfer feature. Setup the ZTerm as
> > VT100 with line  
> > prompt character ^C ($13 = xoff)).
> > 
> > There may be about two characters on its way
> > down
> > > to amforth till  
> > terminal finaly stops sending more characters. I
> > allways insert 4 or  
> > more blanks at the beginning of each line in my
> > forth sources to  
> > handle this situation. This way interpretation
> > of
> > > a line stays  
> > successful even if some characters are lost in
> > the
> > > handshaking process.
> > 
> > : hallo ." hallo world" ;
> > ^^^^
> > 
> > Maybe this helps.
> > Michael
> > 
> > 
> > ------------------------------------------------------------------------------
> > > > > > Enable your software for Intel(R) Active
> > Management Technology to meet the
> > growing manageability and security demands of
> > your
> > > customers. Businesses
> > are taking advantage of Intel(R) vPro (TM)
> > technology - will your software 
> > be a part of the solution? Download the Intel(R)
> > Manageability Checker 
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[pito <pi...@vo...>]

the amforth issues one additional SPACE and that creates an issue
with Mosaic when editing the line and using backspace. The fix - do
comment out the XT_SPACE below:

...
PFA_ACCEPT5:
.dw XT_DUP        ; ( -- addr k k )
.dw XT_EMIT       ; ( -- addr k )
;.dw XT_SPACE     ; ( -- addr k ) <<<<< 20101026 by Pito
.dw XT_EMIT               ; ( -- addr ) 
....


----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <pi...@vo...>
Komu: mic...@on...,
amf...@li...
Předmět: Re: [Amforth-devel] Progress and More Difficulties with
Hello
Datum: 30.3.2011 - 10:22:00

> .. there is an issue with Mosaic Terminal - the
> BackSpace issue I've
> addressed in one of my last year's topics - the
> fix is easy (just a
> small change in one amforth word). P.
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "pito" <pi...@vo...>
> Komu: mic...@on...,
> amf...@li...
> Předmět: Re: [Amforth-devel] Progress and More
> Difficulties with
> Hello
> Datum: 30.3.2011 - 10:03:58
> 
> > I've been using "Mosaic Terminal" (free
> > download,
> > > designed for
> > forth)under XP. Just set "Wait for Echo" ON and
> > "Binary Char Delay"
> > 0.005 (or less). It runs 115200 8N1 without a
> > problem (when your
> > crystal allows such speed, of course).
> > Copy/paste
> > > sources. This
> > terminal is the only one I can use with amforth.
> > For FlashForth the
> > Tera Term (FF supports Xon/Xoff) is the one
> > which
> > > works fine any
> > speed. Pito
> > 
> > ----- PŮVODNÍ ZPRÁVA -----
> > Od: "Kalus Michael"
> > <mic...@on...>
> > > Komu: "Everything around amforth"
> > <amf...@li...>
> > Předmět: Re: [Amforth-devel] Progress and More
> > Difficulties with
> > Hello
> > Datum: 30.3.2011 - 4:47:21
> > 
> > > Hi.
> > > 
> > > 
> > > Am 29.03.2011 um 21:33 schrieb Matthias Trute:
> > > ..
> > > > Receiving characters is a completly
> > > > different
> > > > > > > thing. The characters
> > > > > can come at any time, therefore the code
> > > > > needs
> > > > > > > to deal with the
> > > > > situation relativly fast (at least before
> > > > > the
> > > > > > > next character
> > > > > arrives).
> > > 
> > > If you just want to connect a terminal to type
> > > in
> > > > commands, amforth  
> > > is fast enough to handle this situation: Wait
> > > for
> > > > a key, grab it, put  
> > > it in inputbuffer, wait again.
> > > amforths accepts keys till end of line, then
> > > interprets the line.
> > > See: uart-rx-poll.asm
> > > Since you - the user - wait for the ok of
> > > amforth
> > > > to appear, there is  
> > > no overflow.
> > > I use 12Mhz chrystal, 14400 Baud, atmega168,
> > > works
> > > > fine this way.
> > > 
> > > But to download a file you have to make shure
> > > your
> > > > sending program  
> > > will immediatly stop sending if a CR is
> > > echoed,
> > > > > and continues after  
> > > OK is encounterd. Terminals usualy can not
> > > handle
> > > > this situation.  
> > > That is why Mathias is using a Phyton script
> > > for
> > > > > downloads.
> > > 
> > > I use ZTerm with Mac OSX. In typing mode, it
> > > stops
> > > > sending when XOFF  
> > > character is echoed, and continues after XON.
> > > So
> > > > > my amforth CR sends  
> > > xoff to the Terminal too, and the OK is
> > > followed
> > > > > by XON.
> > > (Typing mode: copy&paste forth souce into
> > > ZTerm
> > > > > window, do not use  
> > > ZTerms file transfer feature. Setup the ZTerm
> > > as
> > > > > VT100 with line  
> > > prompt character ^C ($13 = xoff)).
> > > 
> > > There may be about two characters on its way
> > > down
> > > > to amforth till  
> > > terminal finaly stops sending more characters.
> > > I
> > > > > allways insert 4 or  
> > > more blanks at the beginning of each line in
> > > my
> > > > > forth sources to  
> > > handle this situation. This way interpretation
> > > of
> > > > a line stays  
> > > successful even if some characters are lost in
> > > the
> > > > handshaking process.
> > > 
> > > : hallo ." hallo world" ;
> > > ^^^^
> > > 
> > > Maybe this helps.
> > > Michael
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > > > > > > > > > > Enable your software for Intel(R)
> > > > > > > Active
> > > > > > > > > Management Technology to meet the
> > > growing manageability and security demands of
> > > your
> > > > customers. Businesses
> > > are taking advantage of Intel(R) vPro (TM)
> > > technology - will your software 
> > > be a part of the solution? Download the
> > > Intel(R)
> > > > > Manageability Checker 
> > > today! http://p.sf.net/sfu/intel-dev2devmar
> > > _______________________________________________
> > > > > Amforth-devel mailing list
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > > > > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > > > > > Enable your software for Intel(R) Active
> > Management Technology to meet the
> > growing manageability and security demands of
> > your
> > > customers. Businesses
> > are taking advantage of Intel(R) vPro (TM)
> > technology - will your software 
> > be a part of the solution? Download the Intel(R)
> > Manageability Checker 
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > > 
> 
> 
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active
> Management Technology to meet the
> growing manageability and security demands of your
> customers. Businesses
> are taking advantage of Intel(R) vPro (TM)
> technology - will your software 
> be a part of the solution? Download the Intel(R)
> Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Marcin C. <sa...@sa...>]

>> Kalus Michael <mic...@on...> wrote:
> I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF  
> character is echoed, and continues after XON. So my amforth CR sends  
> xoff to the Terminal too, and the OK is followed by XON.
> (Typing mode: copy&paste forth souce into ZTerm window, do not use  
> ZTerms file transfer feature. Setup the ZTerm as VT100 with line  
> prompt character ^C ($13 = xoff)).

Are you (or anyone) using lib/xonxoff.frt? It never worked for me
(caused quick breakage in all communications on my Arduino).

I am using GNU screen utility to paste files to amforth- 
there is a "slowpaste" (or "defslowpaste") option to add
delay when pasting. 50 millseconds are fine.

//Marcin

Re: [Amforth-devel] Progress and More Difficulties with Hello World exercise

[Kalus M. <mic...@on...>]

Hi.

..
> Are you (or anyone) using lib/xonxoff.frt?

No.

I modified QUIT to achieve a xon xoff handshake with Zterm (mac OSX).

The Idea was:
Create 2 vectors in eeprom to hold execution token (xt) for words to  
send control characters to terminal - value startterminal and value  
stopterminal. Default is NOOP for both. The XONXOFF command then  
replaces the default values with TX_XON and XT_XOFF Words. The FINIS  
command set both back to NOOP.

QUIT checks state, if compiling it uses a prompts that executes stop-  
and startterminal, else uses amforth standard prompt.

A soucefile has XONXOFF at the beginning ans FINIS at end of code.
There is en errorhandler as well that may by turnd on and off.

My amforthversion 3.6 uses pollling method for USART.

Michael




Am 30.03.2011 um 23:24 schrieb Marcin Cieslak:

>>> Kalus Michael <mic...@on...> wrote:
>> I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF
>> character is echoed, and continues after XON. So my amforth CR sends
>> xoff to the Terminal too, and the OK is followed by XON.
>> (Typing mode: copy&paste forth souce into ZTerm window, do not use
>> ZTerms file transfer feature. Setup the ZTerm as VT100 with line
>> prompt character ^C ($13 = xoff)).
>
> Are you (or anyone) using lib/xonxoff.frt? It never worked for me
> (caused quick breakage in all communications on my Arduino).
>
> I am using GNU screen utility to paste files to amforth-
> there is a "slowpaste" (or "defslowpaste") option to add
> delay when pasting. 50 millseconds are fine.
>
> //Marcin