From: Mike B. <mi...@mj...> - 2010-03-15 20:28:08
|
Because amforth is available specifically for the AVR Butterfly ("Bf"), and that device includes some of the "peripherals" that I will need, I have elected to use it as the base for a current project rather than a simple breadboarding tile. The amforth files for Bf create a hex file on AVRStudio without error or warning, and a STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as indicated at one point in the amforth documentation). Then when connected to a terminal, data can be seen going into the Bf, but nothing is ever returned to the terminal, nor is there any suggestion of a sign-on message being generated at reset. The same equipment is able to restore the original flash content, and the same terminal program is then is able to send a "name" string to the Bf, so all other hardware and software appears to be intact. The Bf reset line does go high when released. Can anyone offer suggestions? What have I missed? There was mention of a ready-to-run hex file for this device, but I haven't found it. Mike Beach |
From: Matthias T. <mt...@we...> - 2010-03-15 20:59:23
|
Hi Mike, > The amforth files for Bf create a hex file on AVRStudio without error or warning, and a > STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as > indicated at one point in the amforth documentation). Exactly that is the problem: You definitly need the EEPROM hex file, without it amforth cannot work at all. Strange that the avrstudio does not generate one.. You may find hex files in earlier versions, I sometimes miss to generate one for a release. mea culpa. Please do not mix the versions however... Matthias |
From: Mike B. <mi...@mj...> - 2010-03-15 21:46:45
|
Thanks, Matthias! Very glad there's a solid reason for the failure. Probably simplest then if I look for an earlier version that includes both hex files ready-built. Mike Date sent: Mon, 15 Mar 2010 21:59:15 +0100 From: Matthias Trute <mt...@we...> To: Everything around amforth <amf...@li...> Subject: Re: [Amforth-devel] Butterfly problems [ Double-click this line for list subscription options ] Hi Mike, > The amforth files for Bf create a hex file on AVRStudio without error > or warning, and a STK500 claims to successfully copy it to flash via > ISP (just the one file, no EEPROM file as indicated at one point in the > amforth documentation). Exactly that is the problem: You definitly need the EEPROM hex file, without it amforth cannot work at all. Strange that the avrstudio does not generate one.. You may find hex files in earlier versions, I sometimes miss to generate one for a release. mea culpa. Please do not mix the versions however... Matthias |
From: Mike B. <mi...@mj...> - 2010-03-15 22:27:42
|
Aha! Found it! The assembler generates a file with an .eep extension which is actually a hex file. That will no doubt be the missing ingredient. The automatically-generated batch file AvrBuild.bat begins to make slightly more sense. Once I get through this, I'll be tempted to write something for the benefit of others as ignorant as myself! Mike Hi Mike, > The amforth files for Bf create a hex file on AVRStudio without error or warning, and a > STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as > indicated at one point in the amforth documentation). Exactly that is the problem: You definitly need the EEPROM hex file, without it amforth cannot work at all. Strange that the avrstudio does not generate one.. You may find hex files in earlier versions, I sometimes miss to generate one for a release. mea culpa. Please do not mix the versions however... 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: Ian J. <ij...@sa...> - 2010-03-16 01:05:40
|
Hi Mike, You might look at my earlier posts on the butterfly. Possibly the changes I had to make have been integrated into the source tree now. I'm pretty much the begginer though and the work I was doing was all under FreeBSD without AVRstudio. I don't think I was ever able to get the LCD working correctly and I've lost momentum. I'd be interested in your progress. Let us know how it goes and especially if the LCD and AD words are working for you. Ian On Mon, 15 Mar 2010, Mike Beach wrote: > Because amforth is available specifically for the AVR Butterfly ("Bf"), and that device > includes some of the "peripherals" that I will need, I have elected to use it as the base for a > current project rather than a simple breadboarding tile. > > The amforth files for Bf create a hex file on AVRStudio without error or warning, and a > STK500 claims to successfully copy it to flash via ISP (just the one file, no EEPROM file as > indicated at one point in the amforth documentation). Then when connected to a terminal, > data can be seen going into the Bf, but nothing is ever returned to the terminal, nor is there > any suggestion of a sign-on message being generated at reset. > > The same equipment is able to restore the original flash content, and the same terminal > program is then is able to send a "name" string to the Bf, so all other hardware and software > appears to be intact. The Bf reset line does go high when released. > > Can anyone offer suggestions? What have I missed? There was mention of a ready-to-run > hex file for this device, but I haven't found it. > > Mike Beach > > ------------------------------------------------------------------------------ > 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-16 15:31:33
|
The .eep file was indeed the solution - yesterday. Thanks to Matthias for pointing that out. While happily starting to explore amforth, I must have done something to upset the Butterfly. I'm now thinking that's an apt description for its ruggedness! After erasing flash using PARALLEL programming, most bytes read back as DF; fewer when run at 5V, and all correct at 5.5V. But even there, it could not be programmed. Always the same error: some bytes were $20 less than required, so somewhere in the chip bit5 is being held low. Also, the battery has been dragged to below 3.0V. ESD? Finger trouble? Can't be too careful around this thing. I'll await a new Butterfly (or just the chip if I can find one) while on holiday for the next three weeks. Thanks for your notes, Ian. I'll have a look at your posts, and take the LCD and ADC as a bit of a challenge. For this project though, I'm expecting to use a separate 20x4 LCD, and external ADCs via a cable. Mike Hi Mike, You might look at my earlier posts on the butterfly. Possibly the changes I had to make have been integrated into the source tree now. I'm pretty much the begginer though and the work I was doing was all under FreeBSD without AVRstudio. I don't think I was ever able to get the LCD working correctly and I've lost momentum. I'd be interested in your progress. Let us know how it goes and especially if the LCD and AD words are working for you. Ian |
From: Kalus M. <mic...@on...> - 2010-03-16 19:04:23
|
Hi MIke. Am 16.03.2010 um 16:31 schrieb Mike Beach: > .. I'll have a look at your posts, and take the LCD and ADC as a bit > of a challenge. For this project though, I'm expecting to use a > separate 20x4 LCD, and > external ADCs via a cable. May be you want to take a look at lcd.frt and lcd.asm. That worked fine in earlier versions of amforth and did well in amforth-3.9 recently. You may chose to include lcd.asm while assembling, or use lcd.frt later to download forth code to a running amforth system on the butterfly. I created this while using the polling i/o method for the USART, so the anforth system tolerated the redirection of the EMIT vector (see: source code lines 89,90) to send strings to the LCD: : <lcd> ( -- ) lcdcr ['] lcdemit is emit ; : </lcd> ( -- ) tob wlcd ['] tx0 is emit ; But using the (default) interupt driven i/o method for EMIT, amforth will crash as son as you try to execute <lcd>. So you can not use ldc. or lcd" from the shelf if you use the interupt i/o. May be you find a way to work around this and improve the code to fit both ways to handle the terminal i/o. Michael |
From: Ian J. <ij...@sa...> - 2010-03-16 22:13:33
|
Mike you might find the butterfly carrier from Ecros handy if you don't have one. http://www.ecrostech.com/ On Tue, 16 Mar 2010, Mike Beach wrote: > The .eep file was indeed the solution - yesterday. Thanks to Matthias for pointing that out. > > While happily starting to explore amforth, I must have done something to upset the > Butterfly. I'm now thinking that's an apt description for its ruggedness! After erasing flash > using PARALLEL programming, most bytes read back as DF; fewer when run at 5V, and all > correct at 5.5V. But even there, it could not be programmed. Always the same error: some > bytes were $20 less than required, so somewhere in the chip bit5 is being held low. Also, the > battery has been dragged to below 3.0V. ESD? Finger trouble? Can't be too careful around > this thing. I'll await a new Butterfly (or just the chip if I can find one) while on holiday for the > next three weeks. > > Thanks for your notes, Ian. I'll have a look at your posts, and take the LCD and ADC as a bit > of a challenge. For this project though, I'm expecting to use a separate 20x4 LCD, and > external ADCs via a cable. > > Mike > |