TheBackShed.com

Forum Index : Microcontroller and PC projects : Maximite test ver 2.4A - with I2C

Author

Message

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 04:22am 23 Jul 2011

Copy link to clipboard

Print this post

I have another test version of the Maximite firmware for adventurous people to try out.

You can download it from: http://geoffg.net/Downloads/Maximite/Maximite_Update_V2.4B.z ip

It is the same as 2.4A but includes the latest version of the I2C routines by Gerard Sexton (he also released these in the previous post). These fully support master and slave operation, 10 bit addressing, address masking and general call, as well as bus arbitration (ie, bus collisions in a multi master environment).

The only other changes are:
- The addition of the COPYRIGHT command to list the contributors to the firmware and specify the copyright (GNU GPL V3).
- Allowed the function PIN() to return the digital value of an i/o pin that is configured for open collector output. This is useful when the pin is shared with other devices that might also pull the voltage on the pin low.

Please give it a test and report the outcome (good or bad). If no faults have been discovered in the next few days I will make it into a general release (ver 2.5).

Thanks,
Geoff

Geoff Graham - http://geoffg.net

Gizmo

Admin Group

Joined: 05/06/2004
Location: Australia
Posts: 5078

Posted: 05:14am 23 Jul 2011

Copy link to clipboard

Print this post

You know I just so happened to buy a spare 08M PicAxe chip this morning with the intentions of using it to test the I2C future updates for the Maximite.

This is exciting stuff.

Glenn

The best time to plant a tree was twenty years ago, the second best time is right now.
JAQ

ajkw
Senior Member

Joined: 29/06/2011
Location: Australia
Posts: 290

Posted: 09:39am 23 Jul 2011

Copy link to clipboard

Print this post

Geoff,

I have had a play with reading a pin set as a open collector but the Maximite is giving an error when trying to read the pin "...Input mode not implemented"

Pin 19 has a pull up resistor on it. I was expecting a read of 0 with this example.

Should this be done another way?

Please see the screen shot below.

Regards,
Anthony.

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 10:05am 23 Jul 2011

Copy link to clipboard

Print this post

ajkw said Should this be done another way?

No, that should work. Sounds like a bug... and I thought that I had properly tested that!

Thanks
Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 10:57am 23 Jul 2011

Copy link to clipboard

Print this post

OK, a new test version (2.4C) which fixes the bug reported by Anthony.

It can be downloaded from: http://geoffg.net/Downloads/Maximite/Maximite_Update_V2.4C.z ip

Thanks Anthony,
Geoff

Geoff Graham - http://geoffg.net

trippyben

Regular Member

Joined: 26/06/2011
Location: Australia
Posts: 91

Posted: 11:11am 23 Jul 2011

Copy link to clipboard

Print this post

I've been playing with 2.4b and an M41T815M6E ST RTC I2C device - connected to 3.3V powered from the maximite and using 2.3k pullups. Occasionally the I2C interface locks up and prevents further access to the I2C device. Restarting the program does not release the bus, it requires a cold re-boot of the maximite to get it going again. Once locked up the I2C commands return a time out error.

Here's the code:

1 CLS
5 TIME$="00:00"
10 LINE(0,0)-(479,431),1,B
19 I2CDIS
20 LINE (0,230)-(479,230),1
21 finish_time$ = "0"
22 I2CEN 400,500
23 I2CSEND &h68,0,15,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
24 DIM RTC_TIME(4)
30 LOCATE 10,240
40 PRINT "Finish Times"
50 SETPIN 1,6,1000
51 SETPIN 20,8
52 SETPIN 19,8
53 SETPIN 18,8
60 PIN(20) = 0
61 PIN(19) = 0
62 PIN(18) = 0
100 LOCATE 10,12
110 PRINT TIME$
120 LOCATE 10,252
130 PRINT finish_time$
140 PRINT HEX$(rtc_time(3));":";HEX$(rtc_time(2));":";
141 PRINT HEX$(rtc_time(1));":";HEX$(rtc_time(0));" "
142 PRINT MM.I2C
200 GOTO 100
1000 finish_time$ = TIME$
1010 I2CRCV &h68,0,4,rtc_time(0),1,0
1100 IRETURN

I've poked around with my Saleae logic analyser (nice bit of kit by the way) and found that occasionally the I2C bus transfer does not end with a STOP command. See screenshots in attached pdf. The entire block of data seems to transfer OK, and ends with the expected NACK, but the STOP never happens. Interestingly with the saleae connected I've not yet had a full lock up - after the failed transfer things seem to self recover. Maybe that's just murphy playing the old technicians syndrome card.

