Okay, maybe I figured out why the i2c-eeprom-blocks.frt wasn't working right for me.
I re-flashed my 1284 to get a fresh start, then started working on the simpler i2c-eeprom.frt from the python console. It would sort of work then get stuck. So I ended up just making a list of inclusions and working backward manually, only adding a local version when the #include directive couldn't find the file because it didn't seem to be in the search path. No problem. It was even nice enough to tell me when I had too many versions of the file. It is possible I'm not using the tool properly I suppose. In any case, it seems that I (should) now have a way to play around with an I2C bus. Onward (until next time...) Mark On Sat, Jun 27, 2020 at 1:32 AM Mark Roth <cablegu...@gmail.com> wrote: > Thank you Tristan for the welcome and all of it. > > Yeah, I had done that. I guess pointing out that was missing was just an > easy way to start. What I had actually done was to move everything into my > app directory to try and get things to import. The changes you mention do > work. Where I am getting stuck is in the flash-block.frt file at line 33. > After making some changes (well adding #requires) I'm also seeing it in > i2c-eeprom-block.frt at line 76 which is the same issue. > > S| 76| ['] i2c.ee.load-buffer is load-buffer > > which is about the same type of line in flash-block. That makes me think > it is something that is not included yet. > > It's late here. Tomorrow is another day. Thanks again for the welcome. > Really :) > > On Sat, Jun 27, 2020 at 12:41 AM Tristan Williams <h...@tjnw.co.uk> wrote: > >> Hello Mark, >> >> Welcome to the list. >> >> > Should I be concentrating more on following along with the I2C EEPROM >> > recipe in the cookbook instead? >> >> It depends upon what you want to achieve - but perhaps. At the end of >> cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus >> and be able to write/read a byte/word to/from an address on the >> eeprom. If you put multiple eeproms on the bus make sure they have >> different I2C addresses. i2c.detect is very useful as an interactive >> check to see if things are as you expect. >> >> > The problem is that it seems there is no defer.frt anymore >> >> You are correct. >> >> i2c-eeprom-block.frt requires blocks.frt which >> in turn requires defer.frt - which does not exist. >> >> I think the word Rdefer used in blocks.frt is now in this file >> >> amforth-6.8/common/lib/forth2012/core-ext/defers.frt >> >> I have not tested this, but changing >> >> #require defer.frt >> >> to >> >> #require defers.frt >> >> in >> >> amforth-6.8/common/lib/forth2012/blocks/blocks.frt >> >> may help. >> >> Best wishes, >> Tristan >> >> [1] >> http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom >> >> On 26Jun20 22:04, Mark Roth wrote: >> > Hello, >> > I have been working (and reading extensively) with AmForth this past >> week >> > or so as I learn Forth from Starting Forth. I wanted to try to play with >> > some eeproms on an I2C bus and from reading here I drifted toward the >> > i2c-eeprom-block.frt >> > post. The problem is that it seems there is no defer.frt anymore? >> Should I >> > be concentrating more on following along with the I2C EEPROM recipe in >> the >> > cookbook instead? I tried to upload the requirements with the >> > amforth-shell.py script and that gave me the error message of: >> > E=file defer.frt not found in search path >> > I am running 6.8 on an atmega1284p if that makes a difference. >> > >> > It was a little tricky getting started since I was following the linux >> > instructions, but once I read through the windows stuff (and just the >> docs >> > in general) I was able to get my chip set up correctly. It really is a >> > pretty cool system that reminds me of my old computers back in the olden >> > days. :) >> > >> > Mostly I've been using the e4thcom console, but I couldn't manage to >> get it >> > to search for the sources correctly. The python script seems to work a >> > treat for that. >> > >> > Also, I'm sorry I just missed out on the creator of all this. It's >> always >> > nice to see a project live on though. That's really why they are open >> imho. >> > >> > All the best, >> > Mark >> > >> > _______________________________________________ >> > Amforth-devel mailing list for http://amforth.sf.net/ >> > Amforth-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amforth-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
