The Omega2 cannot interface to the HC-SR04 Sonar sensor using the same technique that the Arduino uses. This is due to the Linux OS running on the Omega2 whereas the Arduino does not run an OS.
The HC-SR04 works by sensing a high-to-low transition on its Trig input and then emitting an ultrasonic ‘ping’. When the ‘ping’ is emitted the Echo output goes high. When the reflection of the ‘ping’ is heard by the sensor the Echo output is driven low. Timing how long the Echo output was high for is the key to using the sensor.
In order to get accurate timing of the Echo output, hardware must be used. Software timing will be inaccurate due to the Linux OS.
The Omega2 does have SPI hardware. SPI is a synchronous serial protocol. SPI is basically a shift register. During an SPI transaction, data is shifted out on one edge of the clock signal and shifted in on the other edge. To interface the HC-SR04, the SPI port is used to capture the Echo output as the input (MISO) to the SPI port. This way the clock rate of the SPI port will determine the sample rate or resolution of the timing. The lowest speed clock rate for the SPI on the Omega2 is 50KHz or 20 uS per bit. The SPI hardware of the Omega2 has a 16 byte internal buffer. 16 bytes yields 128 bits of timing data. In other words, using the SPI port you can time an event that is a maximum of 2.56mS with 20uS resolution.
Sound travels at about 0.034cm/s at sea level. Appling this to the HC-SR04 interfaced to the SPI port yields a best case of 0.68cm/bit. This has to be cut in half because the time is the time for the ‘ping’ to go out and come back. So 0.34cm/bit. The 16 byte SPI buffer yields 128 bits so the best case distance is 43.51cm. The best case is never achieved due to a delay in the HC-SR04 between when Trig is detected low and Echo goes high.
The accuracy of this interface technique is dependant on the SPI clock time. The 50KHz clock yields 0.68cm/bit. Increasing the SPI clock speed would yield better accuracy, however, due to the 16 byte buffer limitation, doubling the clock speed would halve the maximum distance.
The maximum distance can be increased by using DMA or an interrupt to move data out of the hardware SPI buffer and into memory. Then a longer transaction can be used. Currently the SPI driver in the Omega2 does not support DMA or interrupt. If you want to send or receive more than 16 bytes you must use multiple transaction instead of one long transaction. Due to the delays introduced between transactions it is impractical to use multiple transactions and expect to have accurate timing.
Bottom line, you can interface an HC-SR04 to an Omega2 using the SPI port. The limitations are that the accuracy will be 0.68cm and the maximum distance will be around 35cm (about a foot). If and when the SPI driver is updated to use DMA or interrupts to allow for longer transactions then longer distances and greater accuracy can be achieved.
The Python code below demonstrates the feasibility of this technique. One more thing, the HC-SR04 is a 5V device. To avoid destroying your Omega2 you will need someway to translate the 5V Echo output to 3.3V used by the Omega2 GPIO. The simplest is to use a voltage divider consisting of a 1K resistor and a 2.2K resistor. The IK is wired to the Echo output. The other end is wired to the 2.2K resistor. The other end of the 2.2K resistor is wired to Gnd. The junction of the two resistors is wired to GPIO pin 9 of the Omega2.
#This works out to a distance of about 30 cm !!!
#decrease the resolution, so better solution is to enable SPI DMA transfers.
#of isolating the Echo signal to prevent it from killing the Omega's GPIO pin.
#wired to Gnd. The junction of the two resistors is wired to MISO (GPIO 9).
I have looked at interfacing an HC-SR04 sonar module to the Omega2+. The interface technique used by the Arduinos of toggling Trig and then sampling Echo to look for a high then grabbing the time in mS, then sampling Echo looking for a low, then grabbing time again and subtracting to find the duration of Echo high, does not work on the Omega2. There are multiple reasons why it does not work. Mainly due to the Linux OS not allowing the GPIO pins to react fast enough.
You are stuck in the while loop because by the time the Omega2 changes Trig to low and starts sampling the Echo input for the low to high transition, it has already happened and you missed it.
I know this because I tried the same thing and looked at it with a logic analyzer and saw how slow the Omega2 reacted.
I did a project similar to what you are talking about. I used a 16x32 RGB LED matrix that has a hub75 interface (hub75 refers to the pinout and signals that drive the display). I did not use an Omega2, I used a Linkit Smart 7688 Duo. The Omega2 and the Linkit Smart 7688 Duo are both based on the MT7688. The Linkit Smart 7688 Duo also has an Arduino Leonardo on the same board. I used the Arduino Leonardo to drive the display and the MT7688 to handle the WiFi and to send messages to the display.
You will need 3.3V to 5V level shifters. The display is 5V and the Omega2 is 3.3V. The display requires 12 GPIO for 16x32 and 13 GPIO for 32x64. Arduinos have enough RAM to handle a 16x32 display. For anything bigger you will need a controller with more RAM. The Omega2 does not have enough GPIO to drive the display directly.
Adafruit sells a hub75 interface board that uses a Teensy 3.1 or 3.2 to drive the display. You could use one of those with the Omega2 as the WiFi link ( an expensive way to go). I designed a hub75 interface board for the project that I did. It uses a Linkit Smart 7688 Duo and has level shifters on the board.
If you want more information, give me your email address and I can send you an eagle package to make your own boards, the Python code and Arduino Leonardo code that I wrote for my project and a pdf of the schematic.
An experienced developer could easily make a hub75 interface board with a socket for an Omega2, level shifters and on on-board Arduino to drive the display. The board would be a mashup of the board I did and the Omega2 Arduino expansion board.
will result in about 150uS between SPI transmissions. If the SPI driver would recognize that the list passed in is longer than the built-in queues and then use an interrupt or DMA to keep the queue full until the list was exhausted then a list with several hundred bytes could be sent as one continuous transmission. This would facilitate using the SPI device to drive strings of NeoPixels. As it stands now, only a string of one NeoPixel can be driven by the SPI device. This would also help in using the SPI to communicate with an SPI based tft LCD or any device that requires more than 16 bytes in a continuous burst.
The second issue is that the first byte transmitted always sets the most significant bit to zero (when MSB first). So sending 0xAA results in 0x2A being sent. Not good. This only happens to the first byte of each burst. The only thing I changed from default was the bitrate.
Finally, a complaint that seems to be echoed everywhere in the world of the Omega2. That is the lack of documentation. What is available has mistakes, references the Omega or leaves a lot of information out.
I can control the GPIOs that control the LED using “gpioctl”. However, “fast-gpio” fails.
“gpiomux” also does not work.
It really would be nice if the examples in the documentation actually worked. Does anybody at Onion ever try this stuff before posting the docs ?
I am also having an issue trying to use SPI with Python. I add the "import onionPy" statement. When I run the script I get an error message that tells me "onionSpi" is not a valid import. This is right out of the using SPI with Python guide. How do I fix these ?
I upgraded to firmware version 0.1.9 b149. The SD card is being recognized. Thank you for that.
I have read in the documentation how to transfer the file system to a flash drive attached to the USB port. Can I transfer the file system to the SD card ? I have done this with a competitor’s SOC that uses the same processor as the Omega. The file system on an SD card is better than using a flash drive. It makes for a more compact setup and an expansion dock is not required.
Back to the Arduino dock V2. With the new firmware I am able to flash the Atmega328 on the Arduino-dock V2. The omega finally shows up in the Arduino IDE’s port list.
How about publishing the actual schematic of the Arduino-dock V2. The current documentation has the schematic of the Arduino-doc V1.
I tried to burn the bootloader into the Atmega328 on the Arduino dock V2 by using the Linux command given in the documentation; “sh /usr/bin/Arduino-dock flash bootloader”. All this does is tell me the Omega cannot find “bootloader”. That is why I asked where the Arduino bootloader file can be found. I thought that “bootloader” was a stand-in for the real file name. Foolish me. Turns out the bootloader is not needed.
BTW My system had the Bonjour service installed and I still could not connect using “omega-xxxx.local” until I edited the Windows hosts file and added the IP address and host name. I also setup my router to provide a fixed IP for the Omega’s MAC address. Which is another issue. The paper label on the Omega has a MAC address on it, but it is not the same MAC address that the Omega’s WiFi is using. The MAC on the paper label is used by the br-wlan, eth0 and eth0.1. A different MAC is used by apcli0. I typed “ifconfig” to get this information. I used the apcli0 MAC to setup my router. Again, it would be nice if things worked as described in the documentation.
I have an Omega2plus and an Arduino dock v2. I have installed avrdude 6.1 and arduino-dock-2. I am unable to program the Atmega328 from the Omega2. I can attach a USBasp dongle to the arduino dock's six pin header and program the Atmega328, but cannot program it using the Omega2. I have followed what others have posted without success. When I open the arduino ide, select Tools, Board: Arduino/Genuino Uno the port does not change and no options for anything other than Port1 are displayed. What do I have to do to get the Omega2 to show up as a port (I tried restarting the daemon, does not work). Also, where in the Omega2's file system is the bootloader located and what is it's name ? I ask because using generic 'bootloader' comes back with no file found. The fuses were set, but no file named 'bootloader' could be found. BTW I am not an Arduino newbie. I am a Linux newbie, but learning.
On another note, I am very disappointed to receive the Omega2+ that I ordered, only to find out that the SD card slot that I paid extra for is non-functional and has no set date when it will be. Shame on Onion for selling vaporware.
I have two Omega2+s, one Arduino dock and one Expansion dock. Both Omega2+ appear to be working with the expansion dock. Neither Omega2+ will work properly in the Arduino dock.
I have attached a USB to serial bridge/convertor to the three pin header for the Omega serial port. When I power up the Arduino dock usinf the miceoUSB connector, the 5V LED lights up and the orange LED on the Omega2+ also lights up steady. However, nothing comes out of the Omega's serial port. The USB to serial convertor that I use has LEDs to indicate Tx and Rx traffic. The Tx LED is brightly lit. It should be off and flash on when data is sent. Looking at the Omega_Tx pin on the three pin header, the voltage is 0V, a logic low. This should be a logic high when not transmitting. Looking at the schematics, the Tx signal from the Omega2+ is routed through a CD4052 switch that is controlled by GPIO19. It would appear that GPIO19 is not initialized properly to allow the CD4052 to steer the Omega's Tx output to the three pin header or there is some other hardware issue. How do I correct this ?
Until this is corrected the Arduino Dock is useless.
I went through the startup procedure and upgraded the Omega2+'s firmware. I have not done anything else with them.
When the either Omega2+ is in the expansion dock the serial port works through the microUSB header as expected.