Has anyone been able to use a 'blackpill' microcontroller (STM32F401) with a 128x64 OLED display, using the SS_OLED library?
I am using the following
Arduino IDE
ST-LINK V2 to program it (using the 3.3V rail to power the MCU)
PB6 as SCL
PB7 as SDA
If I run the I2CScanner app, it finds the display at 0x3C, as expected. Using an oscilloscope, I can see activity on the I2C lines.
If I run the SS_OLED library example 'SS_OLED_TEST', nothing happens; no display and no SCL/SDA activity.
In both cases, the I2C init code looks like this.
Wire.setSDA(PB7);
Wire.setSCL(PB6);
Wire.begin();
Any help would be greatly appreciated!
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 Tested a simple "hello world" application for RedPitaya FPGA: RedPitayaHelloWorldVHDL.
It takes a clock from PACKAGE_PIN U18 and U19, devides it by frequency to receive 1Hz, and outputs counter to LEDs. After making a bitstram and writing to FPGA by command:
cat bitstram.bit > /dev/xdevcfg
LEDs blinks good, but Linux on board of RedPitaya hangsup. Why it's happening? and how to avoid it?
You need to instantiate a Zynq "PS7" component in your design, that is the interface between the Linux SoC part and the FPGA fabric, there is also a wizard in Vivado to configure this. If this component is not in the design then programming the bitstream crashes the SoC.
If the Linux on Red Pitaya also assumes the presence of any AXI slaves on the FPGA fabric side, omitting these from the design might also cause a lock up, but this is less likely to be the problem.
Has anyone out there successfully driven an HT16K33 using MCC i2c generated code?
Using my own rudimentary i2c code I can get the HT16K33(link below) to work ok but no matter what I try the MCC i2c code will not work. As a sanity check I have the MCC code working ok with a PCF8574 io expander.
I am testing with a 16F18877 on a breadboard, no schematic, the HT16K33 is on an Adafruit board(link below), all is verified working with my i2c code and the io expander.
The HT16K33 is an LED controller. Requires three i2c commands to test, turn on oscillator, turn on display, and send data to the display ram. Holtek recommends having a 100ms delay at the program entry to allow the chip to start up which I have before any i2c commands. I have boiled this down to the simplest possible test of the MCC code by using my working code for the display on and ram data, only using the MCC code to start the oscillator which is the first step.
I2C1_MESSAGE_STATUS status = I2C1_MESSAGE_PENDING;
I2C1_MasterWrite( 0b00100001, 1, 0x70, &status);
while (I2C1_MESSAGE_PENDING == status);
http://www.holtek.com/documents/10179/116711/HT16K33v120.pdf
https://learn.adafruit.com/assets/32012
Any ideas?
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.
I am having an odd problem with my PIC16F88. I have an EEPROM connected thru I2C and it works flawlessly until I write to portb.bit6. From that point on, I start getting garbage from my EEPROM. I tried explicitly disabling Timer 1, which uses portb.6 for oscillator-out but that did not help. I tried cutting the trace from the PIC pin (pin 12) so that there is nothing physically connected to it and that did not help. My C code is simple, either portb.6 = 0 or portb.6 = 1. Either way, reading the EEPROM thru I2C fails forever more. The generated ASM code looks fine. The problem occurs on every board that I have tried it on, so it is not localized to one PCB. I am mystified. Any suggestions?
It turns out that it is necessary to write a zero bit to the SCL and SDA pins every time before writing to any bit in portb. FWIW, I was bit-banging rather than using the SSP peripheral of the PIC16F88 for the I2C communicaitons. Thanks to the people on the Yahoo group, Electronics_101, for figuring out this puzzle.