Re: [Amforth] defer.frt

[Mark R. <cab...@gm...>]

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 <cab...@gm...> 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 <ho...@tj...> 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/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>