Thread: [Flashforth-devel] Problem with I2C on ATMEGA328P
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Mark W. <mar...@gm...> - 2017-05-10 17:05:37
|
Hello, The routine i2c.wait in i2c-base-avr.txt hangs the machine. : i2c.wait ( -- ) \ Wait for operation to complete \ When TWI operations are done, the hardware sets \ the TWINT interrupt flag, which we will poll. begin TWCR c@ mTWINT and until ; I'm trying to use the i2c.detect program in the FlashForth guide (PDF) to detect my i2c devices. I can see them just fine if I use a C++ program so I know the hardware is wired correctly. Regards Mark Wills |
|
From: Mikael N. <mik...@fl...> - 2017-05-10 20:20:04
|
Hello Mark,
You need to register to use the mailing list.
Anyway, on my Arduino Uno the i2c.detect works just fine with an empty
I2C bus when there are external pullups on SDA and SCL. Use i2c.init
first.
I don't have any real i2c devices handy right now.
I wonder, is there any way to use the internal port C pullups for I2C.
Although I suspect the internal pull-ups would be too weak to be of any
use.
BTW, are you using the latest FF hex images and doloop.txt from
11.4.2017 ?
doloop was broken for a while before that.
ok<$,ram>
i2c.init i2c.detect
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
00 : -- -- -- -- -- -- -- -- --
10 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70 : -- -- -- -- -- -- -- --
ok<$,ram>
BR Mikael
On 2017-05-10 20:05, Mark Wills wrote:
> Hello,
>
> The routine i2c.wait in i2c-base-avr.txt hangs the machine.
>
> : i2c.wait ( -- ) \ Wait for operation to complete
> \ When TWI operations are done, the hardware sets
> \ the TWINT interrupt flag, which we will poll.
> begin TWCR c@ mTWINT and until
> ;
>
> I'm trying to use the i2c.detect program in the FlashForth guide (PDF)
> to detect my i2c devices. I can see them just fine if I use a C++
> program so I know the hardware is wired correctly.
>
> Regards
>
> Mark Wills
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
--
--
Mikael
|
|
From: Mikael N. <mik...@fl...> - 2017-05-12 05:02:31
|
I did some tests with ds1307 and did not have any problems. Pushed i2c-base-avr that has a watchdog in the i2c.wait. Added some ds1307 words. Added i2c.stop to the end of i2c.detect. The 220317 version is just fine. BR Mikael On 2017-05-11 11:26, Mark Wills wrote: > HI Mikael, > > Aha! I fixed the mailing list issue! There was a confirmation email > from the server but I missed it as gmail put it in the "promotions" > group! > > The version of FF that I am currently using is 220317, which I guess > is fairly up to date? Is there a compelling reason to upgrade to the > latest version of FF? > > There is a VERY interesting article on the Arduino I2C library which > might be worth a read. I've just started looking at it. > > See http://playground.arduino.cc/Main/WireLibraryDetailedReference > > Regards > > Mark > > On Thu, May 11, 2017 at 5:16 AM, Mikael Nordman > <mik...@fl...> wrote: > >> Hi Mark >> I cannot see you as member on the list. >> Also I did not get any join mails about you. >> Really strange ??? >> >> To implement block or file input some changes to FF core may be >> needed. >> >> REFILL must be implemented. >> >> Now WORD just writes the length byte into the TIB (SOURCE). >> So parsing the block buffer directly would modify it. >> >> WORD could be changed to copy the parsed word into a buffer. >> Or REFILL could copy the file/block line into TIB and then use TIB >> as SOURCE. >> >> Someone else was also complaining that the i2c.ping? hangs some >> times. >> >> The I2C code was provided by Peter Jacobs. >> I need to connect some I2C device to my 328 and check it out. >> >> The FF version has to be 11.11.2016 or later to work with the >> 11.4.2017 doloop. >> >> So for 5 months doloop was broken :-( >> >> BR Mikael >> >> On 2017-05-11 02:12, Mark Wills wrote: >> >> Hello, Mikael thanks for the reply; nice to hear from you. >> >> I've filled in the form on the Sourceforge webpage to join the >> mailing >> list, so you should have a notification email somewhere. I actually >> did this a couple of months ago and never heard anything back, so I >> registered again today. >> >> I don't think it's the pull-ups on the I2C bus, as there is only one >> device (at the moment) on the bus, and I can find the device >> (PCF8574) >> every time when running Arduino code to search the I2C bus. When I >> change out the 328P for a FlashForth programmed 328P it won't work. >> >> I'm using the new do...loop code, yes, however, I'm using an older >> hex >> file of FlashForth - i.e. NOT the latest release. I can update the >> 328P but I'll have to build a programmer on some bread-board again! >> >> I'm designing a controller board based on the ATMega328P, with the >> following features: >> >> * Real RS232 interface >> * LCD Interface (I2C) >> * 8 Digital inputs (I2C) >> * 8 Digital outputs (I2C) >> * 6 Analog inputs (on board 328P) >> * 6 PWM outputs (on board 328P) >> * 16 key keypad interface (I2C) >> * On board SD Card reader/writer (SPI) >> * 32KB FRAM (I2C) (larger sizes available, up to 256KB, but they're >> expensive) >> * Real time temperature compensated clock with battery backup >> >> * A number of software assignable digital inputs (dip switches on >> the >> board) (on board 328P) >> * External I2C interface >> * Standard 2U board dimensions for rack mounting. >> * Paul Bennett is designing a range of expansion cards (I2C) with >> fully isolated industrial grade I/O >> >> Most of the design schematic capture work and >> bread-boarding/prototyping is done. I'll shortly be moving on to the >> board layout. >> >> Currently, my intention is to run FlashForth on the board. That will >> depend on getting the I2C working (I'll try a software upgrade) and >> I'll probably have to write some additional software in FlashForth >> to >> give easy access to the peripherals. The biggest issue will be the >> SD >> Card. Do I implement a FAT file system or not? I've never coded one >> before, and I'm not looking forward to it! It also adds quite a lot >> of >> overhead with words required to manage directories etc. >> >> The other alternative would be to use the SD in a raw format, say, >> in >> 1K blocks. I prefer this idea, and adding a BLOCK subsystem should >> be >> possible in high level FlashForth code. I presume there is a hook >> somewhere in the interpreter where I can feed input to the >> interpreter >> from a BLOCK rather than from the serial port? >> >> Still a lot of work to do! >> >> Regards >> >> Mark >> >> On Wed, May 10, 2017 at 9:19 PM, Mikael Nordman >> <mik...@fl...> wrote: >> >> Hello Mark, >> You need to register to use the mailing list. >> >> Anyway, on my Arduino Uno the i2c.detect works just fine with an >> empty I2C bus when there are external pullups on SDA and SCL. Use >> i2c.init first. >> >> I don't have any real i2c devices handy right now. >> >> I wonder, is there any way to use the internal port C pullups for >> I2C. >> Although I suspect the internal pull-ups would be too weak to be of >> any use. >> >> BTW, are you using the latest FF hex images and doloop.txt from >> 11.4.2017 ? >> doloop was broken for a while before that. >> >> ok<$,ram> >> i2c.init i2c.detect >> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f >> 00 : -- -- -- -- -- -- -- -- -- >> 10 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 20 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 30 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 40 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 50 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 60 : -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> 70 : -- -- -- -- -- -- -- -- >> ok<$,ram> >> >> BR Mikael >> >> On 2017-05-10 20:05, Mark Wills wrote: >> >> Hello, >> >> The routine i2c.wait in i2c-base-avr.txt hangs the machine. >> >> : i2c.wait ( -- ) \ Wait for operation to complete >> \ When TWI operations are done, the hardware sets >> \ the TWINT interrupt flag, which we will poll. >> begin TWCR c@ mTWINT and until >> ; >> >> I'm trying to use the i2c.detect program in the FlashForth guide >> (PDF) >> to detect my i2c devices. I can see them just fine if I use a C++ >> program so I know the hardware is wired correctly. >> >> Regards >> >> Mark Wills > > ------------------------------------------------------------------------------ > >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Flashforth-devel mailing list >>> Fla...@li... >>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel [1] >>> [1] >> >> -- >> -- >> Mikael > > Links: > ------ > [1] https://lists.sourceforge.net/lists/listinfo/flashforth-devel [1] > > -- > -- > Mikael > > > > Links: > ------ > [1] https://lists.sourceforge.net/lists/listinfo/flashforth-devel -- -- Mikael |
×
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