Any idea's what's happening?

2011-07-23_210612_Salese_logic_analyser_screenshots.pdf

sparkey

Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 819

Posted: 11:19am 23 Jul 2011

Copy link to clipboard

Print this post

thanks geoff i know people have been at your head with this one also would like to comment :would it be possible to get the firm ware loaded from the sd-card after down loading it from a pc using a sd-card reader and running the firm throug the sd-card ...

technicians do it with least resistance

ajkw
Senior Member

Joined: 29/06/2011
Location: Australia
Posts: 290

Posted: 11:28am 23 Jul 2011

Copy link to clipboard

Print this post

Geoff,

Yes all fixed in 2.4C. Thanks.

Anthony.

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 12:18pm 23 Jul 2011

Copy link to clipboard

Print this post

sparkey said thanks geoff i know people have been at your head with this one also would like to comment :would it be possible to get the firm ware loaded from the sd-card after down loading it from a pc using a sd-card reader and running the firm throug the sd-card ...

I tried to implement loading from the SD card in the early days but it turned out easier to do it over USB. With more experience it now might be easier so I will have a look at it again (no promises though).

Geoff

Geoff Graham - http://geoffg.net

sparkey

Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 819

Posted: 12:47pm 23 Jul 2011

Copy link to clipboard

Print this post

thanks geoff i have three maxis one running 2.4 /one/2.4a and now 2.4c on the third did not bother with 2.4 b / have 2.4c running on an orig altronics atm seems ok but have not got complex programs to run...many thanks regards sparkey...

: now will some body sell me some hard whare regards sparkey ...i`v been at these guys to sell harwhare but they were reluctant to provide i look into futre devolmplemt always ....Edited by sparkey 2011-07-24

technicians do it with least resistance

sparkey

Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 819

Posted: 01:17pm 23 Jul 2011

Copy link to clipboard

Print this post

i just ran the program by "tryppyben and i am not getting any finish time`s at all //...regards sparkey ..oh on 2 point 4 c...ok...i just ran a ctrl-c then ran run..only displays a "2"on the bottom set of zeros //run time at present 12.20 mins...Edited by sparkey 2011-07-24

technicians do it with least resistance

seco61
Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 205

Posted: 03:59pm 23 Jul 2011

Copy link to clipboard

Print this post

trippyben said I've been playing with 2.4b and an M41T815M6E ST RTC I2C device - connected to 3.3V powered from the maximite and using 2.3k pullups. Occasionally the I2C interface locks up and prevents further access to the I2C device. Restarting the program does not release the bus, it requires a cold re-boot of the maximite to get it going again. Once locked up the I2C commands return a time out error.
I've poked around with my Saleae logic analyser (nice bit of kit by the way) and found that occasionally the I2C bus transfer does not end with a STOP command. See screenshots in attached pdf. The entire block of data seems to transfer OK, and ends with the expected NACK, but the STOP never happens. Interestingly with the saleae connected I've not yet had a full lock up - after the failed transfer things seem to self recover. Maybe that's just murphy playing the old technicians syndrome card.

Any idea's what's happening?

Hi Ben.

I agree, the Saleae logic analyser is a great piece of kit!

Could you post a link to the datasheet for the RTC device - I can not find it.

Also, what length and type of cable are you using for the connection to the RTC device? When running at 400kHz, I have always found the I2C bus to be very fussy with regards to the cable. Ideally it should be as short as possible, and if using flat cable the ground should run between the data and clock lines to reduce crosstalk.

Do the errors occur if the bus speed is 100kHz?

Looking at the screen shots, one of the devices is holding the clock line low. This normally is done by the slave device. But I have seen instances where crosstalk on the data/clock lines has caused the I2C peripheral to get its knickers in a knot.

Regards

GerardEdited by seco61 2011-07-25

Regards

Gerard (vk3cg/vk3grs)

trippyben

Regular Member

Joined: 26/06/2011
Location: Australia
Posts: 91

Posted: 10:50pm 23 Jul 2011

Copy link to clipboard

Print this post

The total length od conductor is about 300mm, ribbon cable and vero board - parallel tracks all the way. Due to Maxi's connector, the SDA and SCL are next to each other and next to ground on one side only.

Will give 100kHz a spin, there's no other devices on the bus at this stage. Might have a look with the CRO to see just how square those bits really are!

Datasheet attached.2011-07-24_085009_M41T815M6E_ST_RTC.pdf

Ben

trippyben

Regular Member

Joined: 26/06/2011
Location: Australia
Posts: 91

Posted: 10:57pm 23 Jul 2011

