Menu
▾
▴
amforth-devel
|
From: Mike B. <mi...@mj...> - 2010-03-03 18:15:44
|
Having read the documentation for AMForth, I am keen to use it for a current project, but it is still not clear to me how one initially downloads the compiled hex (or object) file to the AVR. Some kind of programmer is surely implied in addition to the PC on which the file has been generated, though it seems to be stated that this can be achieved with only a serial link to the target machine. The on-chip UART cannot be functional on a virgin chip (and in any case RS232 levels would, of course, need at least level conversion). The only methods I am aware of are "parallel programming" (simple in concept but requires the manipulation of most AVR pins) or "serial programming" (alias "In System Programming"), using a 6-pin SPI interface, perhaps with the addition of a clock. The four SPI signal pins (MOSI, MISO, RESET and SCLK) could in principle be driven from a parallel port, as in the SP12 project - perhaps the answer. What am I missing? Mike Beach |
|
From: Erich W. <ew....@na...> - 2010-03-03 20:11:24
|
Hello Mike, Mike Beach wrote: > ... The on-chip UART cannot be functional on a virgin chip (and in > any case RS232 levels would, of course, need at least level conversion). The only methods > I am aware of are "parallel programming" (simple in concept but requires the manipulation > of most AVR pins) or "serial programming" (alias "In System Programming"), using a 6-pin > SPI interface, perhaps with the addition of a clock. The four SPI signal pins (MOSI, MISO, > RESET and SCLK) could in principle be driven from a parallel port, as in the SP12 project - > perhaps the answer. In-Serial-Programming is the answer, and I'm using the sp12 Programmer, too! :-) Cheers, Erich |
|
From: Erich W. <ew....@na...> - 2010-03-03 20:16:59
|
Correcting myself: Erich Waelde wrote: > Hello Mike, > > Mike Beach wrote: >> ... The on-chip UART cannot be functional on a virgin chip (and in any >> case RS232 levels would, of course, need at least level conversion). >> The only methods I am aware of are "parallel programming" (simple in >> concept but requires the manipulation of most AVR pins) or "serial >> programming" (alias "In System Programming"), using a 6-pin SPI >> interface, perhaps with the addition of a clock. The four SPI signal >> pins (MOSI, MISO, RESET and SCLK) could in principle be driven from a >> parallel port, as in the SP12 project - perhaps the answer. > > In-Serial-Programming is the answer, -----^^^^^ SYSTEM! Unbelievable. > and I'm using the sp12 Programmer, too! :-) > > Cheers, > Erich |
|
From: Andy K. <an...@ak...> - 2010-03-03 21:04:21
|
Yup ISP is it, there are a few options. 1. As below. 2. Google Pony Programmer, and make up a parallel port to ISP adapter from the schematic (Drive with avrdude) 3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch as part of the examples that can be used to convert the Arduino into an AVRISP programmer. 4. Buy puker Atmel AVRISP One or other of the above are worth having. Even if you down tools on Forth and later go for arduino having the above to burn bootloaders into blank chips is great for your own projects. (Prototyped on an arduino) Hope some of this helps. Cheers Andy Kirby Erich Waelde wrote: > Correcting myself: > > Erich Waelde wrote: >> Hello Mike, >> >> Mike Beach wrote: >>> ... The on-chip UART cannot be functional on a virgin chip (and in any >>> case RS232 levels would, of course, need at least level conversion). >>> The only methods I am aware of are "parallel programming" (simple in >>> concept but requires the manipulation of most AVR pins) or "serial >>> programming" (alias "In System Programming"), using a 6-pin SPI >>> interface, perhaps with the addition of a clock. The four SPI signal >>> pins (MOSI, MISO, RESET and SCLK) could in principle be driven from a >>> parallel port, as in the SP12 project - perhaps the answer. >> In-Serial-Programming is the answer, > -----^^^^^ SYSTEM! Unbelievable. > >> and I'm using the sp12 Programmer, too! :-) >> >> Cheers, >> Erich > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Mike B. <mi...@mj...> - 2010-03-03 22:34:41
|
Many thanks, Erich and Andy, for your swift responses. Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe someone will add a few words to the AMForth documentation.) Good to know that the SP12 method does work, and to see some options. The serial comms method presumably kicks in once you have a running system with the requisite level & polarity match to RS232. (Presumably AMForth sets up the USART for that.) Mike > Yup ISP is it, there are a few options. > > 1. As below. > 2. Google Pony Programmer, and make up a parallel port to ISP adapter > from the schematic (Drive with avrdude) > 3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch > as part of the examples that can be used to convert the Arduino into an > AVRISP programmer. > 4. Buy puker Atmel AVRISP > > One or other of the above are worth having. Even if you down tools on > Forth and later go for arduino having the above to burn bootloaders into > blank chips is great for your own projects. (Prototyped on an arduino) > > Hope some of this helps. > > Cheers > > Andy Kirby > |
|
From: Andy K. <an...@ak...> - 2010-03-04 21:22:32
|
What would be really cool would be if you could take an off the shelf Arduino Mega, burn amforth onto it and then use this Forthduino to clone itself to other off the shelf Arduino Mega's I guess a new design of Atmel based micro board that was purely amforth would be cool too. Mike Beach wrote: > Many thanks, Erich and Andy, for your swift responses. > > Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe > someone will add a few words to the AMForth documentation.) > Good to know that the SP12 method does work, and to see some options. > > The serial comms method presumably kicks in once you have a running system with the > requisite level & polarity match to RS232. (Presumably AMForth sets up the USART for > that.) > > Mike > >> Yup ISP is it, there are a few options. >> >> 1. As below. >> 2. Google Pony Programmer, and make up a parallel port to ISP adapter >> from the schematic (Drive with avrdude) >> 3. If you have an arduino and the ver 18 IDE there is an AVRISP sketch >> as part of the examples that can be used to convert the Arduino into an >> AVRISP programmer. >> 4. Buy puker Atmel AVRISP >> >> One or other of the above are worth having. Even if you down tools on >> Forth and later go for arduino having the above to burn bootloaders into >> blank chips is great for your own projects. (Prototyped on an arduino) >> >> Hope some of this helps. >> >> Cheers >> >> Andy Kirby >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Tom A. <xy...@sy...> - 2010-03-04 22:29:13
|
On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote: > What would be really cool would be if you could take an off the shelf > Arduino Mega, burn amforth onto it and then use this Forthduino to clone > itself to other off the shelf Arduino Mega's > > I guess a new design of Atmel based micro board that was purely amforth > would be cool too. Making amforth work with the Arduino bootloader I think would open up amforth to a lot more people who may not otherwise want to undertake trying to play with it. Forth has a somewhat bad ( un-deserved ) reputation as being difficult to deal with as it is. Having it incompatible with widely available cheap hardware just adds to that. The Arduino bootloader is nothing magical. Its just a simple software implementation of the STK500 protocol. Going with Arduino vs a dedicated amforth board opens up amforth to the world of arduino "shields" ( I hate that name ) which widens up the hardware available to quickly throw at a project. I know there are reasons why its not supported, like Arduino didn't exist with amforth first came about, I'm only saying it'd be nice. I wish I had the skillset to make it happen. It is worth pointing out that a USB based Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think ). That makes it fairly easy to turn an Arduino Mega into an AmforthMega. Easy but not trivial. Supporting the loader would make it trivial... -- -------------------------------------------------------------------- - Tom Arnold - "...is it a virus, a drug, or a religion?" - Sysabend Caretaker - Juanita Shrugs. "What's the difference?" ------------------------ -- Neal Stephenson, Snow Crash |
|
From: Andy K. <an...@ak...> - 2010-03-04 22:36:18
|
Must admit I agree with mathias re the unsuitability of retaining the arduino bootloader. I do however agree that leveraging amforth using off the shelf commodity hardware. ie a re-purposed arduino mega board. Would be a definite boost for the project. The are available very cost effectively, www.DFRobot.com are even making them and exporting them from china. Tom Arnold wrote: > On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote: >> What would be really cool would be if you could take an off the shelf >> Arduino Mega, burn amforth onto it and then use this Forthduino to clone >> itself to other off the shelf Arduino Mega's >> >> I guess a new design of Atmel based micro board that was purely amforth >> would be cool too. > > Making amforth work with the Arduino bootloader I think would open up > amforth to a lot more people who may not otherwise want to undertake trying > to play with it. Forth has a somewhat bad ( un-deserved ) reputation as being > difficult to deal with as it is. Having it incompatible with widely > available cheap hardware just adds to that. The Arduino bootloader is > nothing magical. Its just a simple software implementation of the STK500 > protocol. > > Going with Arduino vs a dedicated amforth board opens up amforth to the > world of arduino "shields" ( I hate that name ) which widens up the hardware > available to quickly throw at a project. > > I know there are reasons why its not supported, like Arduino didn't exist > with amforth first came about, I'm only saying it'd be nice. I wish I had > the skillset to make it happen. It is worth pointing out that a USB based > Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think > ). That makes it fairly easy to turn an Arduino Mega into an AmforthMega. > Easy but not trivial. Supporting the loader would make it trivial... > |
|
From: Erich W. <ew....@na...> - 2010-03-05 20:02:15
|
Hi folks, Tom Arnold wrote: > On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote: >> What would be really cool would be if you could take an off the shelf >> Arduino Mega, burn amforth onto it and then use this Forthduino to clone >> itself to other off the shelf Arduino Mega's >> >> I guess a new design of Atmel based micro board that was purely amforth >> would be cool too. > > Making amforth work with the Arduino bootloader I think would open up > amforth to a lot more people who may not otherwise want to undertake trying > to play with it. Forth has a somewhat bad ( un-deserved ) reputation as being > difficult to deal with as it is. Having it incompatible with widely > available cheap hardware just adds to that. The Arduino bootloader is > nothing magical. Its just a simple software implementation of the STK500 > protocol. > > Going with Arduino vs a dedicated amforth board opens up amforth to the > world of arduino "shields" ( I hate that name ) which widens up the hardware > available to quickly throw at a project. > > I know there are reasons why its not supported, like Arduino didn't exist > with amforth first came about, I'm only saying it'd be nice. I wish I had > the skillset to make it happen. It is worth pointing out that a USB based > Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think > ). That makes it fairly easy to turn an Arduino Mega into an AmforthMega. > Easy but not trivial. Supporting the loader would make it trivial... > I agree very much with this comment. I'm trying to set up a class to teach microcontroller programming using amforth on an atmega32 or similar. We had long and somewhat heated discussions about the hardware to use. We are still very much undecided. Making amforth work with the arduino boot loader requires some work on the arduino bootloader, as far as I have understood this. It's not impossible. It just needs to be done. The key point is that the workings of i! and i@ must reside in the protected flash (boot loader area). Or something along these lines. Cheers, Erich |
|
From: Andy K. <an...@ak...> - 2010-03-07 13:27:57
|
Erich I have read the docs explaining the issues with the bootloader and arduino and fully agree. You are somewhat caught by how the architecture of the AVR's was designed. I don't see it as being a limitation of either amforth or Arduino. They are quite different animals. Trying to make one like the other could be a mistake. A minimalist AVR stamp sounds like a good idea. This though has been done and they are available to buy off the shelf as mass produced commodity hardware. ie quite inexpensive. In the interim, all (an easy statement to make) that amforth appears to lack for it to be able to give newbies a quick way in is a binary image (no compiling, or tool-chain necessary) for a very select number of off the shelf micro boards, and a detailed how-to do ICSP using avrdude and ultimately from a board running amforth (board to identical board clone using a forth programming routine). I fully agree that anyone capable of contributing to the current project would have the necessary skills already. What about the next generation of would be forth hackers that have yet to discover that they are up for it though ?? I think that although awesome the amforth project is at the same cross roads as many forths before it. It needs something more (perhaps only a little thing or two) to make it sufficiently accessible to non forth users who are interested. Feed the interest and this new blood will take itself to the next screen/level. Maybe they will by pass toolchain and C development altogether and settle into entirely native forth development. This is one of forths more appealing aspects. I think there is an opening for new forthies to contribute forth code towards a growing library that resides upon the amforth foundations. If we can get them there......... Erich Waelde wrote: > Hi folks, > > Tom Arnold wrote: >> On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote: >>> What would be really cool would be if you could take an off the shelf >>> Arduino Mega, burn amforth onto it and then use this Forthduino to clone >>> itself to other off the shelf Arduino Mega's >>> >>> I guess a new design of Atmel based micro board that was purely amforth >>> would be cool too. >> Making amforth work with the Arduino bootloader I think would open up >> amforth to a lot more people who may not otherwise want to undertake trying >> to play with it. Forth has a somewhat bad ( un-deserved ) reputation as being >> difficult to deal with as it is. Having it incompatible with widely >> available cheap hardware just adds to that. The Arduino bootloader is >> nothing magical. Its just a simple software implementation of the STK500 >> protocol. >> >> Going with Arduino vs a dedicated amforth board opens up amforth to the >> world of arduino "shields" ( I hate that name ) which widens up the hardware >> available to quickly throw at a project. >> >> I know there are reasons why its not supported, like Arduino didn't exist >> with amforth first came about, I'm only saying it'd be nice. I wish I had >> the skillset to make it happen. It is worth pointing out that a USB based >> Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think >> ). That makes it fairly easy to turn an Arduino Mega into an AmforthMega. >> Easy but not trivial. Supporting the loader would make it trivial... >> > > I agree very much with this comment. I'm trying to set up a class to teach > microcontroller programming using amforth on an atmega32 or similar. We had > long and somewhat heated discussions about the hardware to use. We are > still very much undecided. > > Making amforth work with the arduino boot loader requires some work on the > arduino bootloader, as far as I have understood this. It's not impossible. It > just needs to be done. The key point is that the workings of i! and i@ must > reside in the protected flash (boot loader area). Or something along > these lines. > > Cheers, > Erich > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Erich W. <ew....@na...> - 2010-03-07 14:13:16
|
Hi Andy,
thanks for your detailed reply.
To expand more on the "teaching class" thing ...
I would like to see a small board with
1. a usb connection, which
a. brings in power
b. connects to the serial tx/rx port
AND most importantly
c. also provides a way to reload the board from scratch,
be it In-System-Programming or JTAG or something else.
It is my firm believe that a participant of the class must be
able to load a virgin controller before the class is finished.
2. a prototype area
It also is my firm believe that a board must be extensible
somehow. Arduino shields are one way to do this.
3. the controller itself should be "removable" or exchangeable.
It has hit me more than once, that I suspected portpins to be broken.
So I insert another controller an see if the problem changes. There
is no other way to rule out a ``faulty'' controller. So I would
content with a little DIL-40 sized board with a MLF sized atmega-32
on top, for example.
4. some predefined periphery for the class
a. a RGB led connected to the PWM Pins.
b. some (4?) normal leds, some switches
c. a buzzer or
d. a small H-bridge for a stepper motor
e. pullups for i2c, a sensor (temperature) or clock
or a 1-wire controller
f. a connector for a 10x2 LCDisplay
g. a poti for one of the ADC pins
I want to have this, because I believe that only sufficiently
complex examples are going to hook newbies. ``let's blink an LED''
is a necessary step, but must not be the last one. ``let's make
the color of the led change any way we want, e.g. driven by the
temperature sensor ...'' sounds much better to me. But I may be
wrong.
Then, if the board is readily availabe, people can use this for their
next project without thinking.
Bootloader: I personally don't need it. If it helps a newbie to
start fiddling with controllers, fine. I need to teach how to get
a virgin controller off the ground anyway.
How do Arduino folks get a virgin controller flashed with the boot
loader?
It seems, we largely agree on this stuff.
Matthias is making another point: If we do not provide quite a number
of forth modules to access sensors and stuff, we won't get far. Look
at perl. Try to imagine perl without CPAN. So I ``donated'' the ewlib
directory with hopefully useful stuff.
We'll see. I want to get my current pet project out of the way before
trying to shape up a class. No need to hurry.
Btw: I went to FOSDEM (Brussels) beginning of February. The reprap folks
were there, too. But I missed to ask you, whether you went there as well.
Cheers,
Erich
|
|
From: Matthias T. <mt...@we...> - 2010-03-07 19:39:22
|
Andy, > I have read the docs explaining the issues with the bootloader and > arduino and fully agree. You are somewhat caught by how the architecture > of the AVR's was designed. I don't see it as being a limitation of > either amforth or Arduino. They are quite different animals. Trying to > make one like the other could be a mistake. > It's not a limitation, but a question of what a program could do with the varios types of memories in the atmegas. IMHO most of the programmers think of the flash as a read-only mempory that needs hugh amounts of work to deal with. At most they place some constant data (string literals) in it. The bootloaders reflect that in many ways: They do not provide an API for the essential flash write operation, this function is only available if the bootloader reads data from the serial line. If you take a deeper look at the code, they usually do not use function (if coded in C) but operate in a single main() function without split-out modules, that could theoretically re-arranged to call the result an API. Back to the arduino: The hardware works pretty well with amforth, the only thing missing is the arduino bootloader, that is not able to flash the amforth binary. If you use some other method for transferring amforth, everything's fine. But it's probably not an arduino anymore (the bootloader has a monitor as a debugging aid as well) since you cannot use the arduino software any longer. > In the interim, all (an easy statement to make) that amforth appears to > lack for it to be able to give newbies a quick way in is a binary image > (no compiling, or tool-chain necessary) for a very select number of off > the shelf micro boards, and a detailed how-to do ICSP using avrdude and > ultimately from a board running amforth (board to identical board clone > using a forth programming routine). > There are way too many different boards out there, so I decided against selecting on of them and provide hex files for it. The AVR Butterfly is an exception, but it is somehow the same as the arduino: The bootloader is in the way: the one from atmel is unusable and once amforth is on the chip, you are on you own. Since the use of an programming hardware tool is essential for using amforth, I selected the "advanced end uses" as the intended audience. It's definitly (and sadly) not a beginners toy... > I fully agree that anyone capable of contributing to the current project > would have the necessary skills already. What about the next > generation of would be forth hackers that have yet to discover that they > are up for it though ?? > Really good question. IMHO the most interesting part is that forth gives you an extendible command interpreter at hand. The price is that you need to learn how to deal with microcontrollers and that there is a tool chain with both soft- and hardware to be used. Matthias |
|
From: Andy K. <an...@ak...> - 2010-03-07 21:43:19
|
Mathias I think we probably agree on a large percentage of the below. Where we probably diverge a touch is that I think forth should be sufficient in and of itself. I should be able to program in forth and create further firmware in the same forth. I should be able to do everything (including put a forth environment on to a virgin chip) without ever needing anything but forth. I am principally a C and Assembler programmer, programming for me comes before the language that the program is expressed in. (It's probably as a result of a CS degree and background) Whilst I can and do program in a number of languages (professionally and otherwise) I fail to see why anyone else should...... Being multi lingual is great (for me) as a European (Multi lingual wet ware environment) I value it highly (multi lingual firm/hardware environment). Unfortunately a large proportion of humanity is no where near as gifted (Nor as talented) why should they miss out and be unable to contribute their own capabilities (gifted or talented). Because they are linguistically challenged. Forth is a very particular case in point. It isn't suitable for everyone. Not everyone can get a grip on RP (Reverse Polish, or stack based) notation much less the programmatic equivalent. Their minds don't work that way. By the same token if their minds do but they struggle with infix notation why should they have to bother with C, or any other infix language (that can be used to express computer instruction). Mathias I don't know if you are gifted or talented (or both), certainly you are a clever guy. Clearly you have proved yourself many times over by producing amforth. I think you are missing out on your just recognition through amforth being difficult to adopt by folk who don't have enough languages under their belt. Erich Yup you have found me out, I have been a militant supporter of Open source and "Standing on the shoulders of giants" since before the INTERNET was graphical (As well as contributing fiscally to the FSF, and always will do). The last 2 or 3 years most of my support has been behind the RepRap project http://reprap.org. I can see a big future for amforth in synergy with this project if it can get over it's Arduino Hardware allergy. I really wouldn't want to see either project struggle for the influence of the other though......... Matthias Trute wrote: > Andy, > >> I have read the docs explaining the issues with the bootloader and >> arduino and fully agree. You are somewhat caught by how the architecture >> of the AVR's was designed. I don't see it as being a limitation of >> either amforth or Arduino. They are quite different animals. Trying to >> make one like the other could be a mistake. >> > > It's not a limitation, but a question of what a program could do > with the varios types of memories in the atmegas. IMHO most of > the programmers think of the flash as a read-only mempory that > needs hugh amounts of work to deal with. At most they place > some constant data (string literals) in it. The bootloaders reflect > that in many ways: They do not provide an API for the essential > flash write operation, this function is only available if the bootloader > reads data from the serial line. If you take a deeper look at the code, > they usually do not use function (if coded in C) but operate > in a single main() function without split-out modules, that could > theoretically re-arranged to call the result an API. > > Back to the arduino: The hardware works pretty well with amforth, > the only thing missing is the arduino bootloader, that is not able > to flash the amforth binary. If you use some other method for > transferring amforth, everything's fine. But it's probably not an > arduino anymore (the bootloader has a monitor as a debugging aid > as well) since you cannot use the arduino software any longer. >> In the interim, all (an easy statement to make) that amforth appears to >> lack for it to be able to give newbies a quick way in is a binary image >> (no compiling, or tool-chain necessary) for a very select number of off >> the shelf micro boards, and a detailed how-to do ICSP using avrdude and >> ultimately from a board running amforth (board to identical board clone >> using a forth programming routine). >> > > There are way too many different boards out there, so I decided > against selecting on of them and provide hex files for it. The > AVR Butterfly is an exception, but it is somehow the same as the > arduino: The bootloader is in the way: the one from atmel is > unusable and once amforth is on the chip, you are on you own. > > Since the use of an programming hardware tool is essential for > using amforth, I selected the "advanced end uses" as the intended > audience. It's definitly (and sadly) not a beginners toy... > >> I fully agree that anyone capable of contributing to the current project >> would have the necessary skills already. What about the next >> generation of would be forth hackers that have yet to discover that they >> are up for it though ?? >> > > Really good question. IMHO the most interesting part is that > forth gives you an extendible command interpreter at hand. > The price is that you need to learn how to deal with microcontrollers > and that there is a tool chain with both soft- and hardware to be used. > > > Matthias > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Matthias T. <mt...@we...> - 2010-03-11 19:07:47
|
Hi Andy, > Mathias > > I think we probably agree on a large percentage of the below. > > Where we probably diverge a touch is that I think forth should be > sufficient in and of itself. > I see the point and agree with you that we disagree ;=) > I should be able to program in forth and create further firmware in the > same forth. I should be able to do everything (including put a forth > environment on to a virgin chip) without ever needing anything but forth. > Thats possible to do. Given that the controllers use the same memory architecture. For different systems, it's not that easy. But I miss the real need to do that task. I know of a user that wanted to build a network of controllers that share forth source code, but I do not remember him talking about initializing the bare metal using the same way. > Mathias I don't know if you are gifted or talented (or both), certainly > you are a clever guy. Clearly you have proved yourself many times over > by producing amforth. I think you are missing out on your just > recognition through amforth being difficult to adopt by folk who don't > have enough languages under their belt. > I know that amforth is difficult to use for an absolute beginner. For both langauge and hardware reasons. I myself had to spend a lot of time until my first microcontroller program did run (no, it was not amforth but a simple "hello world" that flashed a LED). The only way around I see is that those people get a pre-programmed chip / complete system. The arduino has it's success mainly because of those pre-programmed hardware ready to use. Thinking that approach further: the amforth core system can reside within 8KB flash, selecting an atmega with that boot sector size would allow an "undestroyable" amforth system. No user could overwrite the forth system at will or by mistake. Well, there are still a few things more to do, but that would work. Matthias |
|
From: Kalus M. <mic...@on...> - 2010-05-19 21:31:54
|
HI. Am 19.05.2010 um 15:01 schrieb an...@ki...: .. > There is perhaps a missed oportunity > to implement something like a "clone" word that will allow an amforth > installation to clone itself (via ICSP) to an identical but empty > atmel > device. Yes, a clone word should be there in amforth. I'll think about it. Michael |
|
From: <an...@ki...> - 2010-05-20 09:14:45
|
Michael That would be great. It may (or may not) be useful to take a peak at the ICSP programming code for the arduino. It can be found in the example code for V18 of the arduino IDE and is called ArduinoISP. This emulates the AVR ISP I think using the STK protocol. Certainly there is a whole bunch that can be trimmed out for a more simple clone function ie the STK protocol and a whole bunch of the host comms code. It is written in C and I am certainly not suggesting doing similar. It would be useful though to pull apart and understand the programming algorithms and bit banging etc though. An optionally overridden check of the device ID's could be used to ensure that a successful clone is possible. I was sugesting overridden because Atmel do have a habit of bringing out new variants of their processors that are directly compatible but have a different device ID. I am thinking of the "p" or low power variants here. ie the 644 and 644p are 100% compatible code wise from 644 => 644p. If you already had a bunch of this covered, sorry. Not knowing I thought it better to contribute just in case it was of some use. Cheers Andy Kirby PS off to play some more with getting amforth onto an Arduino Mega (ATMega1280). I have got it assembling and loading but does not yet run. Kalus Michael wrote: > HI. > > Am 19.05.2010 um 15:01 schrieb an...@ki...: > .. >> There is perhaps a missed oportunity >> to implement something like a "clone" word that will allow an amforth >> installation to clone itself (via ICSP) to an identical but empty >> atmel >> device. > > Yes, a clone word should be there in amforth. I'll think about it. > > Michael > > ------------------------------------------------------------------------------ > > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: <an...@ki...> - 2010-05-19 13:01:35
|
Hurro Mathias & guys > I know that amforth is difficult to use for an absolute beginner. For > both langauge and hardware reasons. I myself had to spend a lot of > time until my first microcontroller program did run (no, it was not > amforth but a simple "hello world" that flashed a LED). The only > way around I see is that those people get a pre-programmed > chip / complete system. The arduino has it's success mainly > because of those pre-programmed hardware ready to use. > > Thinking that approach further: the amforth core system can > reside within 8KB flash, selecting an atmega with that boot sector > size would allow an "undestroyable" amforth system. No user > could overwrite the forth system at will or by mistake. Well, there > are still a few things more to do, but that would work. There is certainly some mileage in this. I could see it working and giving new users a quick in. The undestroyable idea has its merits. I am thinking back a little here to an English company that produced Forth based microcontrolers TDS2020 back before flash was really available. Tiny EEPROM's or battery backed sram were as good as it got. The company was called TDS I think. Their system used Eproms and battery backed sram. So was along those lines. (I still have the manuals, but seem to have lost the boards etc.) On getting forth onto virgin chips. There is perhaps a missed oportunity to implement something like a "clone" word that will allow an amforth installation to clone itself (via ICSP) to an identical but empty atmel device. If an arduino can be used as an stk500 programmer purely from code to program a blank atmel microcontroler with a bootloader the clone should be as easily doable. Perhaps easier as it would only clone to an identical device. Sure it is limited to only cloning to identical devices but it would give folk teaching classes a way to do forth only and bypass the fuss of the toolchain. Students could breadboard up an empty forth system and clone the core from the tutors example system or from each others. The students could then take away their devices, as a ready to go device they could use at home on their own breadboard, pcb or breadboard. cheers Andy Kirby |
|
From: Mike B. <mi...@mj...> - 2010-03-05 15:58:59
|
On Thu, 4 Mar 2010 13:55:36 -0800, Tom Arnold <xy...@sy...> wrote: > On Thu, Mar 04, 2010 at 09:22:22PM +0000, Andy Kirby wrote: > > What would be really cool would be if you could take an off the shelf > > Arduino Mega, burn amforth onto it and then use this Forthduino to clone > > itself to other off the shelf Arduino Mega's > > > > I guess a new design of Atmel based micro board that was purely amforth > > would be cool too. > > Making amforth work with the Arduino bootloader I think would open up > amforth to a lot more people who may not otherwise want to undertake trying > to play with it. Forth has a somewhat bad ( un-deserved ) reputation as being > difficult to deal with as it is. Having it incompatible with widely > available cheap hardware just adds to that. The Arduino bootloader is > nothing magical. Its just a simple software implementation of the STK500 > protocol. > > Going with Arduino vs a dedicated amforth board opens up amforth to the > world of arduino "shields" ( I hate that name ) which widens up the hardware > available to quickly throw at a project. > > I know there are reasons why its not supported, like Arduino didn't exist > with amforth first came about, I'm only saying it'd be nice. I wish I had > the skillset to make it happen. It is worth pointing out that a USB based > Atmel programmer is dirt cheap these days ( $20 or so from AdaFruit I think > ). That makes it fairly easy to turn an Arduino Mega into an AmforthMega. > Easy but not trivial. Supporting the loader would make it trivial... I'm working with a breadboarding tile for an ATMega88 in the 32MLF package, including crystal, decoupling, reset, and 6-pin SPI connector - not very different from some of the simpler Arduinos. I've glued it to the top of an IDC connector to plug into the board that it is to control. An off-the-shelf version of this which included an RS232 interface and pre-loaded with amforth would have been irresistible. (ok, make it the 16k or 32k flash version!) In comparison, I'm wondering how popular the various "BASIC Stamp" - type of boards might be, as a guide to the prospects for a Forth-based board. Forth is, after all, so much more amenable than BASIC (at least I think so - but then, I've been a Forth convert since the 70s.) Mike Beach |
|
From: Matthias T. <mt...@we...> - 2010-06-29 18:15:44
|
Hi Andy, > Logicaly then I thought the easiest way to do cloning should be to use > the ISP peripheral to handle the serialization and low level protocols > rather then bit banging a port. But use a port to drive the target > devices reset line (like the debug LED port.) I'm afraid that you cannot avoid doing the bit-banging youself. The following projects that may serve as an inspiration for you (atmega programs another atmega): http://www.fourwalledcubicle.com/ButtLoad.php http://www.arduino.cc/playground/Code/Programmer2 wrt to the schematics, sourceforge seem to drop your attachment, I could place it on the web space and post a link to it. I'm still not sure whether I should collect hardware descriptions like yours for amforth. My current understanding is that amforth is pure software on a very hardware centric level and I'm not a hardware guy at all. ok, I find the hot end of a soldering iron, by pain ;=) HTH Matthias |
|
From: Matthias T. <mt...@we...> - 2010-03-04 08:28:48
|
Mike, Mike Beach wrote: > Many thanks, Erich and Andy, for your swift responses. > > Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe > someone will add a few words to the AMForth documentation.) > I just edited the FAQ a little, maybe you can comment on it? http://amforth.sourceforge.net/faq.html (top2) Matthias |
|
From: Andy K. <an...@ak...> - 2010-03-04 22:20:41
|
Pretty much there. A suggestion... for "(same: rarly used). Any other programmer type may need support from the microcontroller (a so called bootloader) but cannot program amforth (the reasons are explained in the technical handbook). " try "(same: rarely used). Programming that relies on a boot loader on the micro-controller itself can not load amforth (the reasons are explained in the technical handbook)." I think this means the same but the english is a little clearer. Last tip, the mention of JTAG may be misleading, many of the Atmega micro's do not have JTAG capability. I think you may have meant that the Atmel JTAG programmer could be used in it's ICSP mode. If I have got it wrong I apologies in advance. Is it worth considering putting in some hyperlinks to a couple of sites. (ie Atmel,s programming tools and maybe the pony prog pages) Hope this helps. Cheers Andy Kirby Matthias Trute wrote: > Mike, > > Mike Beach wrote: >> Many thanks, Erich and Andy, for your swift responses. >> >> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe >> someone will add a few words to the AMForth documentation.) >> > > I just edited the FAQ a little, maybe you can comment on it? > > http://amforth.sourceforge.net/faq.html (top2) > > Matthias > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Andy K. <an...@ak...> - 2010-03-04 22:37:44
|
Just thought of something else, it may be worth adding an example invocation line for avrdude to the pages too. Maybe for N12 Pony & AVRISP. Andy Kirby wrote: > Pretty much there. > > A suggestion... > > for > > "(same: rarly used). Any other programmer type may need support from the > microcontroller (a so called bootloader) but cannot program amforth (the > reasons are explained in the technical handbook). " > > try > > "(same: rarely used). Programming that relies on a boot loader on the > micro-controller itself can not load amforth (the reasons are explained > in the technical handbook)." > > I think this means the same but the english is a little clearer. > > Last tip, the mention of JTAG may be misleading, many of the Atmega > micro's do not have JTAG capability. I think you may have meant that the > Atmel JTAG programmer could be used in it's ICSP mode. > > If I have got it wrong I apologies in advance. > > Is it worth considering putting in some hyperlinks to a couple of sites. > (ie Atmel,s programming tools and maybe the pony prog pages) > > Hope this helps. > > Cheers > > Andy Kirby > > > Matthias Trute wrote: >> Mike, >> >> Mike Beach wrote: >>> Many thanks, Erich and Andy, for your swift responses. >>> >>> Very reassuring - makes much more sense. (Can I be the only one with this query? Maybe >>> someone will add a few words to the AMForth documentation.) >>> >> I just edited the FAQ a little, maybe you can comment on it? >> >> http://amforth.sourceforge.net/faq.html (top2) >> >> Matthias >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Amforth-devel mailing list >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Matthias T. <mt...@we...> - 2010-03-05 19:23:41
|
Andy, Andy Kirby wrote: > Pretty much there. > > A suggestion... > Highly appreciated. Thank you. > Last tip, the mention of JTAG may be misleading, many of the Atmega > micro's do not have JTAG capability. But all, on that amforth can run. At least I'm almost sure ;=) > I think you may have meant that the > Atmel JTAG programmer could be used in it's ICSP mode. > Well, the method the hex files are transferred to the controller is completly unrelated to amforth itself. There are no dependencies.. With the one exception, that a bootloader cannot be used at all (with the potential exception from the exception if amforth is adapted to use some API call from the bootloader to perform the flash self programming). > Is it worth considering putting in some hyperlinks to a couple of sites. > (ie Atmel,s programming tools and maybe the pony prog pages) > I think that everybody who works with the Atmel controllers will soon know the tools and how they work. There are so many websites around, that I do not want to publish the same information again; this time my way. Same argument why I omit schematics and such information. I'll collect some links to such websites and put them on the links page. Is that ok? Matthias |
|
From: Andy K. <an...@ak...> - 2010-03-07 13:04:41
|
That would be fine. I understand your not wanting to duplicate what is already out there. Matthias Trute wrote: > Andy, > > Andy Kirby wrote: >> Pretty much there. >> >> A suggestion... >> > > Highly appreciated. Thank you. >> Last tip, the mention of JTAG may be misleading, many of the Atmega >> micro's do not have JTAG capability. > > But all, on that amforth can run. At least I'm almost sure ;=) > >> I think you may have meant that the >> Atmel JTAG programmer could be used in it's ICSP mode. >> > > Well, the method the hex files are transferred to the > controller is completly unrelated to amforth itself. There > are no dependencies.. With the one exception, that a > bootloader cannot be used at all (with the potential exception > from the exception if amforth is adapted to use some API > call from the bootloader to perform the flash self > programming). > >> Is it worth considering putting in some hyperlinks to a couple of sites. >> (ie Atmel,s programming tools and maybe the pony prog pages) >> > > I think that everybody who works with the Atmel controllers > will soon know the tools and how they work. There are so > many websites around, that I do not want to publish the same > information again; this time my way. Same argument why > I omit schematics and such information. > > I'll collect some links to such websites and put them on > the links page. Is that ok? > > Matthias > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
×
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