Use of interrupts

[giacomo892]

managed to fix the pull request.

[DzikuVx]

Heh, better. Will test it next week

[DzikuVx]

@giacomo892 apparently it's not working like expected. Range is not measured (debug LED does not goes off when object in range) and I2C is broken too.

[giacomo892]

Since currently I don't have an attitny to test I'll try to code logic on a 328p and report back.

There should be something stupid related to interrupts setup...

[giacomo892]

Hi!

Do you mind testing this little piece of code? Just flash it and remove the HC from the breadboard and just connect a wire to Vcc and touch ECHO_PIN (maybe a little pull down resistor on ECHO may be needed..) randomly with it.

the led should trigger on and off .

#define TRIGGER_PIN 3
#define ECHO_PIN 4
#define LED_PIN 1


void setup() {
  pinMode(TRIGGER_PIN, OUTPUT);
  pinMode(ECHO_PIN, INPUT);
  pinMode(LED_PIN, OUTPUT);

 
  /*
   * Setup Interrupt for ECHO
   */

    GIMSK |= _BV(PCIE);                     
    PCMSK |= _BV(ECHO_PIN);
    sei();      

}

void loop() {

}

ISR(PCINT0_vect) {
      digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}

Thanks

[DzikuVx]

@giacomo892 LED was responding. But I somehow recall ATtiny is somehow special on interrupts, they work slightly different than on ATmega

[giacomo892]

@DzikuVx if the last example code works it may be something related to sleep or i2c library.

have you tried adding a TinyWireS_stop_check(); in the loop() ?

[Hrumque]

If you recommend using US-100 instead of HC-SR04, why do not you recommend using the US-100 serial mode?
It gives directly the result of the measurement of the distance in mm, directly in digital values, transmits the data via ttl-usart 9600-8-N-1, and it is much more accurate (because performed by the quartz stabilized system and considering the ambient temperature) than the measurement of the pulse length by Attiny (Clocked internal RC, that is pulse time measurement depends on temperature, moon phase and uC internal RC calibration)

In that case - using Attiny would only be limited to cyclical start measurement, and i2c bus operation. Once bored, it would take into account the sensor's slope relative to the surface (information about tilt in X and Y axes - from signal for telemetry or OSD. So that the measurement of distance to the ground was corrected and did not depend on the fact that we actually measured at an angle to the ground (of course for some small angles, because in a racing quad with a 60 degrees angle it is not sense).

Or even better - use two or three sensors positioned at a small angle to each other (e.g., 30 degrees, since each beam is about 15' wide) and determine the actual distance to the ground - from trigonometric calculations.

[DzikuVx]

@Hrumque US-100 in serial will be added in the INAV firmware, not this helper device.

Serial mode has one "problem" as it is using UART port. And usually they are limited in most of the boards.

US-100 in this helper with ATtiny is also impossible to do since I2C and UART shares the same pins

[Hrumque]

@DzikuVx Ok, version with I2C have one big benefit - few devices on one bus (with different addresses), so you can use this "sonar helper" (or many sonars), and other peripherals, only using 2 pins of main FC

I think the good solution would be to add support for additional bridges to usart, connected via i2c / spi , such as the SC16IS740 / 750/760 NX family (or something software-based on some atmega?), so that any standard FC board can have any number of additional features, that should be supported without eating CPU resources - especially when using SPI in DMA mode (but anything is better than softserial on main cpu).

Other "half" solution could be adding "addressing" to all usb devices. Ie apart from the current communication (eg OSD), they would be added at the beginning of the transmitted frames - the addresses of the device to which it is dedicated. And every device - would send to the FC data preceded by its address (eg 0x1A for OSD, 0x20-0x30 for sonar sensors, etc).

So that by connecting one device to one usart port - we work like normal now, only we get free automatic recognition by inav "which is connected to the port" (in the returned addresses in the transmission from the device).

And it would give you the ability to connect multiple devices to a single port, just connect TxD to all RxD and TxD devices - via LEDs and pullup (to create AND-on-wire )

Unfortunately, this would require rebuilding firmware FC, and all peripherals - ie, minimosd etc