ESP32 is finally real?

[rudi ;-)]

..
one of our goals is to create register-level documentation for all peripherals
..
the plan is for the ESP32 to have support in OpenOCD out-of-the-box.
..
..

We can also compress the flash data while it's being sent (the ESP32 automaticallydecompresses it into flash) ..

thanks.

one question,

Let's see... the way multicore processing is handled has changed (AMP -> SMP), the entire memory map has changed, we now have Newlib mostly in ROM (plus some other goodies), the GPIO block is changed wrt how you configure the functions, I2S has gotten a gazillion more functions... those are the things that spring to mind directly. Also, don't try too hard to reverse engineer the registers used in the ESP31 if you can't figure it out from the SDK code: one of our goals is to create register-level documentation for all peripherals except certain specific ones. (Namely BT, WiFi and one of the ADC channels, if I recall correctly.)

can we use the esp31 then with the new SDK further ( stand basics like today ) too or is the version just in time on github the last version to use it with esp31? so we must do a full cut in projects to this version change :
ESP31 just in time SDK on github
next SDK on github only for ESP32?

thanks

best wishes
rudi

[rudi ;-)]

A herd of chips in the wild! I can't tell if these are 31b or 32.

http://imgur.com/QFzJj2B

Meanwhile, some sad beta testers are still without a sample. Still sort of encouraging. Must not jump ship to another chipset. Be strong.

haha ..



the nacked pcb it look like the same you posted as crowdfunding
( but such a coincidence also. )

wild_founds.jpg (82.2 KiB) Viewed 13978 times

btw:

they knew more details as we know here from espressif
daniel: ..We cannot reveal many more details because most of the info is still under NDA, ...

aha.. but we see the result:

wild_founds_1.jpg (50.49 KiB) Viewed 13976 times

the pcb is done - how they can do it?
the software is done, how they can do it?
where are they taken the new SDK ?
and docus?


and they ship out end july?

wild_founds_4.jpg (58.87 KiB) Viewed 13976 times

this is a unfair world

sheet happens
..

( well done! )

btw:
my oszi need +20 °C for working in beta with the beta skd because it was a bug

i want esp32 too


-hope you guys have one sample for me if i ask for it-


best wishes
rudi

[ESP_Sprite]

Please hold your horses, people (Not necessarily refering to this thread in particular, but there seem to be a lot of posts cropping up which encompass a certain sentiment.) I understand you are anxious for any and all information, and maybe think it's a bit weird that the Pycom people seem to have more than is publicly available. A lot of that is because they have been here and actually got an opportunity to ask questions, but I can assure you that there aren't many technical things they know that I can't also post here publicly. For example, how can they make the PCB is pretty simple: they know the ESP32 layout because we actually released that into the public and we do not go around changing that: you can also make your own PCB if you want. The software they have now works on the ESP31B and because we'll try to make efforts in keeping the SDK for the ESP32 as much backwards compatible as possible, they know they'll probably won't have to change much to get it working once they have the ESP32 silicon.

Honestly, we here at Espressif are as eager to get out hands on the silicon as you are, and we understand not having any datasheets or SDKs doesn't make your life easier, but please accept the fact that we're also working hard to get everything in order for a release, and that releasing stuff preliminary isn't always possible. I personally am always willing to throw the community a bone (as you may know, Espressif hired me when I still was a member of the community myself) and you can ask any questions here and I'll try my best to answer them, but some stuff just won't be done until august, and I don't think it's a good idea to release untested and/or buggy stuff preliminary, sorry.

[rudi ;-)]

Please hold your horses, people (Not necessarily refering to this thread in particular, but there seem to be a lot of posts cropping up which encompass a certain sentiment.) I understand you are anxious for any and all information, and maybe think it's a bit weird that the Pycom people seem to have more than is publicly available. A lot of that is because they have been here and actually got an opportunity to ask questions, but I can assure you that there aren't many technical things they know that I can't also post here publicly. For example, how can they make the PCB is pretty simple: they know the ESP32 layout because we actually released that into the public and we do not go around changing that: you can also make your own PCB if you want. The software they have now works on the ESP31B and because we'll try to make efforts in keeping the SDK for the ESP32 as much backwards compatible as possible, they know they'll probably won't have to change much to get it working once they have the ESP32 silicon.

Honestly, we here at Espressif are as eager to get out hands on the silicon as you are, and we understand not having any datasheets or SDKs doesn't make your life easier, but please accept the fact that we're also working hard to get everything in order for a release, and that releasing stuff preliminary isn't always possible. I personally am always willing to throw the community a bone (as you may know, Espressif hired me when I still was a member of the community myself) and you can ask any questions here and I'll try my best to answer them, but some stuff just won't be done until august, and I don't think it's a good idea to release untested and/or buggy stuff preliminary, sorry.

