Menu
▾
▴
amforth-devel
|
From: Enoch <ix...@ho...> - 2012-10-07 23:37:44
|
Hi, On the at90can128, for example, one has to introduce "TCCR0 constant TCCR0B" before uploading lib/hardware/time0.frt How about extending Keith's fantastic shell with conditional upload constructs such as: #ifdev at90can128 %00000000 TCCR0 c! \ stop timer #else %00000000 TCCR0B c! \ stop timer #endif Any better idea? Thanks, Enoch. |
|
From: Matthias T. <mt...@we...> - 2012-10-08 17:36:47
|
Hi, > On the at90can128, for example, one has to introduce "TCCR0 constant > TCCR0B" before uploading lib/hardware/time0.frt > > How about extending Keith's fantastic shell with conditional upload > constructs such as: > > #ifdev at90can128 > %00000000 TCCR0 c! \ stop timer > #else > %00000000 TCCR0B c! \ stop timer > #endif There are a few (~15 IIRC) more devices, that suffer the same problem. Your solution does not scale enough, unfortuatly. > Any better idea? Highly appricated! I considered something like #ifndef TCCR0B #define TCCR0B TCCR0 #endif but who wants to maintain the matching rules? And who wants to check _in detail_ if they are really compatible with each other for every controller type (~120 by now)? I wont do it. Matthias |
|
From: Enoch <ix...@ho...> - 2012-10-08 20:58:59
|
Hi Matthias, Please find attached a patch to Keith's shell script for your consideration. I took the lazy approach of using Python's eval() option and it was quite easy: Two variables: avr - device name string py - a truth value 1st method: #py= avr=="at90can128" #py? "%00000000 TCCR0 c!" if py else "%00000000 TCCR0B c!" 2nd method: #py= TCCR0B #py? "%00000000 TCCR0B c!" if py else "%00000000 TCCR0 c!" If TCCR0B is a known register name py is True, if not py is False (taking advantage of Keith's reg name substitutions). Please comment. Thank you, Enoch. On 10/08/2012 01:36 PM, Matthias Trute wrote: > Hi, > >> On the at90can128, for example, one has to introduce "TCCR0 constant >> TCCR0B" before uploading lib/hardware/time0.frt >> >> How about extending Keith's fantastic shell with conditional upload >> constructs such as: >> >> #ifdev at90can128 >> %00000000 TCCR0 c! \ stop timer >> #else >> %00000000 TCCR0B c! \ stop timer >> #endif > > There are a few (~15 IIRC) more devices, that > suffer the same problem. Your solution does > not scale enough, unfortuatly. > >> Any better idea? > > Highly appricated! > > I considered something like > > #ifndef TCCR0B > #define TCCR0B TCCR0 > #endif > > but who wants to maintain the matching rules? And who > wants to check _in detail_ if they are really compatible > with each other for every controller type (~120 by now)? > I wont do it. > > Matthias > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch |
|
From: Enoch <ix...@ho...> - 2012-10-09 02:24:20
|
Hello again Matthias, Here's the patch at pastebin: http://pastebin.com/NbfGxU3C Thanks, Enoch. On 10/08/2012 01:36 PM, Matthias Trute wrote: > Hi, > >> On the at90can128, for example, one has to introduce "TCCR0 constant >> TCCR0B" before uploading lib/hardware/time0.frt >> >> How about extending Keith's fantastic shell with conditional upload >> constructs such as: >> >> #ifdev at90can128 >> %00000000 TCCR0 c! \ stop timer >> #else >> %00000000 TCCR0B c! \ stop timer >> #endif > > There are a few (~15 IIRC) more devices, that > suffer the same problem. Your solution does > not scale enough, unfortuatly. > >> Any better idea? > > Highly appricated! > > I considered something like > > #ifndef TCCR0B > #define TCCR0B TCCR0 > #endif > > but who wants to maintain the matching rules? And who > wants to check _in detail_ if they are really compatible > with each other for every controller type (~120 by now)? > I wont do it. > > Matthias > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev |
|
From: Matthias T. <mt...@we...> - 2012-10-11 16:49:17
|
Enoch, > Please find attached a patch to Keith's shell script for your > consideration. I took the lazy approach of using Python's eval() option > and it was quite easy: I've difficulties to understand you approach. Do you change the forth code, that gets sent to the controller with the conditionals? The #py directive has what purpose? I'm puzzled... Where do you store the mappings? Looks like you're using the script itself. IMHO not the best place to keep the data.. You introduce a return code in addition to the exception, why? Keith makes an intelligent use of exceptions in his code, I'd keep that design whenever possible. Matthias |
|
From: Enoch <ix...@ho...> - 2012-10-11 19:04:01
|
Hello Matthias, It was a short Python hacking, it turned out that I did not like it myself too :-) #py simply triggers the eval code in the patched amforth-shell.py. Yes, the code sent to the device is being modified by the shell according to the python expression that is embedded in the frt code. This brings me to a more fundamental question which you, as Amforth's BDFL, I feel, need to address. Amforth-shell.py turns the use of frt "&34 constant PORTA" definitions in the code unnecessary as the shell script does these substitutions for you (and saves flash memory). It is great for educational purposes but it creates dependence on loading of the code through amforth-shell.py only. I think Forth tradition is against that, it was supposed to be self contained and operated through a simple terminal... What is your recommended practice? Thanks, Enoch. On 10/11/2012 12:49 PM, Matthias Trute wrote: > Enoch, > >> Please find attached a patch to Keith's shell script for your >> consideration. I took the lazy approach of using Python's eval() option >> and it was quite easy: > > I've difficulties to understand you approach. Do you change > the forth code, that gets sent to the controller with the > conditionals? The #py directive has what purpose? I'm puzzled... > > Where do you store the mappings? Looks like you're using > the script itself. IMHO not the best place to keep the data.. > > You introduce a return code in addition to the exception, why? > Keith makes an intelligent use of exceptions in his code, I'd > keep that design whenever possible. > > Matthias > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev |
|
From: Erich W. <ew....@na...> - 2012-10-11 19:24:45
|
Hi Enoch,
On 10/11/2012 09:03 PM, Enoch wrote:
> This brings me to a more fundamental question which you, as Amforth's
> BDFL, I feel, need to address.
>
> Amforth-shell.py turns the use of frt "&34 constant PORTA" definitions
> in the code unnecessary as the shell script does these substitutions for
> you (and saves flash memory). It is great for educational purposes but
> it creates dependence on loading of the code through amforth-shell.py
> only. I think Forth tradition is against that, it was supposed to be
> self contained and operated through a simple terminal...
>
> What is your recommended practice?
I'm having a similar opinion. amforth-shell.py is impressive, no
question. However, IMHO it blurs the line between "what _I_ know"
and "what the machine knows for me", a state which I'm not too
fond of. Your mileage may vary.
So according to "make one programm do one thing well" I have
created two little perl filters, one will recursively
expand all "include"s in a file and produce the expanded code, the
other is stripping comments and empty lines, just to reduce the
number of transferred bytes (it may destroy ." ..." strings though).
The I use amforth-upload.py to transfer the stripped file.
Since I'm very lazy, I have hacked up a Makefile snippet to do this
for me:
--- Makefile -----------------------------------------------------
...
TARGET=main
CONSOLE=/dev/ttyUSB0
...
upload_file:
cat $(TARGET).fs | unfold_fs > $(TARGET).fs.unfold
trim_fs $(TARGET).fs.unfold > $(TARGET).fs.upload
upload: upload_file
amforth-upload.py -t $(CONSOLE) $(TARGET).fs.upload
--- unfold_fs -----------------------------------------------------
#!/usr/bin/perl
# 2007-12-08 EW
#
# filter, read all input, expand lines like
# "^include filename$"
# with the content found in filename
#
# this is written unfold amforth projects before
# transferring them to the target controller.
use warnings;
use strict;
my $Prog=$0;
my $file="";
my $pattern='^[#]*include\s+(\S+)';
my $comment='\ ---';
my $verbose=0;
while (<>)
{
if (m/$pattern/)
{
$file = "$1";
print STDERR " $file\n" if ($verbose);
if (not -r $file)
{
print STDERR "$Prog: file $file not found!\n";
exit 2;
}
print "$comment include begin $file\n";
system("$Prog $file") == 0 or die "failed.\n";
print "$comment include end $file\n";
}
else
{
print $_;
}
}
--- trim_fs -------------------------------------------------------
#!/usr/bin/perl
# 2007-12-08 EW
# trim_fs
#
# filter, remove comments, leading and trailing whitespace and empty lines
#
# this is written to trim unfolded amforth projects
use warnings;
use strict;
while (<>)
{
chomp;
s/\\[ \t].*$//; # remove line comments
s/\( .* \)//; # remove inline comments
#s/^\s+//; # delete leading whitespace / well no, keep indendation
s/\s+$//; # delete trailing whitespace
s/\b\s+/ /g; # compress white space after first word
next if /^$/; # delete empty lines
print "$_\n";
}
-------------------------------------------------------------------
If you or anyone on the list likes this, feel free to use or adapt it to
your needs.
Cheers,
Erich
|
|
From: Matthias T. <mt...@we...> - 2012-10-13 15:29:09
|
Hi, > What is your recommended practice? Very simple: Use what you like most. All tools that I include with amforth are the ones I consider useful for others as well. I do not enforce any of them. The shell has a few advantages over a dumb terminal and I like to use it. YMMV. Matthias |
|
From: Enoch <ix...@ho...> - 2012-10-13 17:32:34
|
On 10/13/2012 11:29 AM, Matthias Trute wrote: > Hi, > >> What is your recommended practice? > > Very simple: Use what you like most. All tools > that I include with amforth are the ones I consider > useful for others as well. I do not enforce any of > them. > > The shell has a few advantages over a dumb terminal > and I like to use it. YMMV. > > Matthias Matthias, I agree. I use it too now. We do still have a problem how to deal with hardware idiosyncrasies as timer0.frt demonstrates. It should not be dealt with through the shell (re my ill thought #py idea). The generic frt code should include some preprocessing instructions to produce MCU specific code, m4 perhaps? Once you decide on the standard people would follow :-) Thanks, Enoch. |
|
From: Matthias T. <mt...@we...> - 2012-10-13 18:53:59
|
Hi, > We do still have a problem how to deal with hardware idiosyncrasies as > timer0.frt demonstrates. It should not be dealt with through the shell > (re my ill thought #py idea). > > The generic frt code should include some preprocessing instructions to > produce MCU specific code, m4 perhaps? A preprocessor would create a similiar dependency on additional tools that (at least) Erich dislikes. m4 (or cpp) are tools for the unix people, but the majority of the amforth users use windows (for whatever reason....) > Once you decide on the standard people would follow :-) Hell, no! I wont make decisions for you ;) maybe a preprocessor in (g)forth can help us? Matthias |
|
From: Enoch <ix...@ho...> - 2012-10-13 20:51:57
|
On 10/13/2012 02:53 PM, Matthias Trute wrote: > Hi, > >> We do still have a problem how to deal with hardware idiosyncrasies as >> timer0.frt demonstrates. It should not be dealt with through the shell >> (re my ill thought #py idea). >> >> The generic frt code should include some preprocessing instructions to >> produce MCU specific code, m4 perhaps? > > A preprocessor would create a similiar dependency on > additional tools that (at least) Erich dislikes. > > m4 (or cpp) are tools for the unix people, but the > majority of the amforth users use windows (for whatever > reason....) Because Atmel provides a great IDE for Windows free of charge :-) > >> Once you decide on the standard people would follow :-) > > Hell, no! I wont make decisions for you ;) > > maybe a preprocessor in (g)forth can help us? I think that any Amforth pre-processing code should syntactically look very different from the surrounding Amforth code. Mixing Gforth with Amforth may lead to confusion where the code actually executes. All Unix tools are easily available now in windows. We just need to decide which tool is most suitable for adapting a generic Forth library code for a particular AVR MCU. I see this tool utilized at Amforth install stage. Perhaps it would unify those appl/ projects... Comments please. Thanks, Enoch. > > Matthias > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev |
|
From: Matthias T. <mt...@we...> - 2012-10-14 09:01:45
|
Am 13.10.2012 22:51, schrieb Enoch: > On 10/13/2012 02:53 PM, Matthias Trute wrote: >> Hi, >> >>> We do still have a problem how to deal with hardware idiosyncrasies as >>> timer0.frt demonstrates. It should not be dealt with through the shell >>> (re my ill thought #py idea). >>> >>> The generic frt code should include some preprocessing instructions to >>> produce MCU specific code, m4 perhaps? >> >> A preprocessor would create a similiar dependency on >> additional tools that (at least) Erich dislikes. >> >> m4 (or cpp) are tools for the unix people, but the >> majority of the amforth users use windows (for whatever >> reason....) > > Because Atmel provides a great IDE for Windows free of charge :-) > >> >>> Once you decide on the standard people would follow :-) >> >> Hell, no! I wont make decisions for you ;) >> >> maybe a preprocessor in (g)forth can help us? > > > I think that any Amforth pre-processing code should syntactically look > very different from the surrounding Amforth code. Mixing Gforth with > Amforth may lead to confusion where the code actually executes. > > All Unix tools are easily available now in windows. We just need to > decide which tool is most suitable for adapting a generic Forth library > code for a particular AVR MCU. I see this tool utilized at Amforth > install stage. Perhaps it would unify those appl/ projects... The easiest way would an implementation of [if] and friends ... \ older mcu's may need [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then] [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then] .... That would not even require any external tool at all Volunteers welcome ;) (be aware: its not that easy as its seems to be). I just added http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log it does not work in interactive mode however. Matthias |
|
From: Enoch <ix...@ho...> - 2012-10-15 00:18:05
|
On 10/14/2012 05:01 AM, Matthias Trute wrote: > Am 13.10.2012 22:51, schrieb Enoch: >> On 10/13/2012 02:53 PM, Matthias Trute wrote: >>> Hi, >>> >>>> We do still have a problem how to deal with hardware idiosyncrasies as >>>> timer0.frt demonstrates. It should not be dealt with through the shell >>>> (re my ill thought #py idea). >>>> >>>> The generic frt code should include some preprocessing instructions to >>>> produce MCU specific code, m4 perhaps? >>> >>> A preprocessor would create a similiar dependency on >>> additional tools that (at least) Erich dislikes. >>> >>> m4 (or cpp) are tools for the unix people, but the >>> majority of the amforth users use windows (for whatever >>> reason....) >> >> Because Atmel provides a great IDE for Windows free of charge :-) >> >>> >>>> Once you decide on the standard people would follow :-) >>> >>> Hell, no! I wont make decisions for you ;) >>> >>> maybe a preprocessor in (g)forth can help us? >> >> >> I think that any Amforth pre-processing code should syntactically look >> very different from the surrounding Amforth code. Mixing Gforth with >> Amforth may lead to confusion where the code actually executes. >> >> All Unix tools are easily available now in windows. We just need to >> decide which tool is most suitable for adapting a generic Forth library >> code for a particular AVR MCU. I see this tool utilized at Amforth >> install stage. Perhaps it would unify those appl/ projects... > > The easiest way would an implementation of [if] and friends > ... > \ older mcu's may need > [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then] > [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then] > .... > > That would not even require any external tool at all > > Volunteers welcome ;) (be aware: its not that easy > as its seems to be). I just added > http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log > it does not work in interactive mode however. That's based on a forth200x extension and I like it. Will you document it (i.e., refcard) when it works in interactive mode as well? A somewhat related question. Can this initialization and other initializations be uninstalled (words removed) after execution to save space? Thank you, Enoch. > > Matthias > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev |
|
From: Matthias T. <mt...@we...> - 2012-10-16 17:09:32
|
Hi, >> \ older mcu's may need >> [undefined] TCCR0B [if] TCCR0 constant TCCR0B [then] >> [undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then] >> .... >> >> That would not even require any external tool at all >> >> Volunteers welcome ;) (be aware: its not that easy >> as its seems to be). I just added >> http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log >> it does not work in interactive mode however. > > That's based on a forth200x extension and I like it. Will you document > it (i.e., refcard) when it works in interactive mode as well? _when_ yes. Probably in the recipes sections. > A somewhat related question. Can this initialization and other > initializations be uninstalled (words removed) after execution to save > space? Not really. FORGET is not state-of-the-art and MARKER resets the whole dictionary, not a wordlist only. That makes an implementation of [IF] and friends on the host side (e.g. the shell) attractive, IMHO. Matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X