 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 : Duinomite and MODGSM, incoming SMS
  Page 2 of 2 |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
I would hold the COM buffer, and give I2C priority. I would use SETTICK to set two timed interrupts to check both the COM buffer and the I2C for a message. When in your I2C message routine, disable the COM settick - this will allow your code to process the I2C stuff, while the COM buffer will hold onto the serial from the GSM - even multiple messages, if they are short. Once finished processing your I2C routine, re-enable the COM settick, and it will loop immediately to that, if there is anything needing attention. I would have the settick period at 500ms or so, staggered.(say 250mS for I2C and 500mS for COM kind of thing) It's amazing what you can do with MMBASIC, and the interrupts(especially the settick ones) are one of the main aspects of the MicroMite which allow it to win over the PICAXE for certain kinds of programs. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie  Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Grogster, thank you. Sounds perfect. Can you give a bit more detail. Ie. 1. How do you hold one over the other? 2. Can u give example of both SETTICK, esp for I2C (i have used many interupts but never SETTICK, so I am obviously missing a trick) 3. How does one disable SETTICK while handling I2C? No prob if you are too busy. I can research the manual. You seem to be here at very late hours!! I agree MMBASIC can be really powerful and can sometimes do so much with very few lines. Geoff did an amazing job. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Settick syntax is SETTICK X,Y$,Z kind of thing, where Z is the settick interrupt number from 1-4(all four tick timers can run at the same time), X is the period after which the interrupt is called in mS, and Y$ is the interrupt label. So, you could have the likes of: SETTICK 250,I2C,1 and/or SETTICK 500,COM,2 and I2C and COM are your interrupts. While in the I2C processing(NOT the I2C interrupt - the interrupt is just to DETECT if someone on the I2C wants to talk to you), you disable the COM one with the command: SETTICK 0,COM,2 - this will kill the COM interrupt and stop it from coming into effect. Due to the COM port buffer, so long as you don't overflow said buffer, any new messages from the GSM will be automatically saved there while you are doing your I2C processing. That done, at the end of your I2C routine, re-enable the COM port interrupt using SETTICK 500,COM,2 again just before you exit out of that routine. This will re-enable the COM interrupt, and if there is anything in the buffer, that interrupt can take over at that point. I would do it that way, simply cos the COM port has it's own automatic buffer, so it can essentially look after itself(so long as you don't overflow the buffer!), while I2C needs to be polled at the time you want to exchange data, or look at the bus to see if there is a slave device trying to send data to the master kind of situation. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I2C is a keyword so should not be used as a label and I would stay away from COM also. myI2C etc is a good way of playing safe with function names/labels. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
Good point about the I2C keyword - I had totally forgotten that. 
Follow Jim's wise advise re the naming of your settick interrupts there. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Eloclegin Newbie Joined: 01/07/2012 Location: United KingdomPosts: 25 |
Grogster et al. Thank you for the VERY helpful suggestions, hints and detailed code ideas. It has been a huge help. You are very generous with your time! This forum is so welcoming to newbies like myself. Your assistance is really appreciated Eloclegin Btw. Anyone know the I2c rx buffer size on a DuinoMiteMINI. No reply from olimex. I am seeing rx'd bytes go to zero if the burst is longer than around 80 bytes. I2c transfer is robust. Short cable. Have previously tested via loopback at 400k for hours without errored bytes. Just an issue if a burst length exceeds about 80 bytes in one go. I suspect buffer limit. Anyway, new uM's on the way and GSM900 arrived today! Cheers all |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
You are welcome, as far as my help is concerned. You are right about how welcoming this forum is, the same thing happened to me when I joined, and you can ask any question you like about any microcontroller etc, without fear of someone jumping down your throat for talking about the competition, or that the question has been asked before. As the forums have helped ME so much, I like to give back to the likes of you, whenever I can. I had to learn all the settick commands etc myself, so it is nice to be able to relay that information to a new member. As to the I2C buffer, not sure about the unit you have, but looking at the Maximite manual for MMBASIC, I was unable to find any information as to the I2C buffer. I would EXPECT that there is no buffer, although your testing seems to suggest otherwise, but it depends on how you are talking to the slave device and how often etc. As I2C is more of a "I know when data needs to come in or go out" kind of interface because of the master/slave concept - unlike serial, where data can arrive any time - I would have thought there is no data buffer, simply because if you need to write data, the master initiates that transaction, and if you need to read data from a slave, the master initiates that transaction also. Slaves will not send data to the master until the master asks for it, so a data buffer is not really so important in I2C. Slaves may well be ready to send some data they want to send, but they won't actually send any, until the master asks for it. That's only my interpretation of the I2C bus, but that might be false-logic, so other members here will put us BOTH right, if I have that wrong in my head. MMBASIC in I2C slave mode does have a "Buffer" in the form of a string variable to receive data sent from the master(see page page 58 in the v4.5 manual, under I2C SLAVE READ), but generally speaking, once there is anything at all in the string variable, the code will already be processing that data from the master, so I tend to just use byte-at-a-time transfers, along with acknowledge handshaking bytes back to the master. This proved to be very effective at large data transfers even at 400kHz. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 2 of 2 |
|||||
 Print this page |
