Interrupt question

[wagp]

In appendix 4 of manual 2 it discusses Possible Conflicting Commands.

IN paragraph 1, Under the heading "Internal Interrupt Driven Event Tasks" is it talking about interrupts that are handled by the "INTERRUPT" routine that I write in my program, or is it talking about an interrupt that is handled by microcode in the processor?

 

[nick12ab]

is it talking about an interrupt that is handled by microcode in the processor?

Yes that is it.

 

[wagp]

another question

Yes that is it.

I'm trying to develop a monitoring system that has background serial I/O (hsersetup), I2C (hi2csetup), serial I/O, timer1 (settimer/setintflags) and timer3 (tmr3setup) all in the same program.

Any chance I can make it all work?

 

[westaust55]

I do not have a firm answer as I have not investigated or tried myself however,

Your question is only valid if you are looking to use an X2 part as an i2c slave device.

From the manuals both i2c... and hser... commands are trying to use the scratchpad area to read/write data.

Maybe expand a little more on exactly what you are trying to achieve and a clear/firm answer might be given.

 

[nick12ab]

I'm trying to develop a monitoring system that has background serial I/O (hsersetup), I2C (hi2csetup), serial I/O, timer1 (settimer/setintflags) and timer3 (tmr3setup) all in the same program.

Any chance I can make it all work?

Unlikely, and this is out of the question if you will be using the PICAXE as an i2c slave as the interrupt conflict will (in my experience) lock up the i2c bus.

There was also another thread recently regarding use of normal serial (serin/serout) at the same time as uisng background serial receive - in fact it was yours. My suggestion was that you eliminate the need for use of the serout command by changing to a parallel display, and westaust55 also suggested use of a shift register for the LCD with parallel interface to reduce the number of pins used.

 

[wagp]

I posted this same question a few days ago. I didn't do a very good job of explaining the problem I'm having and didn't really understand some of the suggestions, so I thought I'd try again.

I'm developing a monitoring system. All of the Picaxe computers are X2 parts.
The one with all the potential conflicts (background serial , serial I/O, I2C, timer3, timer1 interrupts, etc.) is a 40X2.

It's also the Master on the I2C bus and therefore doesn't have any conflict with the background serial receive in usage of its scratchpad memory.

The problem I'm having is the background serial receive stops before it gets all of the data that was sent.

In the earlier post it was thought that this may be caused by the serial I/o to the displays occurring at the same time as the background serial receive. I don't fully understand what appendix 4 of manual 2 is trying to say and it seems there may be other possible conflicts.

If the conflict is only between the SIO and the background serial receive is there a way I could detect that background serial receive is occurring and delay the SIO to the displays until the background is complete?

Thanks to all for trying to help.

 

[nick12ab]

If the conflict is only between the SIO and the background serial receive is there a way I could detect that background serial receive is occurring and delay the SIO to the displays until the background is complete?

Yes you can, by checking the hserflag (but that might not change until after the first byte is received). However that won't allow you to detect the background hardware serial receive during the serout command so the best thing to do is to eliminate the serout command by using a parallel display.

Here is an experiment to try to determine whether the timers will conflict or not - connect some LEDs to the PICAXE which will indicate the progress through eact test that you program the PICAXE to do. Example tests:

• Control i2c devices at the same time as background hardware serial receive
• Run timer and timer3 at the same time as hardware serial background receive
• Run timer and timer3 at the same time as controlling devices on the i2c bus

 

[srnet]

is there a way I could detect that background serial receive is occurring

Yes, but unless you can stop the PC sending data, what is to prevent the PC sending more data, just after you have decided that the serial receive is idle ?

 

[inglewoodpete]

The problem I'm having is the background serial receive stops before it gets all of the data that was sent.

How do you know that the background serial receive stops? I have found out the hard way that you can't use Debug, SerTxd or SerOut to display what is being received until the received data is complete. Those 3 commands, for instance, have to disable the internal interrupts in order to use the strict timing necessary for their outputs. This results in the serial input data not being transferred to the scratchpad quickly enough, causing the received serial data input buffer to be overwritten.

Perhaps you need to condense the offending code and post an example that demonstrates the problem that you are having. I imagine that your program is quite large and, if posted as is, would scare away many forum members. I realise that this could take you a couple of hours but I have found that it helps to isolate the problem and get the best solution. (Personal experience.)

 

[geoff07]

Yes, but unless you can stop the PC sending data, what is to prevent the PC sending more data, just after you have decided that the serial receive is idle ?

The traditional way, which may or not be compatible with what you are doing, is to use Clear To Send (CTS) and Ready To Send (RTS) lines as a flow control handshake. If the PC has a true serial interface (rather than a USB gadget) this should be strainghtforward. The sending UART raises RTS when it wants to send, and the receiving end raises CTS when it is ready to receive.