Copy link to clipboard

Print this post

Ahhh, the visibility of a DSO (and early morning though processes!) at 400kHz the clock pulses were more like a shark fin than a square wave. Dropping to 200kHz gives more time for each pulse to flatten out at the top. Seems ok thus far. Will keep playing.

trippyben

Regular Member

Joined: 26/06/2011
Location: Australia
Posts: 91

Posted: 11:00pm 23 Jul 2011

Copy link to clipboard

Print this post

sparkey said i just ran the program by "tryppyben and i am not getting any finish time`s at all //...regards sparkey ..oh on 2 point 4 c...ok...i just ran a ctrl-c then ran run..only displays a "2"on the bottom set of zeros //run time at present 12.20 mins...

Yeah Sparkey, not much will happen unless you have the external RTC connected. The last 2 represents the time out error from the I2C functions.

If you connect a button to input pin 1 you should be greeted with a snapshot of the current time in the second half of the window each time you press it.

Sorry about the lack of code commentary - just playing at this stage.

seco61
Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 205

Posted: 11:42pm 23 Jul 2011

Copy link to clipboard

Print this post

trippyben said Ahhh, the visibility of a DSO (and early morning though processes!) at 400kHz the clock pulses were more like a shark fin than a square wave. Dropping to 200kHz gives more time for each pulse to flatten out at the top. Seems ok thus far. Will keep playing.

Hi Ben.

Glad you are having some success. I have found the same to be true of the bus signals when operating at the higher speeds. When I intend to operate over 100kHz I will ensure my cables have a ground line on all "sides" of the clock and data lines.

Just as an aside, reading through the datasheet, I see it does not mention what happens if you send values to the registers that are outside the allowed values (as specified in table 2).

I notice with your initial write command where you write the first 14 bytes (register address byte followed by 14 register bytes), that you are sending binary zeroes for all bytes which will be outside the allowed values for some of the BCD encoded fields.

Also, I was wondering if you could use the output pin of the device as the signal to get the Maximite to read the updated contents of the RTC every second. Either set the ouput to the 1Hz square wave or set it as an alarm every second.

Regards

Gerard (vk3cg/vk3grs)

Regards

Gerard (vk3cg/vk3grs)

Dave Everett
Regular Member

Joined: 24/06/2011
Location: Australia
Posts: 43

Posted: 12:08am 24 Jul 2011

Copy link to clipboard

Print this post

Geoffg said I have another test version of the Maximite firmware for adventurous people to try out.

You can download it from: http://geoffg.net/Downloads/Maximite/Maximite_Update_V2.4B.z ip

Great to see this officially added Geoff

I have been looking at adding PWM functions to the code. There are 2 hardware PWM lines still available on the chip, OC1 and OC4. These could be wired to 2 of the extra ground lines on the 26 way header and Timer2 is available for compare functions.

Dave

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 05:28am 24 Jul 2011

Copy link to clipboard

Print this post

Dave Everett said

Geoffg said I have another test version of the Maximite firmware for adventurous people to try out.

You can download it from: http://geoffg.net/Downloads/Maximite/Maximite_Update_V2.4B.z ip

Great to see this officially added Geoff

Yes, that does seem feasible. It would require hacking your Maximite PCB though.

Geoff

Geoff Graham - http://geoffg.net

trippyben

Regular Member

Joined: 26/06/2011
Location: Australia
Posts: 91

Posted: 07:18am 24 Jul 2011

Copy link to clipboard

Print this post

seco61 said
Hi Ben.

Glad you are having some success. I have found the same to be true of the bus signals when operating at the higher speeds. When I intend to operate over 100kHz I will ensure my cables have a ground line on all "sides" of the clock and data lines.

Just as an aside, reading through the datasheet, I see it does not mention what happens if you send values to the registers that are outside the allowed values (as specified in table 2).

I notice with your initial write command where you write the first 14 bytes (register address byte followed by 14 register bytes), that you are sending binary zeroes for all bytes which will be outside the allowed values for some of the BCD encoded fields.

Also, I was wondering if you could use the output pin of the device as the signal to get the Maximite to read the updated contents of the RTC every second. Either set the ouput to the 1Hz square wave or set it as an alarm every second.

Regards

Gerard (vk3cg/vk3grs)

I had not considered that issue - as I am not reading back those registers, i just chose to initialise all to get things going.

The square wave output is quite useful for that sort of thing. The reason i chose this RTC for my application was that it has 1/100th second counters and if you read all timekeeper registers in one go there is no rollover issues.

Print this page

To reply to this topic, you need to log in.