Twice this year the E0 module for north America has been out of stock. The lead time is now 12-16 weeks for wholesale buyers. Yikes! I have requested a response from Particle sales, but get no response.
What is the future of the E0 module? It has the highest temperature specification of any of the Particle products, and many features that modules like the B523 do not have.
I have developed a product around the E0 module. Since they are not available through Particle.io, I purchased all of Mouser’s inventory (50 of them). But I am concerned that this product is not important to Particle.io, or it would not have that long of a lead time. Can someone tell me what is going on?
Which E Series model, the E310 or the E402? In any case, neither module is being discontinued and there is just a shortage of devices right now. Thousands of units are scheduled to be manufactured between now and October, so they should become regularly available again.
Can software (application code) developed for the E0 be ported easily over to the B523? Of course, all pin and signal names would have to be changed, but does the B523 have similar timers, and a sleep mode like the E0? Does the B523 have a wake up pin available? Also, after reviewing the data sheet for the B523, I am puzzled by all the “reserved” I/O. What does particle expect the product life cycle for the B523 is? If the product life cycle for the B523 is seven years, then I want to use these reserved pins and see what happens in the future.
There are a few fewer I/O pins on the B series than the E series. In particular, the B and C pins on the E series don’t exist, but there are higher numbered D pins on the B series.
In a given model, say the B523, you can use all of the reserved I/O pins. The reason they are reserved is if we made a completely different SoM device with a different MCU, we’ll only guarantee certain IO pins will be the same across all devices. They’re reserved across multiple models, not reserved for future other uses on the same module.
For example, all of the nRF52840 GPIO pins are the same across the B402 and B523, since they have the same MCU. But there are a few SOM-specific pins that vary because they have different cellular modems (u-blox vs. Quectel).
Hardware timers are vastly different between the STM32 and nRF52, and that can potentially be an issue. The software timers (Timer class) are the same.
Again, thank you for your quick response. I am trying to compare the two products, the E0 and the B523 for our industrial product, considering the future. Does the B523 have a wake up pin to bring it out of sleep mode? Our product uses the E0 sleep mode. I can get just enough I/O out of the B523 for our product to function on it from a signal perspective, but other than changing the signals (pins) should the software run the same? I don’t want to invest in a whole new software at this time, since I contract out much of our software programming.
We have the software working on the E0 perfectly right now and the software works perfectly with all of our hardware. Our product presently uses the E0, and a BlueGiga Blue tooth module communicating with an Android cell phone app along with a variety of other industrial components. I am thinking about the B523 because it has the cell phone module built in. This could simplify our manufacturing. However the B523 does not have the power management hardware mounted on the module. This would add complexity to our present design.
We developed our product on the Electron module, but we found that in the field, temperatures exceeded the Electron’s max, so we were forced to redesign using the E0 which has a higher top end temperature limit (167 degrees F). We will target the oil well market for the little oil wells scattered around the country, and the hazardous waste industry also.
The E0 module does everything I want it to do, but I really prefer a module that plugs into a connector rather than is soldered to the board. Our industrial product circuit board is not a throw away product. If the E0 fails, that would be a problem.
Our customer is also interested in the Particle Asset Tracker. I see that it uses the same MCU as the B523. On the T523 developer’s board, I see that many pins are not brought out from the MCU on the T523. Are they really not connected? It seems strange that the pin numbers have been brought out to the edge of the T523 module but they are labeled No connection. Why did they go to the trouble to bring these unused pins out to the edge of the module and use the board space to put them there? Could these MCU pins (signals) still be accessed?
Thank you again for your support. I am a serious Particle user. I work in Missouri, but went to Spectra 2018 in San Francisco, and I was working on a mesh product and used the Zenon and Boron modules for that application. That product has been set aside for now.
Does the B523 have a wake up pin to bring it out of sleep mode?
Yes. Actually the Gen 3 devices are more flexible with wake. Gen 2 (Photon/Electron/E Series) can only wake out of SLEEP_MODE_DEEP with WKP but Gen 3 can wake from any pin.
If you have simple GPIO needs, adding an I2C GPIO expander like the MCP23008 or MCP23017 is a good option.
However the B523 does not have the power management hardware mounted on the module. This would add complexity to our present design.
True, however as long are you are already manufacturing a board, adding the bq24195 PMIC and MAX17043 fuel gauge is not particularly difficult. There's an example in an app note.
Our customer is also interested in the Particle Asset Tracker. I see that it uses the same MCU as the B523. On the T523 developer’s board, I see that many pins are not brought out from the MCU on the T523. Are they really not connected?
There are only a small number of exposed GPIO on the Tracker SoM, A0-A7, D8, D9. The reason is that there are a huge number of peripherals on the Tracker SoM itself. All of the rest of the nRF52 GPIO and more (there's an I/O expander and a SPI CS decoder as well) are used by the numerous peripheral chips on the Tracker SoM itself.