Espressif is simple the Best Team ever know, hear or seen - and we love it and they products!
The Team is the hardest working Team that we have ever know -
Espressif deserves the greatest recognition and awards.

I agree with some of you.

but why we are beta tester -
if we do not get "bugy software"?
we want to support you!

so we are "unemployed" and bored.

we see updates on the resource side (latest esp32 flash tool)
freely accessible. here in the forum (protected sdk) it is not updated.
why then protected?

we are a bit cut from the other information here
although this forum is the forum for the ESP32, should be.
and we wait in vain for more information.

nobody needs to wonder more,
when we here no longer grant informative,
what we know from our own try that we must do by 20° Celsius
i never heared from ESP_GREG again that he want replaced the Board... but is ok.
after 1/2 year i have got used to this warm air noise...

we can reverse many things - but the things is only for the "esp31"
and this is not the final chip and have no HW BLE. so we would happy
if we get at least the same info like Kickstarter, did we are at same level

if the product fails, because no information can provide
and that does not make the product bad, but the image on the esp32.
and we want to avoid precisely.


but once honestly:
Why brags Daniel with an NDA in the LoPy Campagne?
More attention? These are beginner and freeloaders, nothing more.
My personal opinion. Resepct to the Project itself - Respect to each project with ESP's -
because we love ESP..

Here stand and wait long existing industry companies, and their leaves are currently standing in the rain more as few month?!
Not every companie group makes itself known at the beginning, that's normal in the industry.
they have their "straw men" here, which can also lose their interest.
and that makes me worry large.

btw: PCB:
e.g.
The combined antenna design for Bluetooth and Wifi is thus freely accessible including BOM?

The 29 finished Lopy have no final ESP32?

The 12 beta testers do not anything with Bluetooth?

Since then apparently escaped me something ...
and my knowledge of the Beta Testa me then handed wrong? ..
..
..

sorry

holidays comes next week - so perhabs this is a good time for change.

btw:
here runs a fully CAN Master / Slave as Software Solution on ESP31!
Modbus Master / Slave is done too. without Docu and Info
same theme like ESP8266 I2C Slave,
and a little more on RF theme with DMA..

[WiFive]

Please hold your horses, people (Not necessarily refering to this thread in particular, but there seem to be a lot of posts cropping up which encompass a certain sentiment.) I understand you are anxious for any and all information, and maybe think it's a bit weird that the Pycom people seem to have more than is publicly available. A lot of that is because they have been here and actually got an opportunity to ask questions, but I can assure you that there aren't many technical things they know that I can't also post here publicly. For example, how can they make the PCB is pretty simple: they know the ESP32 layout because we actually released that into the public and we do not go around changing that: you can also make your own PCB if you want. The software they have now works on the ESP31B and because we'll try to make efforts in keeping the SDK for the ESP32 as much backwards compatible as possible, they know they'll probably won't have to change much to get it working once they have the ESP32 silicon.

Honestly, we here at Espressif are as eager to get out hands on the silicon as you are, and we understand not having any datasheets or SDKs doesn't make your life easier, but please accept the fact that we're also working hard to get everything in order for a release, and that releasing stuff preliminary isn't always possible. I personally am always willing to throw the community a bone (as you may know, Espressif hired me when I still was a member of the community myself) and you can ask any questions here and I'll try my best to answer them, but some stuff just won't be done until august, and I don't think it's a good idea to release untested and/or buggy stuff preliminary, sorry.

Thanks, sprite_tm for keeping us partially sane. I hate to be a whiner. Do we have full pinout for all peripheral functions?

[jmattsson]

@Sprite_tm: I have a slightly unrelated question for you. Currently many of us use custom boot loaders and over-the-air firmware upgrade methods, typically by mapping either the first or second meg via Cache_Read_Enable() so we can have slot-agnostic firmware. Will the ESP32 have a similar capability/interface for setting up the drom0/irom0 cache windows? I see there is indeed a Cache_Read_Enable() function, but I haven't had a chance to work out its signature.

[ESP_Sprite]

Rudi: Whoa, wall of text Yes, I understand that you guys, as beta testers, are willing to try anything and everything you can get your hands on.

