You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
| 2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
| 2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
| 2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
| 2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
| 2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
| 2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
| 2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
| 2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tristan Williams <home@tj...> - 2017-01-31 08:51:11
|
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 interrupted (by the keypress interrupt) at inopportune moments
using critical[ <code> ]critical. Without this I would (eventually)
crash the system with a -4000 error. I thought about protecting all
the i2c devices en masse at a lower level e.g.
: i2c.c!
critical[
i2c.begin
<code>
i2c.end
]critical
;
or is this just a bad idea?
Tristan
|
|
From: Matthias Trute <mtrute@we...> - 2017-01-28 12:58:33
|
Am Samstag, den 28.01.2017, 10:46 +0000 schrieb Tristan Williams: > I have successfully written a couple of forth words keypad? and > keypad > that use i2c (PCF8574A) and an interrupt to tell me if/what key has > been pressed on my keypad. This is currently completely independent > of > the keyboard buffer. What I would like to do is to take the value > that > would placed on the data stack by keypad and instead insert it into > the > keyboard buffer. The trunk revision has a word called >rx-buf that appends a character from the data stack to the command input buffer. It is used in the usart interrupt word as follows : isr-rx usart-data-port c@ dup 3 = if cold then >rxbuf ; (the code 3 = is the check for ctrl-C that resets the system). IIRC Erich uses this word to communicate via an RS485 network. > I hope then to take advantage of a recogniser to view (say) 350*700 > as > an xy coordinate and finally free my cnc (assisted) xy table from its > umbilical connection to my computer. I am sure it can be done without > this, but to do so seems like going in the wrong direction. > > The internals of the keyboard buffer and recognisers are new areas > for > me so I would grateful for any hints as to where to start. The >rx-buf is new, as described above. The recognizer stuff is currently in a discussion with the Forth language gurus, and got 4 revisions so far (the 4th beeing worked on currently). A good starting point (because I made it ;) ) is http://amforth.sourceforge.net/Recognizers.html Despite it's name the RFD text itself is (should be) readable for starters too. It has a lot of discussion topics and examples after the formal standard section, just scroll down a few pages. A lot of (working) examples are at http://theforth.net/tag/recognizer Matthias |
|
From: Tristan Williams <home@tj...> - 2017-01-28 10:46:17
|
I have successfully written a couple of forth words keypad? and keypad that use i2c (PCF8574A) and an interrupt to tell me if/what key has been pressed on my keypad. This is currently completely independent of the keyboard buffer. What I would like to do is to take the value that would placed on the data stack by keypad and instead insert it into the keyboard buffer. I hope then to take advantage of a recogniser to view (say) 350*700 as an xy coordinate and finally free my cnc (assisted) xy table from its umbilical connection to my computer. I am sure it can be done without this, but to do so seems like going in the wrong direction. The internals of the keyboard buffer and recognisers are new areas for me so I would grateful for any hints as to where to start. Kind regards and thanks, Tristan On 25Jan17 20:21, Matthias Trute wrote: > Am Mittwoch, den 25.01.2017, 13:02 +0000 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 finish 6.4 ;) > > Thanks for testing and giving feedback, it's highly appreciated > Matthias > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matthias Trute <mtrute@we...> - 2017-01-25 19:53:47
|
Am Mittwoch, den 25.01.2017, 13:02 +0000 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 finish 6.4 ;) Thanks for testing and giving feedback, it's highly appreciated Matthias |
|
From: Tristan Williams <home@tj...> - 2017-01-25 13:03:02
|
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. What I was doing incorrectly below I don't know but perhaps starting from a completely fresh UNO (as I did above) was part of the solution. Apologies, I will do 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. Writing to the > port expander appears to be no problem. Reading from it using i2c.>n > results in the UNO hanging. Writing zero bytes and then reading 1 byte > using i2c.m>n appears to read the port expander correctly (i.e. 1 0 > $38 i2c.m>n). What am I missing? Edited minicom session below. > > Best wishes and thanks, > Tristan > > amforth 6.3 ATmega328P Forthduino > > i2c.init.default > ok > > i2c.detect > 0 1 2 3 4 5 6 7 8 9 A B C D E F > 0: -- -- -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > ok > > # turns on each LED attached to the port expander (ports sinking) > > $00 1 $38 i2c.n> > ok > > # turns off each LED attached to the port expander > > $ff 1 $38 i2c.n> > ok > > # this hangs the UNO > > 1 $38 i2c.>n > > # (repeating all comands except the one above) > # this reads the port expander address and leaves $ff on the stack > > 1 0 $38 i2c.m>n > ok > > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Tristan Williams <home@tj...> - 2017-01-25 00:54:55
|
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 hanging. Writing zero bytes and then reading 1 byte
using i2c.m>n appears to read the port expander correctly (i.e. 1 0
$38 i2c.m>n). What am I missing? Edited minicom session below.
Best wishes and thanks,
Tristan
amforth 6.3 ATmega328P Forthduino
> i2c.init.default
ok
> i2c.detect
0 1 2 3 4 5 6 7 8 9 A B C D E F
0: -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
ok
# turns on each LED attached to the port expander (ports sinking)
> $00 1 $38 i2c.n>
ok
# turns off each LED attached to the port expander
> $ff 1 $38 i2c.n>
ok
# this hangs the UNO
> 1 $38 i2c.>n
# (repeating all comands except the one above)
# this reads the port expander address and leaves $ff on the stack
> 1 0 $38 i2c.m>n
ok
|
|
From: Jean Jonethal <jeanjonethal@ya...> - 2016-10-24 20:28:29
|
Die RA- Version beinhaltet einen Optimierer ( Register Allokator ? ) und automatischen Inliner.
Der benutzt einige nicht benutzte Register als Stackerweiterung und vermeidet ein paar Stackzugriffe.Das ergibt dann kompakteren und schnelleren Kode.
Gruß Jean
Michael <mik.kalus@...> schrieb am 22:03 Freitag, 23.September 2016:
So, weiter gehts...
Am 23.09.2016 um 20:32 schrieb Matthias Koch:
> Nein. Unter Linux brauchst Du keine extra Treiber dafür :-)
>
> Reinstöpseln.
> lm4flash mecrisp-stellaris-tm4c1294.bin
Habe mecrsip-stellaris-2.2.9 von sourceforge geholt. Und darin 2 Ordner
die passen könnten, den tm4c1294 und den tm4c1294-ra. In beiden liegt
mecrisp-stellaris-tm4c1294.bin
Sind die gleich? Welche nehme ich? Was bedeutet -ra ?
Michael
------------------------------------------------------------------------------
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@...
https://lists.sourceforge.net/lists/listinfo/amforth-devel
|
|
From: Michael <mik.kalus@gm...> - 2016-09-23 20:02:58
|
So, weiter gehts... Am 23.09.2016 um 20:32 schrieb Matthias Koch: > Nein. Unter Linux brauchst Du keine extra Treiber dafür :-) > > Reinstöpseln. > lm4flash mecrisp-stellaris-tm4c1294.bin Habe mecrsip-stellaris-2.2.9 von sourceforge geholt. Und darin 2 Ordner die passen könnten, den tm4c1294 und den tm4c1294-ra. In beiden liegt mecrisp-stellaris-tm4c1294.bin Sind die gleich? Welche nehme ich? Was bedeutet -ra ? Michael |
|
From: Tristan Williams <home@tj...> - 2016-09-06 10:33:54
|
Hello Matthias, Brilliant. Thank you. Best wishes, Tristan |
|
From: Matthias Trute <mtrute@we...> - 2016-09-05 16:14:32
|
Hi Tristan, > 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 with them. I really > appreciate the forth interpreter here. Whilst doing this I thought > that if I changed my slave processor to an ATmega I might be able to > remove the C++ and write the slave in AmForth. If this has been done > before I would be grateful for any hints. I've started with some code for the slave side. Until now it "only" answers to the ping making the i2c.detect work on the master side. The long term goal is something that Erich did for the RS485 (see commented projects). With rev. 2172 the code is in the avr8/lib/hardware directory, but don't expect too much. It' quite messy and not too well documented. Matthias |
|
From: Tristan Williams <home@tj...> - 2016-09-04 21:45:53
|
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 with them. I really appreciate the forth interpreter here. Whilst doing this I thought that if I changed my slave processor to an ATmega I might be able to remove the C++ and write the slave in AmForth. If this has been done before I would be grateful for any hints. Tristan |
|
From: Matthias Trute <mtrute@we...> - 2016-08-28 08:53:44
|
Hi, The release 6.3 has changes for both controller types, some are common some are specific. The MSP430 now supports the hardware multiplier, if available and adds some more words from the Forth 2012 standard. The AVR parts use a different terminal IO, making it easier to adapt different serial communication setups replacing the pre-defined ones. Both controllers now support application-changeable prompts. A new library example combines defers and lists of exection tokens into one concept called chains. This is inspired from Win32Forth, but uses separate wordlists or stacks instead of linked lists. Details are available in the German FIG periodical "Vierte Dimension" at http://www.forth-ev.de (in German only). Development for the next release has been started by now, some i2c related stuff by now. Have fun Matthias |
|
From: Matthias Trute <mtrute@we...> - 2016-08-15 17:58:02
|
Hi, > 1. The assembler refused to configure a baudrate of 460800. > Increasing baud_maxerror did not help. When it compiled (at > 200 or so) the serial connection displayed garbage. > > I checked the data sheet. It seems to suggest that indeed a > speed larger than 230400 is hard to achieve. But I have not > looked into details let alone tried any tricks. In my world, everything above the 115k limit is high speed computing, other department ;) > Hope this helps. Absolutely. And many thanks to everyone (esp Ian and Tristan) who tested and gave feedback. Your work is highly appreciated. Matthias |
|
From: Erich Wälde <ew.forth@na...> - 2016-08-14 13:10:21
|
Hello all,
Matthias Trute writes:
> Hi,
>
> I need some independent tests, so I'd like to ask for volunteers.
>
> The command prompt got its characters via a simple interrupt
> routine. That works quite well for years now. However some users
> wanted to replace this routine with some other (forth hll) code
> and were unpleasantly surprised that the word INT! did not do what it
> does for all other ISR's. Not surprisingly since that (and only that)
> one interrupt was not dealt with the way all other interrupts got
> handled.
>
> That has changed now. Now every character is processed the "standard"
> way and the INT! word can easily change the actions. I did some
> tests, but for the high speed ones I lack some resources. So I ask
> you to test and give feedback whether the new code works for serial
> line speed like 56k (or more) - my boards don't have the necessary
> baud rate clock quartzes...
>
> Please get the sources from the repository trunk after version 2141
> and recompile them. To check if everything works good enough,
> it is sufficient that you can enter commands at all....
The question was: does receiving data work if serial receive is
done via deferred ISR, not the hard coded one. Especially does
it work at higher baud rates?
So I set out today to run some tests.
Surprisingly, it's not all that clear cut ...
Experiment on atmega644p:
- amforth trunk (6.3), revision 2156
- set WANT_ISR_RX = 1 (default)
WANT_ISR_TX = 0 (default)
- set BAUD_MAXERROR to 10 (default) --- which corresponds to 10%
error allowed, if I read the docs correctly.
- set F_CPU to 18432000
- set BAUD to 4800 ... 115200, 230400, 460800, and maybe higher
For a given baud rate I did
- assemble (wine+AVRASM2) and flash (avrdude) the controller
- connect via minicom, list the dictionary with "words"
- upload a large program file
- from main.fs
- resolve all includes with a small script
- strip (almost) all comments and empty lines with another
small script
- results in 2735 words
- upload with (an old, stupid version of) amforth-upload.py
There should be no receive errors whatsoever! Loading the file
lasted 162 seconds at higher baud rates.
| f_cpu[Hz] | baud[1/s] | load[s] | |
|-----------+-----------+---------+-----------------|
| 1843200 | | | |
| | 4800 | 216 | loads ok, works |
| | 9600 | 181 | dto. |
| | 19200 | 164 | dto. |
| | 38400 | 163 | dto. |
| | 57600 | 162 | dto. |
| | 115200 | 162 | dto. |
| | 230400 | 162 | dto. |
| | 460800 | | assembly error! |
Results:
1. The assembler refused to configure a baudrate of 460800.
Increasing baud_maxerror did not help. When it compiled (at
200 or so) the serial connection displayed garbage.
I checked the data sheet. It seems to suggest that indeed a
speed larger than 230400 is hard to achieve. But I have not
looked into details let alone tried any tricks.
2. RX: The time needed to upload the file seems to be dominated
by compile time rather than transfer time for baudrates of
19200 and larger. To me this boundary seems surprisingly low
...
3. TX: The time needed to fully list the current dictionary (
words ) does change noticably with higher baud rates. Surely
this was one reason why I switched to 115200 baud.
4. Ever since I switched to using baud rate crystals (11.059200
MHz) and a baud rate of 115200 I have not seen any hickups
while uploading program files --- except occasionally when
using rs485 rather than rs232. But that might have other
causes unrelated to the software on the microcontroller and I
did not investigate further.
5. The tests using a 11.059200 MHz crystal are very similar, the
upload time was 225 seconds. Interestingly:
18432000/11059200 = 1.66 whereas
225/162 = 1.40
Interestingly, the upload time does not scale the same way as
the crystal frequency.
Hope this helps.
Cheers,
Erich
|
|
From: Matthias Trute <mtrute@we...> - 2016-07-31 09:35:50
|
Hi Ian, Am Samstag, den 30.07.2016, 06:07 -0400 schrieb Ian Jefferson: > Hi Matthias, > > What kind of hardware would you need? Someone with higher skills to organize my hardware depot ;) In fact: I've ordered a few quartzes by now, spending a few more cents in an already planned order. It only takes time to arrive... Matthias |
|
From: Ian Jefferson <ijeff@sa...> - 2016-07-30 10:45:38
|
Hi Matthias, What kind of hardware would you need? On Fri, 22 Jul 2016, Matthias Trute wrote: > Hi, > I need some independent tests, so I'd like to ask for volunteers. > The command prompt got its characters via a simple interruptroutine. That works quite well for years now. However some users wanted to replace this routine with some other (forth hll) code and were unpleasantly surprised that the word INT! did not do what it does for all other ISR's. Not surprisingly since that (and only that)one interrupt was not dealt with the way all other interrupts got handled. > That has changed now. Now every character is processed the "standard"way and the INT! word can easily change the actions. I did sometests, but for the high speed ones I lack some resources. So I askyou to test and give feedback whether the new code works for serialline speed like 56k (or more) - my boards don't have the necessarybaud rate clock quartzes... > Please get the sources from the repository trunk after version 2141and recompile them. To check if everything works good enough,it is sufficient that you can enter commands at all.... > The MSP430 is a different story, they still lack interrupts completely. > Thanks in advanceMatthias------------------------------------------------------------------------------What NetFlow Analyzer can do for you? Monitors nnetwork bandwidth and trafficpatterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planningreports.http://sdm.link/zohodev2dev_______________________________________________Amforth-devel mailing list for http://amforth.sf.net/Amforth-devel@...://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Tristan Williams <home@tj...> - 2016-07-26 21:42:16
|
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 http://sphinx.mythic-beasts.com/~tristan/files/af230400.tiff It worked for me at both 115200 bps and 230400 bps. However, I am very new to AmForth so I may not have noticed more subtle differences. Tristan On 22Jul16 20:56, Matthias Trute wrote: > Hi, > > I need some independent tests, so I'd like to ask for volunteers. > > The command prompt got its characters via a simple interrupt > routine. That works quite well for years now. However some users > wanted to replace this routine with some other (forth hll) code > and were unpleasantly surprised that the word INT! did not do what it > does for all other ISR's. Not surprisingly since that (and only that) > one interrupt was not dealt with the way all other interrupts got > handled. > > That has changed now. Now every character is processed the "standard" > way and the INT! word can easily change the actions. I did some > tests, but for the high speed ones I lack some resources. So I ask > you to test and give feedback whether the new code works for serial > line speed like 56k (or more) - my boards don't have the necessary > baud rate clock quartzes... > > Please get the sources from the repository trunk after version 2141 > and recompile them. To check if everything works good enough, > it is sufficient that you can enter commands at all.... > > The MSP430 is a different story, they still lack interrupts > completely. > > Thanks in advance > Matthias > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matthias Trute <mtrute@we...> - 2016-07-22 18:56:56
|
Hi, I need some independent tests, so I'd like to ask for volunteers. The command prompt got its characters via a simple interrupt routine. That works quite well for years now. However some users wanted to replace this routine with some other (forth hll) code and were unpleasantly surprised that the word INT! did not do what it does for all other ISR's. Not surprisingly since that (and only that) one interrupt was not dealt with the way all other interrupts got handled. That has changed now. Now every character is processed the "standard" way and the INT! word can easily change the actions. I did some tests, but for the high speed ones I lack some resources. So I ask you to test and give feedback whether the new code works for serial line speed like 56k (or more) - my boards don't have the necessary baud rate clock quartzes... Please get the sources from the repository trunk after version 2141 and recompile them. To check if everything works good enough, it is sufficient that you can enter commands at all.... The MSP430 is a different story, they still lack interrupts completely. Thanks in advance Matthias |
|
From: Matthias Trute <mtrute@we...> - 2016-07-05 17:57:16
|
Am Montag, den 04.07.2016, 21:37 +0200 schrieb MIchael Kalus: > Is there a link to a list of those strange behaving? You can easily reproduce them: just copy a few lines of (assembly) code around. Guess why the file init.asm still exists, the two lines of code belong to the mcu-info structure. But if I move the two lines, the simple test : test ." huhu " ; test fails compiling the word test, most of times freezing the system, sometimes rebooting it. > May be of use beyond amforth. Nobody but me uses assembly for this device ;) Matthias |
|
From: MIchael Kalus <mik.kalus@gm...> - 2016-07-04 19:37:53
|
Is there a link to a list of those strange behaving? May be of use beyond amforth. Michael Am 04.07.2016 20:26 schrieb "Matthias Trute" <mtrute@...>: > Hi, > > It's been a long time since the last release but some strange > effects needed to be handled with the FRAM equipped MSP430 devices. > They behave much like a diva and are worse than the fuses of the > atmega's ;) > > Most of the changes are for the MSP430 devices, I started to learn > the assembler programming for them. Some changes are for both > platforms, details as usual on the homepage http://amforth.sourceforge. > net/ The update from version 6.1 is recommended. > > Have fun > Matthias > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Matthias Trute <mtrute@we...> - 2016-07-04 18:25:51
|
Hi, It's been a long time since the last release but some strange effects needed to be handled with the FRAM equipped MSP430 devices. They behave much like a diva and are worse than the fuses of the atmega's ;) Most of the changes are for the MSP430 devices, I started to learn the assembler programming for them. Some changes are for both platforms, details as usual on the homepage http://amforth.sourceforge. net/ The update from version 6.1 is recommended. Have fun Matthias |
|
From: Matthias Trute <mtrute@we...> - 2016-07-02 08:45:45
|
Am Donnerstag, den 30.06.2016, 10:54 +0100 schrieb Tristan Williams: > Hello James, > > Thank you very much indeed. I needed to adjust for not (yet) having > find-xt but exactly what I needed. Thank you. The anew.frt is available in earlier versions too. Essentially the find-xt used to be find-name, but I decided to rename it to find-xt and give the find-name a new stack effect due to the (then new) name tokens in forth 2012. Bad style, but in the long run morre consistent, I hope. > Which leaves me with one question; what is [defined] used for? Any > pointers greatly appreciated. A common use case is .... [defined] foo [if] ( only if foo is found ) [then] But that does not work with amforth, since [if] and co are not available. I have no use for them ;) Matthias |
|
From: Tristan Williams <home@tj...> - 2016-06-30 09:54:20
|
Hello James, Thank you very much indeed. I needed to adjust for not (yet) having find-xt but exactly what I needed. Thank you. Which leaves me with one question; what is [defined] used for? Any pointers greatly appreciated. Kind regards and thanks, Tristan On 29Jun16 17:11, James Bowman wrote: > Right, it's a tricky problem because (in your example) "stage1" might not > be defined, so stage1 cannot appear in the definition of "check_marker". > > Fortunately Neil Bawd's word ANEW does something similar: > > http://www.wilbaden.com/neil_bawd/tool2002.txt > > His original definitions are: > > : POSSIBLY ( "name" -- ) BL WORD FIND ?dup AND IF EXECUTE THEN ; > > : ANEW ( "name" -- )( Run: -- ) >IN @ POSSIBLY >IN ! MARKER ; > > But in AmForth it is supplied already as common/lib/anew.frt: > > : possibly ( "name" -- ) > > parse-name find-xt if execute then ; > > > > : anew ( "name" -- ) >in @ possibly >in ! marker ; > > > > On Wed, Jun 29, 2016 at 3:37 PM, Tristan Williams <home@...> wrote: > > > 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 > > > > > > : check_marker [defined] stage1 if stage1 else marker stage1 then ; > > > > > > followed by > > > > > > check_maker > > > > > > However, this does not work for me and I suspect this is because of > > > a (another) gap in my understanding. > > > > > > At the interpreter > > > > > > [defined] stage1 > > > > > > gives 0 or -1 as I would hope but I am unable to make progress when I > > > try and put it in a word. > > > > > > Can anyone put me out of my misery? Where am I going wrong? > > > > > > Kind regards and thanks, > > > > > > Tristan > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > > > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > > > present their vision of the future. This family event has something for > > > everyone, including kids. Get more information and register today. > > > http://sdm.link/attshape > > > _______________________________________________ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > Amforth-devel@... > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > > > > ------------------------------------------------------------------------------ > > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > > present their vision of the future. This family event has something for > > everyone, including kids. Get more information and register today. > > http://sdm.link/attshape > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > -- > James Bowman > http://www.excamera.com/ > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: James Bowman <jamesb@ex...> - 2016-06-30 00:11:28
|
Right, it's a tricky problem because (in your example) "stage1" might not be defined, so stage1 cannot appear in the definition of "check_marker". Fortunately Neil Bawd's word ANEW does something similar: http://www.wilbaden.com/neil_bawd/tool2002.txt His original definitions are: : POSSIBLY ( "name" -- ) BL WORD FIND ?dup AND IF EXECUTE THEN ; : ANEW ( "name" -- )( Run: -- ) >IN @ POSSIBLY >IN ! MARKER ; But in AmForth it is supplied already as common/lib/anew.frt: : possibly ( "name" -- ) parse-name find-xt if execute then ; : anew ( "name" -- ) >in @ possibly >in ! marker ; On Wed, Jun 29, 2016 at 3:37 PM, Tristan Williams <home@...> wrote: > 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 > > > > : check_marker [defined] stage1 if stage1 else marker stage1 then ; > > > > followed by > > > > check_maker > > > > However, this does not work for me and I suspect this is because of > > a (another) gap in my understanding. > > > > At the interpreter > > > > [defined] stage1 > > > > gives 0 or -1 as I would hope but I am unable to make progress when I > > try and put it in a word. > > > > Can anyone put me out of my misery? Where am I going wrong? > > > > Kind regards and thanks, > > > > Tristan > > > > > > > > > > > ------------------------------------------------------------------------------ > > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > > present their vision of the future. This family event has something for > > everyone, including kids. Get more information and register today. > > http://sdm.link/attshape > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amforth-devel@... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > -- James Bowman http://www.excamera.com/ |
|
From: Tristan Williams <home@tj...> - 2016-06-29 22:37:16
|
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 > > : check_marker [defined] stage1 if stage1 else marker stage1 then ; > > followed by > > check_maker > > However, this does not work for me and I suspect this is because of > a (another) gap in my understanding. > > At the interpreter > > [defined] stage1 > > gives 0 or -1 as I would hope but I am unable to make progress when I > try and put it in a word. > > Can anyone put me out of my misery? Where am I going wrong? > > Kind regards and thanks, > > Tristan > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |