I have a a Sparkfun Max 7456 breakout board that I am trying to rewrite the character table to an ASCII format. I have been following the Arduino + MAX7456 OSD thread but cannot seem to load the .mcm file to the breakout board. I have tried hyper terminal and tera term. Tera term allows me to "transfer" the mcm file but I do not get any type of confirmation in the terminal window. When I try simple sample code like "Hello World.ino" I get no response and the default character set is still displayed. Hyper terminal tells me there is a COM port conflict with the Arduino IDE. I know the steps are available in the above mentioned thread but the picture/ code resources have mostly been removed. I don't know if I'm missing something in the code or if I am not using the terminal program correctly. I have the following connections between the breakout board and the Uno and have been trying Arduino code provided at the start of the thread;
Breakout/ Uno;
CS-->D10
SDIN--> D11
SCK--> D12
SDOUT--> D13
+5V
GND
I have tried using wires that are <5cm and >=10cm and I am using NTSC. Can anybody determine what I am doing wrong or point me in the right direction please. Thanks in advance,
I figured out my issue. Using Google translate I was able to get code from;
http://f5mna.free.fr/Arduiexpert.htm
Previously, I was only making the connections listed in the code when the full list is;
D13--> SCLK
D12--> SDOUT
D11--> SDIN
D10--> CS
+5VDC must be applied to the +5V pin on the board as well as a 1k resistor in series with LOS and a 10k with RESET.
As for using tera term. First shutdown the Arduino IDE and open the connection in the terminal program. The code provided in the above link will indicate it is ready for file transfer and will prompt you with a transfer complete message.
All in all, simple solutions but I was a newcomer to a very old thread. Hope this helps anyone else having the same issues in the future.
Related
I have ESP23 dev kit with micropython firmware esp32-idf3-20200329-v1.12-317-g688323307.
I also have ds18b20 waterproof sensor. datasheet link
I wrote this code for it:
import time, onewire, ds18x20
import machine
from machine import Pin
ds_pin=Pin(19)
ds_sensor = ds18x20.DS18X20(onewire.OneWire(ds_pin))
roms = ds_sensor.scan()
for rom in roms:
print(rom)
It returns tis info:
[bytearray(b'(\xbcN6\x14\x19\x01\xba')]
Before reading temp data from sensor, we first need to use the scan() function to scan for DS18B20 sensors. The addresses found are saved on the roms variable (the roms variable is of type list). scan() function sends request and sensor returns its unique 64-bit serial code.
I used manual here
Today I bought two more ds18x20 waterproof sensors (I don’t know what type of sensor - ds18a20/ds18b20 or else - are they, ‘cause eager chinese manufacturers sealed sensors inside metal bullet too good, so I can’t just look inside).
I tried to run the same code with them, but it returned the following:
bytearray(b'(\xff\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfe\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfc\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf8\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xd0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xfe\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xf6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xe6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xc6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xfd\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xf9\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xfe\xff\xff\xff')
bytearray(b'(\x90\x86y\xfa\xff\xff\xff')
bytearray(b'(\x90\x86y\xf2\xff\xff\xff')
bytearray(b'(\x90\x86y\xe2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xfd\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf9\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xe1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xc1\xff\xff')
bytearray(b'(\x90\x86y\xa2\x81\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xfb\xff')
bytearray(b'(\x90\x86y\xa2\x01\xf3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xe3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xc3\xff')
bytearray(b'(\x90\x86y\xa2\x01\x83\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfe')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfc')
bytearray(b'(\x90\x86y\xa2\x01\x03\xdc')
bytearray(b'(\x90\x86y\xa2\x01\x03\\')
When I try to read temperature using this values it returns ‘CRC error’.
What can be done? Is the problem with code, or the sensors are failed somehow?
Connect one sensor at a time when you do the scan.
You haven't shared how you're wired the DS18x20 sensor. Make sure its positive power connection is to 3.3V not 5V.
Make sure you've connected a resistor (4.7K should be good) between the data pin of the sensor and 3.3V. OneWire devices absolutely won't work reliably without this resistor - you might see the kind of problem you're seeing.
If you're sure it's wired correctly the next step would be to try it with different firmware, for instance a Dallas one-wire scanner using the Arduino Core. That would eliminate the possibility of problems with the library you're using and MicroPython.
looks like fake sensor
How to tell original from fake DS18B20 temperature sensors
Looks like i'm a fool))
Yes. One 4.7K pull up resistor and it's alive! IT'S ALIVE!!
aaaand whats'up doc?
then we use internal PULL_UP mode we pull up signal only for ESP.
BUT! DS18B20 is microchip too. And the wire for little DS18B20 is like giant radio aerial.
Maybe in my first sensor this problem was solved on hard level.
I just installed the latest version of LIRC(0.10.1-5.2) on my Raspberry Pi 3, running Raspbian on Debian Buster.
I am trying to get my Pi to take input from an IR remote using lirc.
I have made the necessary changes to these files :
/etc/lirc/lirc_options.conf
driver = default
device = /dev/lirc0
/boot/config.txt
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
//I set mine on up on GPIO pins 17 and 18 instead of 22 and 23
I have checked and cross-checked my circuit. Everything looks okay.
The challenge I'm facing right now is when I test my IR receiver using the following command,
mode2 -d /dev/lirc0
Nothing happens. There's no output at all. No pulses recorded.
Has anyone else experienced this issue?
Any help would be much appreciated.
After spending a great amount of time, trying to figure out how to solve this issue, I was finally able to resolve it.
So hopefully my answer will help someone else.
First things first, it's important to note that infrared device has changed from lirc-rpi to gpio-ir
Although, I already had this change in my /boot/config.txt
file,like below:
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
// in stead of dtoverlay=lirc-rpi
I just thought it was important to point out.
Since I am trying to get my Pi to take input from an IR remote using lirc, I decided to first test my IR sensor separately, to make sure it works.
To do that, I connected up the sensor like so:
Pin 1 is the output so we wire this to a visible LED and resistor
Pin 2 is ground
Pin 3 is VCC, connect to 3v3
You can find more detailed step by step instructions from this tutorial here which also shows how to wire up your circuit as seen below.
During this test, my LED lit up each time I pointed a remote at the receiver, which gave me hope that it was working just fine.
The next step was to test the IR receiver on my raspberry pi, which is the challenge I had in the beginning.
I re-wired my circuit, this time:
Pin 1 is DATA, goes to RPi pin 12 (GPIO 18)
Pin 2 is GND, goes to RPI pin 6 (GROUND)
Pin 3 is POWER, goes RPi pin 1 (3v3)
Then I ran this command sudo /etc/init.d/lirc stop to make sure that service wasn't running.
I then ran the initial command mode2 -d /dev/lirc0 and now pressed random buttons from my remote at the receiver and violá! I could see some pulses on the screen with each button press now.
Like you I managed to get all the way to receiving pulses/data on the RPI 3, seem to have a problem with the output.
I have the USB strip light and my RPI with the IRC receiver, this is so I can monitor what data captured corresponds with the button pressed on the remote keypad. Works just fine.
However? If I push the ON button - I get data, if I push the ON button again I get another set of data. The two set of data dont match? , in both cases mode2 or mode2 -r.
I get the feeling I'm missing a method to decode the output, I've noticed there's a huge amount of companies and they all have distinct code sets.
Here is one thread that exactly matches what I have (24-Key IR remote).
http://woodsgood.ca/projects/2015/02/13/rgb-led-strip-controllers-ir-codes/
However I dont see the same set codes ???
Try to change the device to mode2 -d /dev/lirc1
I also faced this.
I am using the internal oscillator (FOSC = 7.37 Mhz) of the dsPIC33EV256GM102. I have a 1602 LCD connected to the PIC via 4 data, and enable, RW, and RS control lines.
I write initialization commands to the LCD and then two lines of text. That works fine.
After 2 minutes and 10 seconds the enable line quickly pulses high-low causing something to be written to the LCD. It happens again in another 2:10 and then again, repeatably.
All my program does right now is initialize the LCD, write two lines of text and go directly into a while(1).
I have tried setting the LCD enable low on every iteration of the While. I have tried latching the enable low before going into the While. I have moved the enable to another pin but the pulse still occurs on that pin. If I remove the enable line after writing the data, the problem goes away.
Any thoughts what might cause this kind of behavior or what additional troubleshooting steps I might take?
I am using pin 24 labeled RPI45/PWM1L2/CTPLS/RB13 for the enable but I have also tried pin 23 labeled RPI44/PWM1H2/RB12. I am not executing any code related to peripheral pin select yet.
When I download the program via the Pickit3, for the first POR while the Pickit3 is still in the circuit, there is some spurious text written to the LCD. So I have to disconnect the Pickkit3 and do another POR before the two line of text are written correctly without any unwanted additional data writes.
In conclusion there are two issues really or perhaps they are related?
I have been working with ATmega128 and other such series for about 2 years and used a UART library for serial transmission. I am pretty sure the library is correct because I have used it hundreds of times but from the past few months I cannot do UART on my ATmega128. I am sure that my hardware is correct, I am sure of my code and to add to it, the same hex file runs good in other two ATmega boards but not in other boards.
PORTs are giving 5V output when all pins coded to give output.
Statements execute before any UART function occurs and after that it stops (does nothing, no UART, not even statements after UART)
I tried copy pasting UART code completely in main.c and it worked then.
Please help! I have no idea what is going on.
Well, after a lot of tussle, I finally found the problem and solved it. When I checked the fuse bits of the other microcontroller (the working one), I found Extended Fuse bits different from the not working microcontroller. I changed the Extended Fuse bits to 0xFF and problem solved.
I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!