Hello,
I have only recently found AmForth, and have, over the last month or
so, been making led flash, getting the time from rtc, displaying
things on an lcd etc. It really has been a most enjoyable and
educational couple of months for me. I thank Matthias and the AmForth
developers for making
Hello Matthias,
I have made hex files from amforth-code-2147-trunk for a "home brew"
UNO (atmega328P) using a 14.7456MHz crystal. Screen shots from the
serial connections are below
115200 http://sphinx.mythic-beasts.com/~tristan/files/af115200.tiff
230400
Hello,
I would like to set a marker or execute a marker dependant upon
whether that marker exists or not. What I have in mind is something
like this
: check_marker [defined] stage1 if stage1 else marker stage1 then ;
followed by
check_maker
However, this does not work for me and I suspect
Apologies, that should be (and is in my code)
check_marker
On 29Jun16 23:23, Tristan Williams wrote:
> Hello,
>
> I would like to set a marker or execute a marker dependant upon
> whether that marker exists or not. What I have in mind is something
> like this
>
> :
Hello Matthias,
> The good news: your code works for me. The bad news: I
> cannot reproduce
> what you wrote.
My apologies. I did not explain myself well. My code worked for me
also. It was the Cookbook example I could not get to work.
>From
Hello Matthias,
Thank you. >rx-buf is wonderful. I have high hopes of making the
keypad appear as a subset of the keyboard so they can use exactly the
same code.
The PCF8574A + keypad + interrupt also seems to work well. I
explicitly protected each of the other i2c devices on the bus from
being
Hello,
I am in the process of connecting a keypad to an i2c port expander
(PCF8574A) to an UNO and have run into the following problem. More
than likely the problem is my lack of understanding. Writing to the
port expander appears to be no problem. Reading from it using i2c.>n
results in the UNO
:02 + schrieb Tristan Williams:
> > I replaced my i2c files with those from the trunk r2209 and all of
> > i2c.c! i2c.c@ i2c.n! i2c.n@ i2c.m!n@ give me what I was expecting.??
>
> I've essentially re-implemented the i2c words after release 6.3.??
> Maybe I should f
that first next time.
Tristan
On 25Jan17 00:37, Tristan Williams wrote:
> Hello,
>
> I am in the process of connecting a keypad to an i2c port expander
> (PCF8574A) to an UNO and have run into the following problem. More
> than likely the problem is my lack of understanding. Writin
Hello Matthias,
Brilliant. Thank you.
Best wishes,
Tristan
--
___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
Hello Matthias,
> Development for the next release has been started by now,
> some i2c related stuff by now.
I was wondering if anyone has used AmForth as an I2C slave on ATmega
uc(s)? I've written a couple of I2C slaves in C++ using ATtiny uc(s)
and used AmForth as an I2C master to communicate
AVR8 watchdog (reset and interrupt) atmega328p
I wanted to use the 128 kHz watchdog oscillator as an additional
timer. I saw that AVR8 watchdog timer and reset was addressed on the
mailing list in late 2013 using assembler.frt
In the source tree there is an assembler word -wdt (no-wdt.asm),
On 13Jul17 09:50, Atommann wrote:
> Hi Tristan,
>
> 2017-06-26 19:36 GMT+08:00 Tristan Williams <h...@tjnw.co.uk>:
> > Thank you.
> >
> > The small project I had in mind needs little in terms of resources. In
> > my perfect world there would be an 8 pin DI
Hello Matthias,
> I'll look at them in the next few days. Since we've just discovered
> some interrupt related bugs so maybe I'll ask you to do some
> tests with the code I will checkin. Is this ok for you?
Absolutely fine.
Tristan
Hello Matthias,
> IIRC only the "disable watchdog" sequence is timing critical (the
> 4 cpu cycles you mention). All other tasks can be performed at
> lower speed, so a forth implementation should be fine.
My atmega328p seems to require any change to WDTCSR to be completed
within 4 cycles (I
Hello Matthias,
> I use a 1284 occasionally too. Works fine and without problems.
Thank you for this. It persuaded me to look at my hardware
again. Building a board that pays attention to the reference hardware
design seems to have made the difference. It works fine and without
problems for me
may
> also be useful to have extra UARTs, but for this you might prefer to use the
> 2560 instead of the 1284. If you want to connect RS232 devices you might add
> a TTL to RS232 level convertor such as a MAX232.
>
> Peter
>
>
> > On 9 May 2017, at 23:07, T
Hello,
I have been enjoying using AmForth on AVR hardware but have a project
in which I would like to use a physically smaller processor than a
AtMega328p 28 pin DIP. Before thinking about SMD I wondered if there
was a smaller DIP packaged processor that would run AmForth in the
MSP430 family?
On 26Jun17 20:33, Matthias Trute wrote:
> Am Montag, den 26.06.2017, 12:36 +0100 schrieb Tristan Williams:
> > Thank you.??
> >
> > The small project I had in mind needs little in terms of resources.
> > In
> > my perfect world there would be an 8 pin DIP micropro
Thank you.
The small project I had in mind needs little in terms of resources. In
my perfect world there would be an 8 pin DIP microprocessor capable of
running AmForth :) I was hoping that, despite my failure to find it,
there existed a 14 pin DIP MSP430 with the necessary resources to run
Hello Matthias,
Two build questions.
1)
I have downloaded 2252 and run into this error when building for my uno
amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: jz: Unknown instruction
or macro
amforth-6.5A/avr8\drivers/generic-isr.asm(28): error: isr_clean: Unknown
instruction or
Hello Martin,
I am currently looking for an avr emulator, but I have not got far
enough in my search to make any comments. simavr, which runs under
Linux, is on my list but I have not used it yet.
https://github.com/buserror/simavr
Kind regards,
Tristan
On 14Nov17 10:28, Martin Bitter
Hello,
I am clearly not understanding how something works, and would be
grateful for any help.
I am decoding infrared remote control codes using the input capture
mode of TIMER1 on an ATmega328P (UNO). This works successfully.
Then I decided to buffer the codes received, so that should the MCU
On 08Jun18 14:57, Matthias Trute wrote:
> Am Donnerstag, den 07.06.2018, 21:05 +0100 schrieb Tristan Williams:
> > Hello,
> >
> > I am clearly not understanding how something works, and would be
> > grateful for any help.
> >
> > I am decoding infrar
Hello Frank,
I am sitting looking at some multitasking flashing LEDs, but you just
beat me to it :) It does indeed live.
I still find it amazing to have a multitasking environment and an
interactive interpreter/compiler on an mcu you can setup on a
breadboard. Makes me smile.
Best wishes,
Hello Jan,
If you are happy to have version 6.7 rather than most recent sources
(see http://amforth.sourceforge.net/ below Work In Progress for more
information ) then using this link is probably the easiest way.
https://sourceforge.net/projects/amforth/files/amforth/6.7/
Then click on an
On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote:
> Hi,
>
> I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR.
> Although it's possible to code around a variable being changed by an
> interrupt (using C@ C! for example), the 16-bit counter registers can't
> be dealt with
Hi Jan,
On OS X I use amforth-shell.py which is in the tools directory of the
AmForth distribution. More info below
http://amforth.sourceforge.net/TG/recipes/Upload.html
Regards,
Tristan
On 24Oct18 16:58, Martin Bitter wrote:
> Hi Jan!
>
> I recommend e4thcom written by Manfred Mahlow
Hi Jan,
I am not sure how far you got with amforth-shell.py so I have started
at the beginning and worked forward in steps.
Step 1
Open an OS X terminal, change to your-amforth-dir/tools directory(folder)
and type
./amforth-shell.py --help
If this executes you should get a screen full of
Jan,
In release 6.2 [1] find-name was renamed to find-xt. I think the forth
code for see has not been updated to reflect this. By editing see.frt
and changing find-name to find-xt I was able to produce the following.
> : test 5 0 do i . loop ;
ok
> test
0 1 2 3 4 ok
> see test
: test
[ 5278 ]
Jan,
Perhaps amforth-shell.py is trying to execute one of the versions of
python you have on your machine that does not have the required serial
module installed or configured. The following might shed some light on
the problem but comes with no warranty. Proceed at your own risk.
In an OS X
Jan,
If you want to see different frequencies using your code I think you
will need to reset TCNT1 to the value you want in your overflow isr.
: timer1.isr
\ toggle output PD7
togglePD7
\ reset TCNT1
your-value TCNT1 !
;
However, using CTC mode would be more accurate and
Jan,
I would try adding --rtscts to the ./amforth-shell.py command line. If
that does not help, then I would use --debug-serial to have a look at
what is happening at a lower level.
What model of Arduino are you trying to connect with?
Regards,
Tristan
On 25Oct18 19:02, Jan Kromhout via
Jan,
Have a look at the source your-amforth/common/lib/hardware/i2c.frt
and the comments at the top of the file.
i2c.c! i2c.c@ i2c.n! i2c.n@ i2c.m!n@ already have the i2c.begin and
i2c.end within the respective word. I don't know the Gravitech shield
but if you are sending multiple bytes i2c.n!
> : test7SEG
> \ i2c.detect
> \ 7SEG i2c.begin
> 0 7SEG i2c.c!
> %01000111 7SEG i2c.c!
> \ i2c.end
>
> \ 7SEG i2c.begin
> 1 7SEG i2c.c! \ Digit
> $7d 7SEG i2c.c! \ Number
> \ i2c.end
> ;
>
>
> > Op 10 nov. 2018, om 17
Jan,
What error is avrdude reporting?
Kind regards,
Tristan
On 13Dec18 10:09, Jan Kromhout wrote:
> Hi,
>
> Flashing the Arduino Uno is giving no problems.
>
> Try to flash the Leonardo.
> I’m using the Pololu AVR programmer v2.1
> This is my command.
>
> MacBook-Pro-van-Jan-10:avrdude
On 03Jan19 16:07, Jan Kromhout wrote:
> Hello,
>
> Is in AmForth a microsecond delay available?
>
> Cheers,
>
> Jan
>
Jan,
As far as I know, whilst AmForth does have a millisecond word 1ms, it
does not have an equivelent microsecond word, say 1us. I think it
would be possible to make one,
On 24Jan19 20:25, Erich Wälde wrote:
> atmega644p has 2 serial interfaces. It is the same package as
> the 328p. I have toyed around with two serial interfaces, but
> with not much success. That was a problem of how to utilize this
> second uart, more than anything else. I'm sure, it can work.
I have added forth files for uart2 and uart3 on an ATmega2560 together
with a small video of the mcu running 4 uarts.
https://www.mostlymostly.uk/post/2019.02.01/
Tristan
___
Amforth-devel mailing list for http://amforth.sf.net/
Jan,
> What do you mean with “and a small sck period”
The smaller the SCK period the faster the programmer tries to program
the target mcu. There are limits and not all programmers/software support
user altering of the SCK period.
I think you mentioned you use a Pololu programmer so this link
:
> A nice board to play with it.
> What is the internal frequency? Found only that there is a 32k crystal
> mounted on the board.
>
>
> Cheers,
>
> Jan
>
> > Op 6 mrt. 2019, om 09:56 heeft Tristan Williams het
> > volgende geschreven:
> >
> >
&
I would like to try and see if I can get AmForth running on the
ATmega4809 IC and specifically on the ATmega4809 Curiosity Nano [1]
The ATmega4809 is a relatively new IC and so does not have a directory
in amforth-6.8/avr8/devices. Consequently it does not have the part
specific .frt , .asm
Hi Fred,
How are you proposing to connect the DSO112A to the Arduino Mega2560 ?
Best wishes,
Tristan
On 14Mar19 12:43, f.zelders--- via Amforth-devel wrote:
>
> Hello!
>
> I want to connect a DSO112A mini oscilloscope to UART1 of my Arduino Mega
> 2560 .
> The DSO112A uart only supports
Fred,
Many thanks. I have a DSO112A so I was interested in what you are
looking to do.
> One of the connectors is a alternative UART. It is a LVTTL connection.
> I want to connect the Arduino uart1 (TXD1/RXD1) to this connector (J11).
I think LVTTL is ~3.3V levels rather than the 5V levels of
Fred
> I don't have (and can't find) the data sheet that is referred to.
> Do you have that datasheet? Can I have a copy? (PDF?)
https://www.microchip.com/wwwproducts/en/ATmega2560
I made two changes
#16 UBRR1 ! \ change to this - change 1
%10 UCSR1A bm-set \ add
Hello Jan, Erich,
I came across my Leonardo and remembered this thread. I think Eric
is correct. There is no FTDI USB to serial chip. The USB connection is
provided by the ATmega32U4 itself. The Leonardo bootloader enumerates
to the host as a CDC Class device (virtual serial port). However,
I've linked (below) some AmForth words I've written to help me use the
second hardware serial port on an AVR atmega mcu, should there be one.
https://www.mostlymostly.uk/post/2019.02.01/
Tristan
___
Amforth-devel mailing list for
s without a good portion of
> help.
>
> My email is krom1109 at hotmail dot com
>
> With kindly regards,
>
> Jan
>
>
>
> > Op 15 feb. 2019, om 16:38 heeft Tristan Williams het
> > volgende geschreven:
> >
> > Jan,
> >
> &g
Jan,
> Loading my Mega with forth was a succes.
Very pleased it worked.
> After loading my fix amount of screens, witch are the same as on the
> Arduino it took significant more time to save and load the new
> image. Is this by the structure of the Mega?
Not an answer to your question, but it
the mega, and what fuse settings you
> > have used.
> > I wont to play with it this evening. Verry exciting how it works.
> > Cheers,
> >
> > Jan
> >
> > Verstuurd vanaf mijn iPad
> >
> >> Op 15 feb. 2019 om 12:45 heeft Tristan Wi
erview!
>
> Cheers,
>
> Jan
>
> Verstuurd vanaf mijn iPad
>
> > Op 15 feb. 2019 om 09:21 heeft Tristan Williams het
> > volgende geschreven:
> >
> >
> >
> > I've linked (below) some AmForth words I've written to help me use t
il is krom1109 at hotmail dot com
>
> With kindly regards,
>
> Jan
>
>
>
> > Op 15 feb. 2019, om 16:38 heeft Tristan Williams het
> > volgende geschreven:
> >
> > Jan,
> >
> > A number of things.
> >
> > The hex file you have fo
Hi Jan,
Not as far as I know. However, the mailing list archive
https://sourceforge.net/p/amforth/mailman/amforth-devel/
is worth searching (bitbang) and there are some messages relating to
your particular question. It would certainly be a nice feature to
have, perhaps along with being able to
Hello Michael,
Something I only discovered recently (when my AVRIPSmkII clone started
misbehaving) is that avrdude has various bitbang drivers, including
one for my usb-serial adaptor (5V FT232R based). I used the avrdude
ft232r programmer type, though a search through the output of avrdude
-c ?
Hello Jan,
A quick question first.
You have built your AmForth hex files with words/spirw.asm ?
Kind regards,
Tristan
On 07Jun19 17:06, Jan Kromhout via Amforth-devel wrote:
> Hello
>
> I have take a close look into SPI routines.
> I really not understand them.
>
> I need simple make a
iki/Serial_Peripheral_Interface
will help a lot, as will starting with a simple SPI device (e.g. io
expander, digital potentiometer) first.
Kind regards,
Tristan
>
> Verstuurd vanaf mijn iPad
>
> > Op 7 jun. 2019 om 17:25 heeft Tristan Williams het
> > volgende geschreven:
> >
> >
t; volgende geschreven:
> >>
> >> Hello Jan,
> >>
> >>
> >> Jan Kromhout writes:
> >>
> >>> Hi Tristan,
> >>>
> >>> What to load in the right sequence to fellow the examples in
> >>> http:/
Hello Peter and welcome,
I have just tried the turnkey example from the docs
http://amforth.sourceforge.net/TG/recipes/Turnkey.html
and it works for me.
Your error message[1] ?? -13 23 after the line
' turnkey defer@ Evalue tk.amforth
suggests that you are missing the word Evalue
Have you
Hello Peter,
> This was also to automate as much as...
I use amforth-shell.py to automate the process of loading AmForth files
onto the mcu. I use OS X, so I don't know if it will work on Windows, but
I find it indispensable.
Hello Terry,
> I moved my builds to Linux and I can now build a working set of .hex files
> that run on my eval hardware without errors or warnings.
I am interested to know what eval hardware you are using.
> Though there are some parts that appear to be missing, in particular
> the various
Hello Michael,
It is also worth checking your communication settings are 38000 8N1
and that flow control is not set to hardware (RTS/CTS), unless your
serial connection is wired that way.
kind regards,
Tristan
On 20Apr19 11:47, Jan Kromhout via Amforth-devel wrote:
> Hello,
>
> I use these
Hello Erich,
Thanks again for your help. I managed to modify applturnkey to read
from internal EEPROM, which was the missing part of my project to have
AmForth use the RC oscillator as a clock source.
kind regards,
Tristan
On 08Aug19 19:47, Erich Wälde wrote:
> Hello Tristan,
>
>
> >
> > In
Hello Erich,
Project was probably too grand a word! I have made a few notes below,
though they are not of cookbook standard.
https://www.mostlymostly.uk/post/2019.08.09/
kind regards,
Tristan
On 14Aug19 08:39, Erich Wälde wrote:
> Hello Tristan,
>
> > Thanks again for your help.
> You are
Hello Martin,
> Also, a bug in D0>:
> Hmmm, something wrong here I feel:
>
> > (ATmega2560)> decimal 1553994000. d0> . 1572137999. d0> .
> > -1 0 ok
Yes, you are right. There is something odd with d0>
It seems when the sign[1] of the least significant cell and the most
significant cell
Hello,
I have been trying to redirect emit from within a task in a forth
multitasking setup. Redirection works perfectly for me in a word run
from the interpreter but when I try to do it from a task I fail to get
it to work. Below is a stripped down example which aims to redirect
emit to drop -
Hello,
I would like to modify my AVR build of AmForth to read/write a byte
from a known fixed EEPROM address, perhaps from applturnkey. This byte
may be written outside of AmForth. Is there a safe area of EEPROM
from which to do this or a way making one? Any pointers as to where to
look
wrote:
> Hello Tristan,
>
>
> Tristan Williams writes:
>
> > Hello,
> >
> > I would like to modify my AVR build of AmForth to read/write a byte
> > from a known fixed EEPROM address, perhaps from applturnkey. This byte
> > may be written outside of AmF
ut down the
> output of the task, no matter what." I think, I have done this
> somewhere ... but I do not remember the details. You need to
> place " ' drop " in the correct field in the task control block.
> Something like this ... I'll check this out next week. :-)
>
&g
task for data. I don't print anything from inside a
> task anymore, because these different task do share the buffer,
> where number output is formatted. PAD? I forgot its name. I got
> errors in formatted numeric output --- which of course looks
> like calculation errors.
>
>
>
Hello Erich,
Within task-init from multitask.frt I think a task's entire tcb/user
area is filled with zeros and then only the values from the task's
(flash) tib are copied across to the task's tcb/user area. A value for
BASE is not stored within the tib. Only sp0, sp0-- and rp0 are stored
in the
oin(self._filedirs[filename]))
self.progress_callback("Information", None, "using "+ filename+"
from"+ self._filedirs[filename][0])
fpath = os.path.join(self._filedirs[filename][0], filename)
Best wishes,
Tristan
On 08May20 15:44, John Verne
Hello Erich,
My original 2019 problem of "why can't I redirect emit to output to my
LCD from a task" is perhaps most simply addressed by an addition to the
documentation. Once (I) it is understood that the user area a task has
access to needs to be explicitly populated, it all works as expected.
A very, very, minor suggestion for amforth-shell.py in the next
release.
If amforth-shell.py finds multiple matches for a filename whilst
executing a #include directive then it exits silently. It really has
no choice but to exit (which one to load?). Adding a
self.progress_callback line (as per
Hello Erich, AmForthers,
> After that all the remaining hex files could be built.
> ONLY arduino/leonardo.hex is missing.
I am not sure if the Leonardo was excluded because AmForth cannot make
use the of the Leonardo's USB connection, but it builds without error
on r2450. I have not tested r2450
Hello Mark, Erich, AmForthers,
I agreed with Mark's comment below
>> It seems that the intent of the refcard was to document the things that
>> are compiled into the system.
and commented
> For me, the scope of the/each refcard is defined by the
> distribution build for each architecture
A one line patch for amforth-shell.py to correct a python2/python3
syntax error. It occurs when using the --no-error-on-output
option. Below is a unified diff against r2450/trunk/tools/amforth-shell.py
--- amforth-shell.py
+++ new-shell.py
@@ -857,7 +857,7 @@
Hi,
> Does that mean that it is practically impossible to use amforth on an
> atmega8?
I would say yes.
The ATmega8 has 8K of flash memory. My AmForth 6.8 ATmega328p hex
needs ~10K of flash memory. It might be possible to remove words from
the current distribution/build so that it would fit
https://tjnw.co.uk//amforth-6.92/appl/arduino/custom.html
The issues relating to the presence and correctness of the
documentation in the .asm files still remain.
Best wishes,
Tristan
On 09Sep20 08:38, Tristan Williams wrote:
> Hello Mark, Erich, AmForthers,
>
> Yes, I completely agree t
On 23Oct20 00:28, fra...@fraber.de wrote:
> Hi!
>
>
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher
Hello Mark, Erich, AmForthers,
Mark - I have chopped and reordered selected parts of your message to
form my reply. I hope this is OK.
> It seems that the intent of the refcard was to document the things that
> are compiled into the system.
+1
For me, the scope of the/each refcard is defined
Hello,
I have modified amforth-shell.py to run under python3 and put up a
patch here
https://tjnw.co.uk/new-shell/doc/
as the patch seemed a little too large for a mailing list.
Best wishes,
Tristan
___
Amforth-devel mailing list for
d the atmel (micochip) assembeler. These tools
> allowed me to build and run the current amforth on the avrbutterfly. I think
> this is a great project. I would love to help, especially in the
> documentation. I'll keep my eyes open to how to submit patches. Thanks for
> everything.
>
Is it possible to build the current AVR AmForth so that it can
co-exist with a bootloader?
There is a reference in the documentation to changes that would be
required
http://amforth.sourceforge.net/TG/AVR8.html?highlight=bootloader
and some older discussions in the mailing list
Hello,
> Who of you is using which target controller?
I use AVR atmega328p, atmega1284p, atmega2560
> Can we get rid of the Atmel/Microchip Avrasm Assembler?
Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
that would be a lot of work and wine does run it very well.
Hello Brian,
Welcome to the list. Seems like you got a bargain. I was surprised to
see I could still buy a new AVR butterfly in the UK, but it would cost
me quite a bit more than 8 USD!
> How would I submit this as a patch for the documentation?
Emailing this mailing list is the way I have done
Hello Mark,
Welcome to the list.
> Should I be concentrating more on following along with the I2C EEPROM
> recipe in the cookbook instead?
It depends upon what you want to achieve - but perhaps. At the end of
cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
and be able
Hello Mark,
Brilliant! There are AmForth words there I hadn't realised it had.
Best wishes,
Tristan
On 16Jul20 00:49, Mark Roth wrote:
> It's almost there at least as a page that can temporarily replace the
> temporary v5.5 one. This is generated from the current svn sources and
> consists of
Hello Stephen,
I wanted to do something similar with the ATmega4809 on a Curiosity Nano last
year but ran out of time/skill.
https://sourceforge.net/p/amforth/mailman/search/?q=4809
> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I
A very minor item.
avr8 has bm-set, bm-clear and bm-toggle as assembler words but does
not appear to have bm-test. This is not a big thing as it is easily
defined in forth as
: bm-test ( c a -- c ) c@ and ;
However, I've made myself an assembler version so I have a matching
set. It seems only
Hello David,
The ping-pong[1] looks interesting!
You are correct the ATMega8 does present some challenges for AmForth 6.9
This issue came up on the mailing list earlier this year.
> Any ideas what's wrong about the Uart drivers
https://sourceforge.net/p/amforth/mailman/message/37085124/
>
Hello AmForthers,
With the season's TV not to everybody's taste and ownership of the
remote control contested, having an alternative activity is a good
idea. Over the decades there have been many good Forth papers written,
but finding approachable, self-contained ones is not always easy (for
me
uld be referenced on the AmForth website? For a
newcomer to Forth like me, it is too useful a paper to have to rely on
finding it by chance!
Best wishes,
Tristan
On 10Dec20 18:23, Erich Wälde wrote:
> Hello Tristan,
>
> Tristan Williams writes:
>
> > Hello AmForthers,
> &g
Hello Erich, AmForthers,
> Does this sound like a worthwile plan?
Yes, very much so.
I would be interested in progressing further with AmForth for
RISC-V. The existing AmForth target board HiFive1 has been
discontinued [1] - though there is the upgraded HiFive1 Rev B [2].
Are there any views
I have added parts two and three of the project.
https://tjnw.co.uk/limpicprog/
Best wishes,
Tristan
On 06Jan21 18:56, Tristan Williams wrote:
> First part of project to make tinkering in the shed easier.
>
> https://tjnw.co.uk/limpicprog/
>
> Best wi
Hi Michael,
I hope you got AmForth to build successfully under windows for the
atmega2560, but if not, I have built it for my Arduino MEGA using the
most recent source (r2457).
https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
I have uploaded the resulting hex files to
t; Michael
>
> Sent from my iPhone
>
> > On Jun 2, 2021, at 01:18, Tristan Williams wrote:
> >
> > Hi Michael,
> >
> > I hope you got AmForth to build successfully under windows for the
> > atmega2560, but if not, I have built it for my Ard
rface to use
> that will allow me to upload source files?
>
> Thank you for your patience!
>
> Kind regards,
>
> Michael
>
> On 6/2/2021 8:36 AM, Tristan Williams wrote:
> > Hi Michael,
> >
> > I used
> >
> > FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U
amforth-shell.py replaces known mcu register names with their
values. This makes it very easy to create a file like this and upload
it to the mcu (in this case avr8)
#include ms.frt
: low ( mask port -- ) dup c@ rot invert and swap c! ;
: high( mask port -- ) dup c@ rot or swap c! ;
I have been using wordlists to store and catalogue information for a
different project and found I needed some more tools in addition to
those in the distribution
Source and more details below
https://tjnw.co.uk/wlt/
Kind regards,
Tristan
___
Hello and welcome Helge,
> amForth is an interactive Forth. The compiler runs on the target and
> writes to the flash memory of the device. This requires to send all the
> source code through the UART interface.
This is the usual way AmForth is used. However it is possible to write
words in AVR
1 - 100 of 109 matches
Mail list logo
