I would like use battery backup SRAM in STM32F4 MCU. Is there some way how detect disconnected/removed battery after connecting VDD voltage (after reset)?
Yes, I can save CRC of backup SRAM in RTC backup registers, but I would like get information from some MCU register.
Thank you for your answer
Vbat is connected internally to the channel 18 of the ADC. You just need to enable the bit VBATE in the CCR ADC register and convert. This channel has internal divider and the read value is 1/4 of the actual one.
Related
I am doing a university project in which i have to build a I2C which have only one slave and will have to transmit a data with 5 bits, 4 bits for the number which is in the range of 0 to 9 and 1 bit to read or write, i'm using a DE10-LITE with VHDL for this project, which has a 50 Mhz default clock, i was looking into the "ALTPLL" inside quartus prime but i can't find the option to set my clock to 100kbps, i did find in the in some forums that the "Set up PLL in LVDS mode" enables that, but for some reason quartus won't let me activate it. My SDA will be 100kbps, and the SCL 50mhz.
As the Other people have said: You don't need a PLL for that. If you already have a default clock of 50MHz then you just need to divide that by 500, using a counter, and then you have your 100kHz clock.
Anyways, you would want to start the counter only when there is a request on the bus. So user16145658 is correct: The generated clock should be the output of your state machine.
You don't need to change the clock of the FPGA, since you are using an FPGA, you only need to implement an i2c core to communicate with the i2c device.
And the i2c specification specifies the rate of i2c
Standard mode (Sm) 100 kbit/s
Fast mode (Fm) 400 kbit/s
I have an Arduino Uno R3 (actually, distributed from Elegoo but has the same exact components) and I thought about burning the ATMega 8 chip on it with a bootloader, using the "Arduino as ISP" feature on the Arduino IDE.
I looked at the specs for the ATMega 8 chip, and I would like to just ask - everywhere I've looked online, it says the default CPU clock speed is 16MHz, which makes sense because of the crystal clock onboard running at 16MHz. However, I'm not sure the code I have already written is safe:
#define SPI_CLOCK (16000000/6) // Internal clock speed 16 MHz for Arduino UNO.
I think that this code will be fine considering the specs. The example told me to set SPI_CLOCK to a value of 1000000/6, which slow enough for an ATtiny85 (# 1 MHz), but since I want to use the full functionality of the crystal I have onboard and want a faster clock speed, is it safe to set SPI_CLOCK directly to 16000000/6?
Any help will be appreciated.
Thanks!
Anyways, AterLux answered my question:
Setting SPI clock speed on the programmer only affects how fast you can flash the device. It does not change how the flashed code works – AterLux
I want to use hdmi monitor with cyclone V GX board, but I don't get an acknowledgement from adv7513 on i2c bus.
I think there is a problem with the address that I am sending at the beginning of the i2c transaction (I get no acknowledgement of address) I couldn't find information on whether PD/AD is low or high. Also I am not sure if i should use 7 or 8 bit address, so I would like some explanation.
I used i2c controller that i found online:
https://www.digikey.com/eewiki/pages/viewpage.action?pageId=10125324
signaltap result
I assume you haven't read the ADV7513 Programming Guide
The ADV7513 uses four I2C register maps. The SDA/SCL programming
address for the Main Register Map is 0x72 or 0x7A, based on whether
PD/AD is pulled high (10KΩ resistor to power supply = 0x7A) or pulled
low (10KΩ resistor to GND = 0x72) when power is applied to the
supplies. The user should wait 200ms for the address to be decided,
after the power supplies are high, before attempting to communicate
with the ADV7513 using I2C
I2C addresses are 7-bit or 10-bit not 8-bit. In this case it is 7-bit.
See I2C Specification. So if PD/AD is high, 7-bit address is 0x7A. In binary your 7 bits will be: 1111010. The R/W bit is the last bit of the first I2C 'address' byte but the vhd code you posted doesn't need that as part of the address, that's done separately.
addr : IN STD_LOGIC_VECTOR(6 DOWNTO 0); --address of target slave
rw : IN STD_LOGIC; --'0' is write, '1' is read
If you are still having problems, check your pull-ups, I2C SCL clock rate, ensure the master allows clock stretching. The VHDL code you posted has quite a lot of information about how to use so re-read that.
Alternatively take to question to Electrical Engineering Stack Exchange and take some oscilloscope readings of SDA/SCL.
I'm using STM32F411 with USB CDC library, and max speed for this library is ~1Mb/s.
I'm creating a project where I have 8 microphones connected into ADC line (this part works fine), I need a 16-bit signal, so I'm increasing accuracy by adding first 16 signals from one line (ADC gives only 12-bits signal). In my project, I need 96k 16-bit samples for one line, so it's 0,768M signals for all 8 lines. This signal needs 12000Kb space, but STM32 have only 128Kb SRAM, so I decided to send about 120 with 100Kb data in one second.
The conclusion is I need ~11,72Mb/s to send this.
The problem is that I'm unable to do that because CDC USB limited me to ~1Mb/s.
Question is how to increase USB speed to 12Mb/s for STM32F4. I need some prompt or library.
Or maybe should I set up "audio device" in CubeMX?
If small b means byte in your question, the answer is: it is not possible as your micro has FS USB which max speeds is 12M bits per second.
If it means bits your 1Mb (bit) speed assumption is wrong. But you will not reach the 12M bit payload transfer.
You may try to write (only if b means bit) your own class but I afraid you will not find a ready made library. You will need also to write the device driver on the host computer
Do the windows built in com port drivers support non-standard baudrates? (actually does windows have a built in driver for com1 & 2?)
The reason I ask is I'm having trouble getting a reliable connection to a device that uses the unusual baudrate 5787. The device & PC talk briefly, then seem to loose the dialogue, and then get it again. Once a long message is sent, it gets lost at the other end, a short time later the dialogue is back. This sounds to me like the classic baudrate mismatch. Not quite close enough to be reliable though but close enough that some data gets through.
If I use an inexpensive PCI serial board it works without problems. It's only computers that use on board serial I've found don't work properly.
Baudrates in a PC are controlled by a UART and a crystal. The crystal frequency determines what baudrates the serial port can generate. The baudrate is often generated by a divide by 16 counter. The crystal frequency for a standard PC is normally 1.8432 MHz. Dividing that by 16 gives you 115200 which is usually the maximum the com port can do.
Inside the UART is a DLAB register. This further divides the clock. So essentially, to get 5787 baud you're talking about dividing 115200 by 5787 which gives you 19.906687...
It's close to 20 you'd load the DLAB register with 20. 115200 / 20 gives you 5760. Therefore you're probably getting 5760 baud out of the PC com port. That's probably enough of a difference to cause the issue that you're seeing.
No, the difference from 5760 to 5787 is nowhere near enough to explain any sort of problems. UARTs identify the start of a byte from the leading edge of the start bit, then sample the data in the middle of each bit. This means they are tolerant to errors in Baud rate up to the point where the predicted middle is an edge. That's a half bit error in one full byte, because each byte has a stop bit so there's a re-synchronise event per byte. On half bit in ten bits (8 data, one start, one stop) is 5%. The difference from 5760 to 5787 is only 0.5% so miles inside the safe region.