Like to get more details specific to this module answered here.
Can the ESP32 be clocked to the 240MHZ, or is it fixed to the 160MHZ ?
2 Likes
I don't have an officical answer but from the FAQ:
ESP32-S0WD is a single core variant of the very popular ESP32, and is better supported than the ESP8285 with a fully open source developer SDK
which sounds like you can possibly do that by building locally.
Building locally I know we can change it, I just don’t know if Particle crated a hook or a setting to allow us to change it within their software. You can do this with PlatforIO by simply adding:
; set frequency to 160MHz
;board_f_cpu = 160000000L
board_f_cpu = 240000000L
Hey there @seulater – we’re using the ESP32-S0WD as a network co-processor for the Argon, so it’s not intended to run the primary user application. As such, we may not expose the same level of user APIs for controlling the coprocessor as the primary Nordic MCU.
We haven’t completed software development for the new hardware though, so we’re open to feedback on features you’d like to see made available at the Particle API level.
5 Likes
Thanks, that answers all of my questions. Appreciate it.
Honestly, if the ESP32 is not the primary for user application I don’t see a need for me. 64MHz, is just not going to cut it. I’d be better off sticking with the Photon @120Mhz. The issue for me moving to the ESP32 is that I have outgrown my user flash space for the Photon, and needed a faster platform for updating LCD’s.
I have a 7" capcitive touch with the Photon now, and just wanted faster LCD updates. This same product with the ESP32 Dual core, makes this happen. Where this all sucks, is that I cannot use the Particle platform which I have come to love. So for now I have to stick with the crappy platform that supports ESP32. 
5 Likes
Sorry we couldn’t deliver exactly what you were looking for, @seulater. It’s also worth mentioning that we’re adding an additional 2MB of on-board flash in addition to the 1MB on the nRF52840 that will be user accessible, but I understand that this does not solve all the problems you cited.
We’re enthusiastic about the Espressif hardware platform and are excited to add Espressif hardware to the Argon. I hope we’re able to satisfy your project requirements and get you back on the platform sometime soon!
5 Likes
You could just use 4D systems displays that handle all their own processing vs loading it off on your main CPU. I already know your going to tell me the 4D systems displays cost to much though 
3 Likes
Bingo! you know me too well 
We also know you’ve heard about Nextion displays (not as powerful but cheaper) before, but trading the display choice against a platform decission is a “tough” one 
thanks guys for the suggestions, but its more than just the display, which the 7" capacitive LCD is only costing me $18.95 in singles. Its the Dual core, 240MHZ, up to 32MB flash, and up to 16MB ram.
Looking at the GPIO specifics…
How many of the GPIO pins can be specifically used for analog I/O? Is it similar to the Photon where there are actually 8 analog I/O pins or is there only a total of 6 analog pins for the Argon?
Right, just wanted to confirm that only 6 of the total pins can be used for analog control. On the Photon pinout, the 2nd SPI port is located on the analog pins. I thought maybe on the Argon, some of the other peripherals could be used as analog
On the Feather pinout SPI and analog are usually seperated already, and IIRC there is only one SPI on the Gen3 devices.
But the full docs for these devices are still under construction - something else to wait for
1 Like
I’m looking forward to hearing more about the BLE module API that will be available for Argon, specifically if development of user firmware that connect to 3rd-party peripherals will be available upon release. Anyone know if the new generation of hardware will support BLE central?
Why? Why have the processor that is superior in every way as far as I can tell, just sit there an run the mesh? Seems like most of the MIPS on the board are being wasted. Not having studied these SOCs in great detail I may be missing the reason here. But maybe you can tell us why this design?
I could be wrong, but I think they are using the ESP32 just for WiFi.
Happy to!
There were a number of considerations that resulted in this design:
1. Standardized architecture. One of the primary features of mesh networks are that individual devices can act as both the “end product” and the “mesh infrastructure” at the same time. In other words, a device that is acting as a border router in a network can also run the same Particle app that collects temperature information and reports it to the cloud. Functionally, it means that you can design a base board and add the Argon, Boron, or Xenon interchangeably depending on the needs of your network.
Because of this, we wanted to ensure that each device had a standard host controller that provided a common set of peripherals available to product creators as well as a common Device OS implementation that provided a consistent development experience across the three new products.
Those requirements made it necessary to employ use of a network co-processor architecture in order to provide Mesh, Wi-Fi + Mesh, and Cellular + Mesh combos with a consistent developer experience.
2. Nordic nRF52840 as the host. Because we wanted 15.4/BT on each and every part (including the Xenon, which has no additional radios), it made sense to use the Nordic part as the host processor in the architecture described above. Additionally, the Nordic part has some awesome features that make it a meaningful improvement over the STM32F205, which we currently use for the Photon and Electron:
- 1MB flash on board (same as Photon/Electron)
- QSPI support, which means we can (and did) add external flash (2MB) that should be able to support external in-place code execution, making the effective flash on board each device 3MB
- 256Kb RAM, double that of the STM32F205
- Improved hardware security via accelerated hardware cryptography and CryptoCell from ARM
- FPU support for accelerated operations
Additionally, we believe that Nordic, as the industry leader in Bluetooth, is poised to become the industry leader in 15.4 with the nRF52840 – we’ve seen broad adoption of the part within industry and their software support is best-in-class.
3. Wi-Fi radio selection. The final question to answer was what part to select to add Wi-Fi support to the Argon. The requirements of the part were simple – run some basic AT command firmware and respond to networking calls from the Nordic host processor.
After evaluating all of the modern Wi-Fi chipsets in industry, we concluded that Espressif provided the best mix of performance and value. We actually initially targeted the ESP8266 (that’s the chip that’s in the product photos) but decided to switch to their new single core ESP32 chip (ESP32-S0WD) because it’s their newer hardware design and is supported by an entirely open-source SDK, which we love. Despite the higher cost, we were able to maintain a low retail price to developers ($15 during pre-order).
As a consequence, there are features that are available on the ESP32 that are not exposed or are redundant with the Nordic nRF52840 (like Bluetooth). Even so, Espressif hardware is more affordable than most (every?) other Wi-Fi only chipsets on the market, and we wanted to start investing and contributing to that ecosystem which is driving a lot of the innovation and excitement within the semiconductor industry today.
Hope that helps.
9 Likes
Excellent!
Excellent!
1 Like
Hi Will,
Thanks for that great information. These improvements over the STM32F205 are all excellent, and I plan to take advantage of them. However it is a bit disappointing that the clock speed will be half. I read that the Nordic has single precision floating point hardware support. Is it your plan that the compiler will take advantage of that? If so, then I think my speed concerns will be alleviated, as my application runs up against software floating point slowness more than it does raw clock speed.
- Rich