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
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
Good morning I need to perform a 0.4 Hz pwm and with LEDC I can only reach 1 hz in esp32. Could you tell me if there is a possibility to do it?
I assume you are currently using the functions from some esp32 library. Like in the Arduino world, there is another way. You can set the right Bits so you manually create a PWM signal. Here is the Technical Reference Manual:
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf
You will find all the relevant Information in chapter 14 (LED_PWM).
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
i have been working on a code where both 24lc512 and pcf8563 are interfaced together. Here in the breakup board of pcf8563 there are two 1K pull-up resistor on SDA and SCL line so am planning on using the same resistors for eeprom.
I had a code for eeprom which worked perfectly before with 4.7K pull up resistor, so i for making the code work for 1K pull-up resistor i made the following changes.(Coding was done for PIC16f877a with XC8 compiler)
SSPSTAT=0x80
SSPADD=(_XTAL_FREQ/(4*c))-1 //where c is 400,000
But sadly the code is not working as expected.Could someone please lend me help by saying what all changes should i bring in the earlier code so that it can work with 1K pull-up resistor.
Thanks in advance :)
The datasheet says
R = tr/Cb
where
tr is rise time (maximum specified at 1us)
Cb is capacitive load for each bus line with specified max. of 400 pF.
1x10^6 / 400x10^12 = 2500, so 2.7K would be the best choice if you're close to the maximum capacitance.
1K ohm sounds a bit low though, I'd try to unsolder the resistors and use 2.7 to 4.7k ohm instead. Only one set is needed if the bus lines are kept short.
Use an oscilloscope to check the signal shape. If the traces aren't nice and square then you need to adjust the resistors or shorten the bus wires. If the rise time is longer than 1us it may have problems too.
It would make much more sense to use a much lower bus speed, capacitance won't be much of a big deal. For a calender and a small eeprom 100K or even lower is plenty fast enough in most circumstances.
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.