First of all, sorry, when push comes to shove the Pycom people are going to be able to know a few things more than we can release on the forum. They have an NDA, meaning we can tell them stuff that is sensitive and we cannot tell here in public. Also important: if we tell them something or give them some documentation in person under NDA, we can fully qualify that we're not sure of things, that things may change, that maybe some of the features won't make it in the final chip. If we throw the same information in public, people (in general, not you I'm sure) are going to take that info, disregard the caveats and see it as gospel. That is never a good idea and can kill the release of something pretty badly, I'm afraid.

Add to that that releasing software or documentation costs time. References to internal servers and information need to be scrubbed, software has to be checked for dependencies on stuff we're never going to release, at least some documentation has to be added etc. The release needs to be supported in some way, otherwise people are going to complain we don't answer questions etc. In other words: we lose a lot of man power that we, in my humble opinion, are better off spending on getting you the best SDK and documentation we can as soon as the ESP32 becomes available.

Furthermore, the antenna for BT and WiFi is the same as a normal WiFi antenna (same frequency range) and sorry, I have no idea what chip on the '29 finished LoPy' you mentioned could be.

WiiFive: We can't give it, because you can map nearly all peripherial pins to nearly any GPIO pin. You can basically tell the hardware "I'd like my UART1 input to go to GPIO1, and my SPI CS0 to GPIO2." Some pins have a default function because they are used during the booting process (eg the uart and SPI ports have a set of default pins) but there's absolutely nothing stopping you from remapping it when the ESP32 has booted. (You may even be able to change the boot pins permanently using some efuses, but don't quote me on that... not sure how much of that functionality made it into the final ROM.)

jmattsson: Yes, you will actually have the ability to make each block in IROM/DROM (iirc a block = 256K) point to a certain position (in block-size increments) in flash. The ESP31 already has that functionality, actually, although it is undocumented: if you poke the PRO_CACHE_MAP registers, you can change that mapping. (Iirc MAP0 and MAP1 change the DROM mapping, the rest the IROM mapping. I'm not sure if these registers and configurations made it to the ESP32 in exactly this form, but be assured you'll have at least that functionality.

[WiFive]

WiiFive: We can't give it, because you can map nearly all peripherial pins to nearly any GPIO pin. You can basically tell the hardware "I'd like my UART1 input to go to GPIO1, and my SPI CS0 to GPIO2." Some pins have a default function because they are used during the booting process (eg the uart and SPI ports have a set of default pins) but there's absolutely nothing stopping you from remapping it when the ESP32 has booted. (You may even be able to change the boot pins permanently using some efuses, but don't quote me on that... not sure how much of that functionality made it into the final ROM.)

That is definitely great, but the "nearly" could be important. For example does that include Ethernet, CAN, DAC, ADC, touch peripherals?

[ESP_Sprite]

Let me look into that. CAN seems to be movable to any GPIO, the others I'm not 100% sure. I'll get back to you as soon as I've heard back from the HW team.

Edit: Okay, here's some information. Big fat warning in advance: This is a list extracted from a preliminary document that's still an unedited work-in-progress; we will release more detailed and edited information later. Feel free to look at this as an initial set of hints of what to expect, but don't make any decisions on it you can't change later. Because I know a fair few of you want to build PCBs in advance, I'll try and see if I can release at least the GPIO bit of the datasheet early on (that is, as soon as it's done, we're still writing it.). Also: some of the peripherals in this table are also are configurable by the GPIO mux, as mentioned before. If your favorite peripheral isn't mentioned in this list, you can assume that it's routed through the aforementioned GPIO mux as well.

Edit: Just heard we're also going to release this information in a more palatable form this or next week.

Code: Select all

Alternate functions for pins:
SENSOR_VP: ADC_H, ADC1_CH0, GPIO36 (input only)
SENSOR_CAPP: ADC_H, ADC1_CH1, GPIO37 (input only)
SENSOR_CAPN: ADC_H, ADC1_CH2, GPIO38 (input only)
SENSOR_VN: ADC_H, ADC1_CH3, GPIO39 (input only)
VDET_1: ADC1_CH6, GPIO34 (input only)
VDET_2: ADC1_CH7, GPIO35 (input only)
32K_XP: XTAL_32K_P, ADC1_CH4, TOUCH9, GPIO32
32K_XN: XTAL_32K_N, ADC1_CH5, TOUCH8, GPIO33
GPIO25: DAC_1, ADC2_CH8, GPIO25, EMAC_RXD0
GPIO26: DAC_2, ADC2_CH9, GPIO26, EMAC_RXD1
GPIO27: ADC2_CH7, TOUCH7, GPIO27, EMAC_RX_DV
MTMS: ADC2_CH6, TOUCH6, HSPICLK, GPIO14, HS2_CLK, SD_CLK, EMAC_TXD2
MTDI: ADC2_CH5, TOUCH5, HSPIQ, GPIO12, HS2_DATA2, SD_DATA2, EMAC_TXD3
MTCK: ADC2_CH4, TOUCH4, HSPID, GPIO13, HS2_DATA3, SD_DATA3, EMAC_RX_ER
MTDO: ADC2_CH3, TOUCH3, HSPICS0, GPIO15, HS2_CMD, SD_CMD, EMAC_RXD3
GPIO2: ADC2_CH2, TOUCH2, HSPIWP, GPIO2, HS2_DATA0, SD_DATA0
GPIO0: ADC2_CH1, TOUCH1, CLK_OUT1, GPIO0, EMAC_TX_CLK
GPIO4: ADC2_CH0, TOUCH0, HSPIHD, GPIO4, HS2_DATA1, SD_DATA1, EMAC_TX_ER
GPIO16: GPIO16, HS1_DATA4, U2RXD, EMAC_CLK_OUT
GPIO17: GPIO17, HS1_DATA5, U2TXD, EMAC_CLK_OUT_180
SD_DATA_2: SPIHD, GPIO9, HS1_DATA2, U1RXD
SD_DATA_3: SPIWP, GPIO10, HS1_DATA3, U1TXD
SD_CMD: SPICS0, GPIO11, HS1_CMD, U1RTS
SD_CLK: SPICLK, GPIO6, HS1_CLK, U1CTS
SD_DATA_0: SPIQ, GPIO7, HS1_DATA0, U2RTS
SD_DATA_1: SPID, GPIO8, HS1_DATA1, U2CTS
GPIO5: VSPICS0, GPIO5, HS1_DATA6, EMAC_RX_CLK
GPIO18: VSPICLK, GPIO18, HS1_DATA7
GPIO23: VSPID, GPIO23, HS1_STROBE
GPIO19: VSPIQ, GPIO19, U0CTS, EMAC_TXD0
GPIO22: VSPIWP, GPIO22, U0RTS, EMAC_TXD1
U0RXD: CLK_OUT2, GPIO3
U0TXD: CLK_OUT3, GPIO1, EMAC_RXD2
GPIO21: VSPIHD, GPIO21, EMAC_TX_EN

QFN-48 Pinout (pin:name)
1:VDDA_RX
2:LNA_IN
3:VDD3P3_PA
4:VDD3P3_PA
5:SENSOR_VP
6:SENSOR_CAPP
7:SENSOR_CAPN
8:SENSOR_VN
9:CHIP_PU
10:VDET_1
11:VDET_2
12:32K_XP
13:32K_XN
14:GPIO25
15:GPIO26
16:GPIO27
17:MTMS
18:MTDI
19:VDD3P3_RTC
20:MTCK
21:MTDO
22:GPIO2
23:GPIO0
24:GPIO4
25:GPIO16
26:VDD_SDIO
27:GPIO17
28:SD_DATA_2
29:SD_DATA_3
30:SD_CMD
31:SD_CLK
32:SD_DATA_0
33:SD_DATA_1
34:GPIO5
35:GPIO18
36:GPIO23
37:VDD3P3_CPU
38:GPIO19
39:GPIO22
40:U0RXD
41:U0TXD
42:GPIO21
43:VDDA
44:XTAL_N
45:XTAL_P
46:VDDD_XTAL_PLL
47:CAP2
48:CAP1

[rudi ;-)]

Let me look into that. CAN seems to be movable to any GPIO, the others I'm not 100% sure. I'll get back to you as soon as I've heard back from the HW team.

Edit: Okay, here's some information. Big fat warning in advance: This is a list extracted from a preliminary document that's still an unedited work-in-progress; we will release more detailed and edited information later. Feel free to look at this as an initial set of hints of what to expect, but don't make any decisions on it you can't change later. Because I know a fair few of you want to build PCBs in advance, I'll try and see if I can release at least the GPIO bit of the datasheet early on (that is, as soon as it's done, we're still writing it.). Also: some of the peripherals in this table are also are configurable by the GPIO mux, as mentioned before. If your favorite peripheral isn't mentioned in this list, you can assume that it's routed through the aforementioned GPIO mux as well.

Edit: Just heard we're also going to release this information in a more palatable form this or next week.

Code: Select all

Alternate functions for pins:
SENSOR_VP: ADC_H, ADC1_CH0, GPIO36 (input only)
SENSOR_CAPP: ADC_H, ADC1_CH1, GPIO37 (input only)
SENSOR_CAPN: ADC_H, ADC1_CH2, GPIO38 (input only)
SENSOR_VN: ADC_H, ADC1_CH3, GPIO39 (input only)
VDET_1: ADC1_CH6, GPIO34 (input only)
VDET_2: ADC1_CH7, GPIO35 (input only)
32K_XP: XTAL_32K_P, ADC1_CH4, TOUCH9, GPIO32
32K_XN: XTAL_32K_N, ADC1_CH5, TOUCH8, GPIO33
GPIO25: DAC_1, ADC2_CH8, GPIO25, EMAC_RXD0
GPIO26: DAC_2, ADC2_CH9, GPIO26, EMAC_RXD1
GPIO27: ADC2_CH7, TOUCH7, GPIO27, EMAC_RX_DV
MTMS: ADC2_CH6, TOUCH6, HSPICLK, GPIO14, HS2_CLK, SD_CLK, EMAC_TXD2
MTDI: ADC2_CH5, TOUCH5, HSPIQ, GPIO12, HS2_DATA2, SD_DATA2, EMAC_TXD3
MTCK: ADC2_CH4, TOUCH4, HSPID, GPIO13, HS2_DATA3, SD_DATA3, EMAC_RX_ER
MTDO: ADC2_CH3, TOUCH3, HSPICS0, GPIO15, HS2_CMD, SD_CMD, EMAC_RXD3
GPIO2: ADC2_CH2, TOUCH2, HSPIWP, GPIO2, HS2_DATA0, SD_DATA0
GPIO0: ADC2_CH1, TOUCH1, CLK_OUT1, GPIO0, EMAC_TX_CLK
GPIO4: ADC2_CH0, TOUCH0, HSPIHD, GPIO4, HS2_DATA1, SD_DATA1, EMAC_TX_ER
GPIO16: GPIO16, HS1_DATA4, U2RXD, EMAC_CLK_OUT
GPIO17: GPIO17, HS1_DATA5, U2TXD, EMAC_CLK_OUT_180
SD_DATA_2: SPIHD, GPIO9, HS1_DATA2, U1RXD
SD_DATA_3: SPIWP, GPIO10, HS1_DATA3, U1TXD
SD_CMD: SPICS0, GPIO11, HS1_CMD, U1RTS
SD_CLK: SPICLK, GPIO6, HS1_CLK, U1CTS
SD_DATA_0: SPIQ, GPIO7, HS1_DATA0, U2RTS
SD_DATA_1: SPID, GPIO8, HS1_DATA1, U2CTS
GPIO5: VSPICS0, GPIO5, HS1_DATA6, EMAC_RX_CLK
GPIO18: VSPICLK, GPIO18, HS1_DATA7
GPIO23: VSPID, GPIO23, HS1_STROBE
GPIO19: VSPIQ, GPIO19, U0CTS, EMAC_TXD0
GPIO22: VSPIWP, GPIO22, U0RTS, EMAC_TXD1
U0RXD: CLK_OUT2, GPIO3
U0TXD: CLK_OUT3, GPIO1, EMAC_RXD2
GPIO21: VSPIHD, GPIO21, EMAC_TX_EN

QFN-48 Pinout (pin:name)
1:VDDA_RX
2:LNA_IN
3:VDD3P3_PA
4:VDD3P3_PA
5:SENSOR_VP
6:SENSOR_CAPP
7:SENSOR_CAPN
8:SENSOR_VN
9:CHIP_PU
10:VDET_1
11:VDET_2
12:32K_XP
13:32K_XN
14:GPIO25
15:GPIO26
16:GPIO27
17:MTMS
18:MTDI
19:VDD3P3_RTC
20:MTCK
21:MTDO
22:GPIO2
23:GPIO0
24:GPIO4
25:GPIO16
26:VDD_SDIO
27:GPIO17
28:SD_DATA_2
29:SD_DATA_3
30:SD_CMD
31:SD_CLK
32:SD_DATA_0
33:SD_DATA_1
34:GPIO5
35:GPIO18
36:GPIO23
37:VDD3P3_CPU
38:GPIO19
39:GPIO22
40:U0RXD
41:U0TXD
42:GPIO21
43:VDDA
44:XTAL_N
45:XTAL_P
46:VDDD_XTAL_PLL
47:CAP2
48:CAP1

even bang on the table and here we go.



thanks for your effort and restraining words.
I do not like nagging from me too.

see you!


best wishes
rudi

Edit: Just heard we're also going to release this information in a more palatable form this or next week.

thats great!
thank you!