|
|
| Author |
Message |
FFMan
Joined: 09 Jan 2010
Posts: 264
|
|
Posted: 23 August 2010, 21:31 PM Post subject: Input capture & bitbanging I2c |
 |
|
Working on a project that involves picking up an rpm signal via a signal conditioner, driving an I2c 4 digit 7 segment display and receiving GPS data via a serial port using a zx24n.
In first stages of testing and at the moment the gps is all disabled, so i'm just using my proven rpm capture and my PHAndersons bitbang I2c routines. I know the rpm interface and code (task) is sound as i ported it from my shift light project which is in the race car and works faultlessly. I am using the bitbang routines for i2c as there is a resource clash between h/w serial port and the built in i2c routines on this chip.
In early testing the rpm was displayed for a couple of seconds and then the display would blank and the rpm routine would seemingly return nothing. I put a locktask and unlocktask round the inputcapture command and this seemed to stabilise that part, but i would get occasional LED display corruption, so i put a locktask & unlocktask round the i2c write loop and this seemed to improve the display too.
Given I have yet to reintroduce the serial gps data, i am concerned that sprinkling lock/unlock task statements about will have a detrimental effect and is not the right approach. if i were able to use the h/w i2c routines is this problem likely to disappear ?
is it likely that inputcapture will work ok capturing rpm data whilst the processor is also receiving serial data at 57600 baud and attempting to write i2c data or am i expecting too much? |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 24 August 2010, 0:19 AM Post subject: Re: Input capture & bitbanging I2c |
|
|
| FFMan wrote: | | is it likely that inputcapture will work ok capturing rpm data whilst the processor is also receiving serial data at 57600 baud and attempting to write i2c data or am i expecting too much? |
InputCapture() is interrupt driven as are the hardware-based serial channels. It is unlikely that they would interfere with each other with the USART running at 57.6K baud. The hardware I2C channel is polled and it is unlikely that the ISR overhead for InterruptCapture() and the hardware USART would interfere with that. However, attempting to use the ZBasic software-based I2C would likely be problematic since it requires the use of the I/O timer - the same one that is needed by InputCapture(). |
|
| Back to top |
|
|
FFMan
Joined: 09 Jan 2010
Posts: 264
|
|
Posted: 24 August 2010, 7:54 AM Post subject: |
|
|
ok thanks. My 3 main io streams then are:-
serial gps (receive only) 57600 (tx pin 11, rx 6)
rpm using inputcapture (pin 12)
i2c io to display (pins 11 & 12)
i think i need to move to h/w i2c and drop the bit banging routines.
so it seems the zx24n isn't the way forward as we have a pin clash on inputcaputre and h/w i2c. if I use s/w i2c i have a timer clash. so maybe a zx40n is the correct choice of device ?
serial (com2 h/w) pins 16 & 17
rpm pin 15
i2c Pins 22 & 23
no pin clashes here then ! any other issues lurking do you think ? |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register