Thanks Kurt. Were you using the hardware serial or the standard SEROUT when you noticed timing problems? I would hope the HSEROUT, HSERVO, etc would give better results when inserting code on a hardware interrupt.
-Drew
I was using the standard software driven Serout. I plan on trying the hardware serout but I have the PS2 controller on some of the IO lines used by the hardware version and I have not tried moving it yet.
Kurt
I use the hardware serial to interface the Sabertooth motor controller and it works well. Now if only the i2c were so easy… 
Are you having problems getting I2C working? I have had 3 Microchip MCP23017 I2C I/O expanders interfaced to an Atom PRO, and that was working just fine.
What I2C device are you trying to interface with and what microcontroler are you using?
8-Dale
ha funny, i was just reading your posts on the basic micro forum trying to figure out the i2cout command. I’m using an Atom Pro 28 with the new (8.0.?) ide. The device is a Mindsensors LCD.I used the code from the I2C thread on the Basic Micro site where the address is shifted 1 bit left and included in the data. The command just jumps to the error routine.
I’ll have to boot the PC in the RobotRoom to get the code… 
I don’t get all the address shifting, because I never had to shift the address to get I2C to work. All I know is it worked and worked well.
Please post your code when you have a chance, including all variable declarations the code segment uses. I will look at it and compare it with my code for I2C and the Atom PRO and see if I can find the problem.
8-Dale
Drew, do you mean I2CIN?
On the AtomPro I have to bitshift I2CIN data occasionally (or cater to a misset high bit). If the slave device holds the clocking line low, according to I2C specs, the master should wait for it to be released before clocking in data.
It’s intended to give the slave time to collect its wits and assemble the data for transmission. It doesn’t happen with ‘dumb’ devices like EEPROM, but when you have a microprocessor controlled slave (a lot of Devantech modules), it can be an issue. Its not a deal breaker, just need to be aware that your MSB wrong, and everything else in the byte is shifted >>1.
I started a new thread since this is becomming (another) Atom Pro I2C conversation.
PS - There is interrupt timer code on the Basic Micro site that works great.
Unfortunately, using the timer throws off the I2C routines. It’s too bad the I2C commands are bit banged when I believe there is a hardware I2C peripheral on the chip. I guess using interrupts for encoders will have the same effect.
I agree! Hopefully, Basic Micro will take more advantage of onboard hardware features as times goes on. I2C would be a great next venture along that course. 
I think maybe they underestimated what uses their Atom chips would find in robotics (and what we would try doing with them). 
Generally, if there is a feature available, I will find some way to exercise and use it. Unfortunatly, that means I tend to trip over bugs more frequently also.
8-Dale
I also had problems with the timings on I2C code when the timers code was running. So when my code was doing some I2C work I would disable the timer interrupt. This was not great but luckily the timer code was mainly only used for interfacing with the TV remote and I could lose this support during the I2C communication. Likewise I had problems with some characters being garbled when I output to my serial LCD at 9600 baud with the timer running. It worked OK at 2400 baud.
Like lynxguy, I wish they would take more advantage of the hardware of the underlying chip. Other options they maybe should consiser is to provide/export some support for one of the hardware timers. Maybe something like get a current time or the like that would have a hardware interrupt that would keep time in some increments and of which the other underlying commands would know to take into account when calculating the delays and the like. I would think they would already have to do some of this to support the hardware servo commands.
Kurt
Basically what you are describing is a tick(sort of). I don’t use a general tick in MBasic because a) I wasn’t planning on making it multitask(outside of interrupts at least) which is were a tick can come in handy and b) I didn’t want to require any piece of hardware be left alone by the user if I didn’t absolutely have to. As it is you can access any hardware you want at any time unless you are specifically using particular hardware commands(eg hserial and hservo). I looked(eg experimented) with a hardware timer as the basis behind all timer critical functions but found I couldn’t get the resolution I needed without a lot of extra overhead so all commands, unless they specifically say they use hardware, are bit banged. I will put “clock stretching” for i2c on my todo for the next release though.
Yes, I am describing a tick counter. They do come in handy in many different places. For example the TV Brat project needed to measure the difference in time for the signals to calculate when and which button was pressed. Outputing stuff to an LCD display, there are places where the manual says that you should delay X time after you do some command for you ouput the next. There is no clean way to do this right now, so you either hope the time has delayed, or you pause your program some amount of time to make sure, which wastes lots of time…
I totally understand your reasons for not wanting to generalize this. I do like and appreciate the idea that I do have access to the underlying hardware of the microcontroller and have used it some so far and will probably increase it. For example I will try to use the hardware I2C. The problem I have run into though is the more I try to use things like interrupts, the more likely the bit bang functions stop working reliably.
My guess is that have to deal with this some already. For example when you enable the HSERVO and define the number of groups, that this information is taken into account when you do a command like serout. Assuming this is true then the reason I thought you might consiser adding something like an ENABLEHTICK with some commands like GetTickCount… is to allow you to factor the overhead into your bit bang functions.
An alternative approach may be to export one of more functions that allow us to tell you about the interupt overhead. This would be somewhat easy for fixed types of interrupts like timers where we could give you a somewhat fixed number. It might be a little more interesting for interrupts that happen on a non-regular basis. For example if the HSERIN and HSEROUT commands were implemented through interrupts it would make your bit bang functions a little more complex to implement as you would probably need to take into account some dynamic information about interrupt overhead in these functions timing loops. My guess is the HSER functions are implemented by polling the devices and as such you avoided these issues.
I probably rambled on enough here 
Interesting conversation. I think it really gets to the issue of “Basic” microcontrollers, i.e., Atoms, Stamps, etc. The value they offer is ease of use and flexible routines but at a performance cost. It seems once you try to eliminate some of the performance cost, the ease of use starts to slip. Inevitably, if you need hardware access, RTOS, interrupts, etc. you are going to end up programming in C/C++ and all the ease of use benefits of a Basic micro just complicate things. I think it is smart for Basic Micro to not want to risk the ease of use and flexibility of its products by trying to be all things to everyone. Atom Pro 
True to a point. Even using a high level language on a micro would require the above. Just because someone uses C/C++ doesn’t automatically give them a tick. Ussually you only get a tick with a full blown OS. You can however setup a hardware timer to keep track of time very easily and without using ANY interrupts(though using a timer interrupt gives you more options). If you’d like, open a new message talking about a timer tick and I’ll post an example of how to do one in MBasic for AtomPro. It can be done for Atoms and MBasic for PICs but not as well because interrupts are only processed between commands in those cases. Also just wanted to point out I wrote the TV Brat program and it’s timer interrupt handler. That is a good example of an interrupt tick.
Yes and no. Only timing critical functions(eg asyncronous) will have issues. Bit banged serial is my primary example. The Pause style commands would be effected. So would the pulsin and puslout commands. It all comes down to how accurate do you need to be. In general serial commands have to be exremely accurate whereas pause commands and even pulse commands have some wiggle room.
Actually no. HServo(the newest version in 8.0.1.0) only uses a MAX of 2.5% IIRC. To be safe assume 3%. Thats running 32 servos all the servos moving(not just holding position). In normal use on a 28pin module you’ll see 1 to 1.5% usage(max) which isn’t enough to really screw with most bitbanged commands.
What you are describing is a nice thought but not possible(at least not on a micro even as powerfull as the AtomPro). To keep track of the overhead of interrupts accurately enough to be usefull you would end up with most of your processor power used up in over head(and your timer hardware would have to be dedicated to do it as well). I’ve already done tests to prove it to myself. It’s not possible to be everything to everyone(as said by the next poster).
The Hserial back end is handled entirely by interrupts.
When a byte is received an int is triggered and the byte is read out of the single byte buffer in the hardware uart(eg the byte is received by hardware and then the int is triggered) and stored in the circular input queue(by a very tightly coded interrupt handler.
When bytes need to be sent out a byte is read from the circular output queue and given over to the uart to send. When it finishes an int is triggered and another byte is gotten from the queue and sent out add infinitum until no bytes are left to be sent out.
The Hserin and HSerout commands do nothing but get or put bytes into the circular queues for the interrupt handlers.
Total processor power used for all of this is so small as to be pointless to calculate which is why hserial backend doesn’t have a noticable effect on software serial commands or other bitbanged timing based commands.
Also I just wanted to point out you can already adjust your own timing to take account of any over head you KNOW about. There is no need to tell me(eg the compiler) about it. You can adjust your pause commands to be shorter and you can adjust the bitrate of your software serial commands to adjust “for fixed types of interrupts like timers”.
No, AtomPro is not everything to everyone, though I think it does better than just about anything else in it’s category. That was one reason I left the option of writing in C/C++ for the AtomPro. That and one day I’d like to build a C/C++ library for AtomPro to duplicate all the MBasic functionality.
This is very good to now. If I could have my main wish for the Atom PRO, it would be to have commands to make use of ALL the neat hardware features, including I2C and such. It just seems silly to me to not provide easy access to ALL the hardware features of the Atom PRO through the command language. Better access to interrupts would be my real close second (or maybe hardware I2C would be second, with ability to be master OR slave) wish. These are so important to me, it is real hard to pick which one I would rather have first. 
I am sure that if I could have gotten the IRQ1 interrupt to work, that I could have gotten the PING sensor to work through the MCP27017 I2C expander chip. I think I am so close to having the right code, or maybe it is right and just not working as it should. I don’t know which it is. I want to do some real advanced stuff, and interrupts and I2C are a necessity. This is really the only other reason I am going to get setup to work with PICs. The other reason is cost - the Atoms are just too expensive for me to risk blowing one. Other than these things, I really like the Atom PRO.
8-Dale
I have opened up a new thread on this.
Actually I have seen and used this approaches like this done in the past with very little overhead. They are a pain to implement (and can be very error prone), but for a bit bang function like SEROUT, where you do something like:
SET pinx High
WaitClockTicks(nNumberOfClocks)
Set pinx Low
Your wait function may be implemented like:
void WaitClockTicks(int nTicks)
{
nGlobalWaitTicks = nTick - (subroutine overhead ticks);
while (nGlobalWaitTicks > 0) {
nGlobalWaitTicks -= (number of ticks per interation);
}
}In each of your interrupts you could include a line like:
nGlbalWaitTicks -= (number of ticks for interrupts including latency…)
Depending on your processor this may be very difficult to accurately calculate each of these number of ticks, but if you can reasonaby estimate it would make the waits reasonably close. Just an idea and probably way out of the scope of this thread.
That was how I was hoping the HSERIAL commands would be implemented . I hope to use them soon. Since these interupts are realitively infrequent I could imagine that their impact on the bit bang serial functions would be minimal.
Thanks again for all this detailed information!.
Writing something in a high level language is great an all for displaying a concept but you have no idea how much processing time it actually takes until you put it in assembly. I’ve written the equivilent of what you’ve described here. The current serout command can handle a max of 57600pbs. Add in the necessary code to process what you describe above and the serout command will max out at half that or even a quarter that rate. Same applies to all the other timing critical functions. Pulsout would have half to a quarter the resolution and 2 to 4 times the minimum pulse width. Pulsin would probably be worse, approx 4 to 6 times the minimum pulse width because I already had to do some very nasty coding to get it where it is. In other words, it was a no brainer. I went for top performance of normal commands instead of tweaking everythying out so that interrupts had no effect on those commands. The simple fact is interrupts are not something used by 99.9% of programmers using basicstamp style micros. There is a simple solution to remove interrupts from messing with your timing critical code. Simple disable the interrupt while processing that code.
Sorry I appear to have pressed a hot button.
It was simply a possible solution to fixing a timing issue timing issue I ran into using your interrupt code for the BRAT and trying to run an LCD using your serout command at 9600 baud. If this is something that you are not interested in or you do not think will work for you, that is fine.
FYI - the last time I used something like the WaitClockTicks function was on an AVR Atmega32. Depending on compiler flags, I believe the inner loop was 6 or 7 clock ticks per loop and in timer critical area I had this in C++ as an inline function so the subroutine overhead was 0. (Yes many C or C++ programmers do really look at the generated code)