 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : I2C example - Curious error
| Author | Message | ||||
| Bizzie Senior Member  Joined: 06/07/2014 Location: AustraliaPosts: 185 |
Hi All, About to embark on a major project using bigmick's I/O boards so decided to set up the I2C example from the MicroMite manual (4.5). Typed in the example code to two MM's running 4.6 I hope the images are clear enough thought this was best way to show both Master (left) and slave (right). 
This code is functionally identical to the manual (well except for the commented out print statement in the slave code). If I then run the slave and type the ssetpin command into the master I get number out of bounds error from the slave and a reboot of the slave. :- 
Now if I uncomment the print statement which I inadvertently put before the I2C Slave read things work as expected. It seems to me the slave read does not handle the array correctly. 
Rob White |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
You have a sub and a function with the same name for a start - spin. I am not sure if that is legal or not, but probably not.... Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5913 |
Try putting a delay at the start of the ReadD sub. The sub is called as soon as there is some data available but it takes time for the rest of the data to arrive. Posting your programs as code rather than an image will make it easier for other to read it. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
I agree with Jim - it's hard to read those images. I would also be inclined to move most of your slave read code, into your main DO/LOOP, keeping the ReadD I2C read interrupt as short as possible - best not to hang about inside interrupts. 
Could it be possible that the I2C is timing out? You could try increasing the master timeout to 250 or something - I2C OPEN 100,250 - that sort of thing. The time taken to print the three tabulated results as the first line of code in the ReadD interrupt, could possibly be taking more then 100mS, and this would cause the master to timeout waiting for the slave to respond. In my I2C experiments, I have found that sending data byte-at-a-time rather then as strings seems to be the most reliable(for me, anyway), with acknowledge bytes back to the master - this seems to work at any speed, right up to 400kHz no problem. Here is the slave code from one of my projects: I2C SLAVE OPEN &B1010101,0,0,I2C_OUT,I2C_IN DO do watchdog SET 'Keep resetting watchdog loop until BITE=EOM 'Wait till a full message is received. Print "EOM detected. Message length is ";Len(dta$);" bytes." pin(BUSY)=0 'Tell CPU SUBSYS is busy pin(SUBSYS)=1 'Disable SUBSYS LED on bargraph P=1 'Reset string pointer for sucking out message lines DO 'Suck out message line #1 B$=mid$(DTA$,P,1) 'Extract byte from I2C string L1$=L1$+B$ 'Add byte to current line string P=P+1 'Increase string pointer loop until B$=chr$(13) 'Loopy thing till a CR is detected DO 'Suck out message line #2 B$=mid$(DTA$,P,1) L2$=L2$+B$ P=P+1 loop until B$=chr$(13) do 'Suck out message line #3 B$=mid$(DTA$,P,1) L3$=L3$+B$ P=P+1 loop until B$=chr$(13) do 'Suck out message line #4 B$=mid$(DTA$,P,1) L4$=L4$+B$ P=P+1 loop until B$=chr$(13) Do 'Suck out message line #5 B$=mid$(DTA$,P,1) L5$=L5$+B$ P=P+1 loop until B$=chr$(13) Print "LINE 1( HUGE): ";L1$ print "LINE 2(LARGE): ";L2$ print "LINE 3(LARGE): ";L3$ print "LINE 4(SMALL): ";L4$ print "LINE 5(SMALL): ";L5$ Print:print 'Space on terminal between messages for debugging print #1,Chr$(27)+Chr$(33)+Chr$(&B00111000); 'Select huge text Print #1,L1$; 'Message mode print #1,Chr$(27)+Chr$(33)+Chr$(&B00100000); 'Select large text print #1,L2$; 'Date print #1,L3$; 'Time print #1,Chr$(27)+Chr$(33)+Chr$(&B00000000); 'Select small text print #1,L4$; 'Name print #1,L5$; 'Address print #1,chr$(13)+chr$(10) 'Space between messages do:loop until lof(#1)=256 'Wait till serial TXD buffer is empty DTA$="":BITE=0 'Clear I2C message string and byte value L1$="":L2$="":L3$="":L4$="":L5$="" 'Clear all line strings for next time pin(BUSY)=1 'Tell CPU SUBSYS is ready pin(SUBSYS)=0 'Enable SUBSYS LED on bargraph Loop END '-------------------------------- 'I2C INTERRUPT HANDLING ROUTINES: '-------------------------------- I2C_OUT: I2C SLAVE WRITE 1,75 'Send K acknowledge byte(is ignored) IReturn I2C_IN: I2C SLAVE READ 1,BITE,BUF DTA$=DTA$+Chr$(BITE) IReturn End This code sucks a five line text message from the master for printing on a thermal printer connected to COM1 on the I2C slave Micromite. Note how all the data string processing is NOT done inside the interrupt, rather the interrupt just keeps building up a string(DTA$ in my example) until an EOM(end of message) byte is detected. This is a special non-printable character byte that indicates the end of the message. Once THAT is detected within the main DO/LOOP, then the processing begins at that point. I also set a line low from the slave MM to the Master, so that it knows not to send anything else while the slave is in the thinking DO/LOOP - this is normally less then 150mS though. In the master code not shown here, the master waits for the acknowledge "K" byte from the slave before sending the next byte of the message. This handshaking continues to the end of the message. I can put up the master part of the code if you like, but I thought it might be useful to see how I did it in my slave code, and this does seem to work very well. Smoke makes things work. When the smoke gets out, it stops! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1097 |
@ Bizzie I can confirm that your code, as taken straight out of the manual, fails as you indicate on line 14. It appears that the variable cfg in the slave which is supposed to be setting the pin as a digital out (8) is actually being received as a 0 (I put a print statement prior to line 14 to give the pin and config info) This could be a timing issue in that the cfg parameter doesn't arrive quick enough - haven't been able to check that yet. panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Bizzie Senior Member Joined: 06/07/2014 Location: AustraliaPosts: 185 |
Thanks all for you comments. I can confirm that a pause 10 will overcome the issue. Rob White |
||||
 Print this page |
