I have been using esp32 for some projects.
Now i want to include classic bluetooth with a serial profile for one of our old projects.
In theory ESP32 is class 1,2,3 Bluetooth and in theory it supports 100meters.
I have been trying to raise the TX power for bluetooth playing with function esp_bredr_tx_power_set.
I have been able to raise it a bit passing params:
esp_bredr_tx_power_set(ESP_PWR_LVL_P9,ESP_PWR_LVL_P9);
But it is not enough. I have another bluetooth class 1 device with serial profile with more power (one from bluegiga).
Power consumption is not a problem in this project but distance is critical.
Is it possible to raise the power of classic bluetooth more on ESP32?
To check that power is assigned right, i used the get fuction
esp_power_level_t min,max;
esp_ble_tx_power_set(ESP_BLE_PWR_TYPE_ADV,ESP_PWR_LVL_P9 );
esp_bredr_tx_power_set(ESP_PWR_LVL_P9,ESP_PWR_LVL_P9 );
delay(1000);
esp_bredr_tx_power_get(&min,&max);
Serial.printf("min %d max %d",min,max);
The pause is used to be sure that power is changed (if you do it without delay, you see the old value). Probably 1s is too much, but this is just a test.
Thanks.
The highest TX output for an ESP32 is +9dbm, which falls in-between BT class 1 (+12dbm) and class 2 (+4dbm). So you have what it seems already set your TX power output to the maximum. It's not clear if you are using an PCB antenna or an external antenna, the latter will of course increase the range.
For the different BT power classes see this link
See Espressive document (scroll down to section with ESP_PWR_LVL_P9)
Related
I had written a code on atmel studio for blinking a led on pin 13. After uploading the code with xloader mega's builtin led was blinking.
I uploaded fade code on my mega and the builtin led was blinking instead of led. What should i do?
I am using arduino mega 2560.
int main(void)
{
DDRB=0b00000000;
while (1)
{
PORTB=0b10000000;
_delay_ms(1000);
PORTB=0b00000000;
}
}
What you should do? Read the manual.
Please refer to https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf
Chapter 13.2.
The DDxn bit in the DDRx Register selects the direction of this pin.
If DDxn is written logic one, Pxn is configured as an output pin. If
DDxn is written logic zero, Pxn is configured as an input pin.
Working with registers doesn't make sense if you don't know what they do.
DDRB=0b00000000;
Gives you inputs only.
why would you use Arduino and try to program it without its conventional macros and functions?
If you are trying to blink an led or make it breath then use the Arduino IDE and its built-in functions analogWrite() to generate a pwm pulse for your led or any led on suitable pins which support analogwrite(). You shouldn't try to do any direct modifications on registers if you have no suitable knowledge, because your risk destroying your development kit and maybe burning some other stuff around. Please use your kit's schematics to spot the pins which support analogwrite() and then use the code in examples.
That way you will achieve your goal faster and without any issues.
TL/DR: you have to set 7th bit in DDRB to one.
In AVR ports are configured by bits in two registers: DDRx and PORTx.
When the corresponding bit in the DDRx register is set to one, the port is configured as output. And the corresponding bit in the PORTx register chooses which electrical level is output on the pin. If it is 0 then internal MOSFET shorts the pin to "ground" lane, and sinks current from external source. When the bit of the PORTx is one, then the pin is connected to "VCC", sourcing big amount of current enough to lit up a LED.
But if the pin is connected to something, what consumes too much of current, or the pin is shorted to GND or VCC (let's say you have a button connected and pressed), then output MOSFETS might be overloaded and damaged.
If the bit in DDRx is set to zero, then the pin is configured as input. If the corresponding bit in the PORTx is zero, then the pin has no internal connection to power lines, it is called "Hi-impedance" state, or Tri-state. It does not source or sink any current. So, if no external source of current is connected, then pin level is floating, influenced by electrical interference. Logical level is not detectable and can change occasionally. If you want to connect, for example, a button (between the pin and GND), then logical level will be defined only when button is pressed. When it is released, the logical level will be undefined.
But! If the bit in the PORTx is set to one, then internal MOSFET connects the pin thru a resistor (about 35 kOhm) to VCC line. This make the pin to source a little amount of current, setting its logical level to high. Therefore, if a button is connected, when it is released, then pin will have defined high level. This is called "pull-up resistor". When button is pressed, it will not short and damage the MCU, because current flowing thru the button is limited by the resistor, but the logical level will be defined low.
What if instead of button you have a LED connected to the pin? Very small amount of current will flow thru the LED, makes it barely glow.
Read more in the datasheet (chapter 13. I/O-Ports)
This is driving me nuts for a couple of days now, so maybe you guys can give me some insights into what is going wrong.
I'm trying to read some data from an EEPROM (24LC16B) with an STM32(F0), but it just doesn't let me. I've tried an Arduino, which worked and does still work, so I do know that the wiring is correct.
This is my function to read the EEPROM data. (It is cut down to the very basis, just for testing): (Pastebin of my I2C_setup function)
uint16_t readEEPROMData(uint16_t deviceAddress, int memAddress){
// Wait while I2C peripheral is not ready
I2C_WaitForFlag(I2C_ISR_BUSY);
// Start I2C write transfer for 2 bytes, do not end transfer (SoftEnd_Mode)
I2C_TransferHandling(I2C1, 0xA2, 2, I2C_SoftEnd_Mode, I2C_Generate_Start_Write);
I2C_WaitForFlag(I2C_ISR_TXIS);
// For testing purpose, be sure to generate a stop command...
I2C_TransferHandling(I2C1, 0xA2, 0, I2C_AutoEnd_Mode, I2C_Generate_Stop);
return I2C_COMM_STATUS;
}
Here's an pastebin of the Arduino library I used.
I've used a logic analyzer to see how the communication is going, and now I really don't understand it. Here's a printscreen of the working Arduino version:
And here's a printscreen of the STM32 communication:
Logic analyzer exports (viewable with Saleae Logic)
As you can see, I'm using the same address (although I had to use 0xA2 with the STM32), and there are no weird things happening, besides the NACK. So what could possible be wrong?
Confirm if all bus timing requirement are satisfied.
Confirm if their is adequate delay after every write cycle (5 mS)
Confirm is bus capacitance falls under permissible limit of I2C (400 pF - Theoretically).
Confirm if the correct VCC is supplied
As mentioned by you are interfacing EEPROM with MCU using cable you need to conform on capacitance.
You can use an oscilloscope to check if their are any distortion in waveform. You can use a LCR meter to check the capacitance.
Try reducing bus speed 25kHz to 50 kHz and check waveform.
Try increasing the strength of pull resister.
The problem with the wrong VCC capacity (4.2v instead of 5v for example) is, that the timing can be different to. (not fully verified, but it fixed the problem)
I am trying to make a large moving sign that consists of Arduino (as the microcontroller), an 8x8 dot matrix (as the display) and MAX7219 (as the controller for the dot matrix display).
Is it possible to use 16 MAX7219 chips?
Thanks.
I don't know what arduino board are you using, and the answer may vary. Anyway:
If you have an Arduino UNO: you can't connect them directly, since the UNO has 14 digital I/Os, and you need at least N+2 pins to communicate with N MAX7219. Moreover I think you want to send commands to it, so the number of pins is drastically reduced. You can however use any port expander to have more I/Os and so communicating with it.
If you have an Arduino MEGA you will probably already have already all the I/Os you need.
In both cases probably the limiting factor will be the speed.. Just make some tests and you'll find it out
I need to make a device where there has to be the following components:
1. An accelerometer chip ( as thin and small as possible)
2. A bluetooth or low power data transmitter
The device will be attached to an object and if the object is moved in a certain way, a small amount of data needs to be transmitted indicating that the object has moved.
Restriction: The whole device has to be as thin as possible.
The transmitter can be low powered because the receiver will be within a few feet(4-5 feet). The amount of data transmitted is also very small (a few bytes).
Can you guys give me a suggestion what are the devices I can use?
I am thinking about an MPU-6050 3-Axis Gyroscope + 3-Axis Accelerometer 6-DOF Module (Arduino Compatible Core Module) and an adafruit trinket. But I do not know what module I can use to trasmit the data.
Any suggestions will be greatly appreciated.
Try this one:
http://www.aliexpress.com/item/nrf51822-MPU6050-6pixs/32456095618.html?ws_ab_test=201407_1%2C201444_6_3_2_1_5_4%2C201409_1&spm=2114.01020208.3.2.MJWube
It is a module with Bluetooth (nRF51822)/6-DOF Gyroscope/Accelerometer as well as a wireless charging module. The size is only 16 mm and the module is super thin.
I used this for my project and worked very well.
A lot of tools can be used for programming it like MK20 USB from redbearlab or just nRF51822-mKIT.
I'm new to microcontroller programming and I have interfaced my microcontroller board to another device that provides a status based on the command send to it but, this status is provided on the same I/O pin that is used to provide data. So basically, I have an 8-bit data line that is used as an output from the microcontroller, but for certain commands I get a status back on one of the data lines if I choose to read it. So I would be required to change the direction of this one line to read the status thus converting this line as an ouput to an input and then back to an output. Is this acceptable programming or will this changing of the I/O pin this frequently cause instability?
Thanks.
There should not be any problem with changing the direction of the I/O line to read the status returned by the peripheral provided that you change the state of the line to an input before the peripheral starts to drive the line and then do not try to drive the line as an output until the peripheral stops driving it. What you must try to avoid is contention between the two driver devices, i.e. having the two ends being driven to opposite states by the processor and peripheral. This would result in, at best a large spike in the power consumption or worse blown pin driver circuitry in the processor, peripheral or both.
You do not say what the processor or peripheral are so I cannot tell whether there are any control bits in the interface that enable the remote device to output the status so that you can know whether the peripheral is driving the line at any time.
I've done this on digital I/O pins without any problems but I'm very far from an expert on this. It probably depends entirely on which microcontroller you are using though.
Yes, it's perfectly fine to change I/O direction on microcontroller repeatedly.
That's the standard method of communicating over open-collector buses such as I2C and the iButton. (see PICList: busses for links to assembly-language code examples).
transmit 0 bit: set output LATx bit to 0, and then set TRISx bit to OUTPUT.
transmit 1 bit: keep output LATx bit at 0, and set TRIS bit to INPUT (let external resistor pull-up line to high)
listen for response from peripheral: keep output LATx bit at 0, and set TRIS bit to INPUT. Let external resistor pull-up line to high when peripheral is transmitting a 1, or let the peripheral pull the line low when peripheral is transmitting a 0. Read the bit from the PORTx pin.
If both ends of the bus correctly follow this protocol (in particular, if neither end actively drives the line to high), then you never have to worry about contention or current spikes.
It`s important to remember that any IO switching in high speed generates EMI.
Depending of switching frequency, board layout and devices sensibilities, this EMI can affect performance and reliability of your application.
If you are having problems in your application use an oscilloscope to check for irradiated EMI in your board lanes.