ESP32 Forum

* +1 proper documentation(hardware documentation is poor, more software/hardware examples).
* configurable parallel port(with data/command, chip select, reset, write/read, all configurable ) in isolation from the i2s module.
* mipi dsi.
* graphical controller(with tearing support).
* independent communication with psram and flash memory(dual sqi controller maybe, more package pin 64 pins maybe), so on boot i can load a critical part of flash into psram memory without reading psram/flash stall.
* 64 pin package.
* more internal static ram/cache.
* powerfull fpu/dsp instructions.
* FreeRtos support for static allocation memory.

I would like:

Hardware
1- A better ADC (more accurate) in my current project I had to add an external ADC because each esp32 had a different reading for ADC
2- Option to lower power consumption 20mA with BT (no sleep)

Software
1- Better documentation more detail / explanation
2- More sample code with real use cases, not just small tests

Business
1- A cheaper version ala (esp8266) but with BT only

I really enjoy esp32
Thanks

Any thoughts on something like a FPGA section in HW, like a FPIOA(Field Programmable IO Array). This would allow for great flexibility in the GPIO space. Furthermore having programable hardware would be great in situations like when you need an extra or custom HW component, like a extra UART etc ...

Inspired by https://www.indiegogo.com/projects/sipe ... -ai-module

Also something like KPU(Neural Network Processor) would be a super bonus, but i dont see that "fitting"

My biggest hope would be sub 1GHz RF

Thanks

For aiding in push button debounce... Schmitt trigger inputs.

Burtrum

For aiding in push button debounce... Schmitt trigger inputs.

Burtrum

You can handle that with a simple cap/resistor on the pin or in software. Not to mention a debounce time for one type of button would not be enough for another.

Like everyone else, better documentation would be a plus. What's wrong with it? Well, it seems like the sort of documentation that was written after the fact and just *barely* describing what things are. Very often functionality is essentially glossed over. What I mean is, descriptions are VERY terse usually and don't really tell us what something actually does. So, more complete documentation would be nice. I know, documentation is about the least fun part of any project.

Another request - currently RMT doesn't really support DMA and chaining the way most of the other high speed digital peripherals do. I can chain I2C buffers with DMA and send out huge streams of data. Likewise, PWM output can be done DMA. But, I really can't do that with RMT. It seems like a very obvious hole since it falls into similar niches as PWM and I2S. But, it's even more useful for arbitrary protocol decoding as the format: bit level, duration is EXACTLY what we'd normally want when decoding protocols. It's a lot more convenient than getting thousands of samples with I2S then having to sift through them. So I'd really love to see RMT supported as a DMA source and destination. I think this would really make sense. Otherwise RMT doesn't have enough built-in storage to be nearly as useful as it could be.

USB for sure! USB2.0 high speed 480mb would be handy. Obviously you don't really need to support 480 megabits per second from the ESP32 but being able to send something like 30-40 megabits/s would be handy. It's weird that currently the old Arduino Due (Atmel SAM3X) is more useful for USB connected serial as it has native USB and thus one really can get up over 10mbs through the USB port. Though, it actually is kind of nice not to rely on USB on chip as the Due can get into weird situations where you brick the USB stack and it's hard to reflash the chip after that. So, maybe look with an eye toward not requiring the USB stack to actually run on the processor. If it is possible to integrate a serial to USB module on-die that might be sufficient. I'm not sure I care enough about a true arbitrary USB interface stack running on the processor itself. Others will no doubt tell me I'm wrong.

CollinK wrote: ↑

Tue Nov 26, 2019 2:51 am

Like everyone else, better documentation would be a plus. What's wrong with it? Well, it seems like the sort of documentation that was written after the fact and just *barely* describing what things are. Very often functionality is essentially glossed over. What I mean is, descriptions are VERY terse usually and don't really tell us what something actually does. So, more complete documentation would be nice. I know, documentation is about the least fun part of any project.

Hi CollinK,

Do you mean documentation for bare metal functionality described in ESP32 Technical Reference Manual or software documentation described in ESP32 Programming Guide?

Could you give some examples which particular pieces of documentation to improve?

Hi,

"Do you mean documentation for bare metal functionality described in ESP32 Technical Reference Manual or software documentation described in ESP32 Programming Guide ?"

ESP32 Technical Reference Manual: i2s module for example are very badly explained. Parallel mode like lcd for example. *I2S_TX_FIFO_MOD[2:0].
*I2S_TX_CHAN_MOD[2:0].
*I2S_LCD_TX_SDX2_EN.
*I2S_LCD_TX_WRX2_EN.
*I2S_DATA_ENABLE_DELAY Number of delay cycles for data valid flag. (R/W)
what equation ? The are two bits. 00, 01, 10, 11. what does each one do ?
*i2S_AHBM_FIFO_RST Set this bit to reset AHB interface cmdFIFO of DMA. (R/W) when should i do this. We were not the ones who designed the machine.
*I2S_LC_FIFO_TIMEOUT_SHIFT The bits are used to set the tick counter threshold. The tick counter
is reset when the counter value >= 88000/2i2s_lc_fifo_timeout_shift. (R/W)
times units based on what( crystal clock ? ) there are 3 bits. 000, 001, ....., 111. what meaning of each ?
* I2S_OUT_DSCR_ERR_INT: Triggered when invalid rxlink descriptors are encountered. rxlink or txlink ? page 316.
* I2S_IN_DSCR_ERR_INT: Triggered when invalid txlink descriptors are encountered. rxlink or txlink ? page 316.
* I2S_OUT_EOF_INT: Triggered when rxlink has finished sending a packet. rxlink or txlink ? page 316.
* I2S0.sample_rate_conf.tx_bits_mod = 32; // set to 32 to transmit 8 bits ???
* I2S0.conf.tx_right_first;
* I2S0.conf_chan.tx_chan_mod
* I2S0.fifo_conf.tx_fifo_mod
* I2S0.conf.tx_msb_right
* I2S0.conf2.lcd_tx_sdx2_en = 0; // these 2 bits have four possibilities.
* I2S0.conf2.lcd_tx_wrx2_en = 1; // all for possibilities should be well explained.



In addition, espressif staff need not be answering so many questions with good documentation/examples.


Thank's.

Hello,

Many requests result in a CPU and not a microcontroller.
Of course, less power consumption, more computing power, more FLASH, more RAM would be better.
But the chip already covers a lot.
My wish would be an MRAM (1 KByte or more).

JimmyO wrote: ↑

Sat Dec 07, 2019 7:03 pm

My wish would be an MRAM (1 KByte or more).

Embedded MRAM is not there yet I think. The problem with it is that you need a speciality process for it, unlike embedded SLC flash.

I heard TSMC was doing trials, but no idea how it went later. Maybe you should call and ask them if they provide it on 40nm ulp, and for how much?