Hi,
-The external wifi antenna is the best option. I also agree that wired
ethernet is essential and preferred in an industrial application. So
thats fine.
-SD cards are very unreliable and to achieve their goal (be usable on
desktop computers), they have to use FAT filesystems, which are
EXTREMELY NOT reliable in case of surprise power loss, which is an
unavoidable design constraint in an embedded system, so I disagree with
you on the choice of a SD card, because this does not match the level of
reliability you seem to intend with the rest of this board (which is
really well done).
ISSI now has some large fast and available flash chips with 4KB erase
blocks.
Which are VERY RELIABLE and very well managed by LittleFS regarding to
wear leveling, with atomic/or replayable filesystem operations. I insist
a lot, mass storage reliability in embedded devices is CRITICAL and very
OVERLOOKED. I am a smart card engineer, and we constantly have to deal
with half-erased data bits, undefined and unstable bits that can change
every time you read them, duration and energy required for correct page
erases, etc. So even if a "normal" embedded system does not need to deal
with this, at least a reliable flash storage is a must, IMHO. With a
large cap on the power rail to finish the current write, and ideally a
powerok GPIO to disable further flash writes in case of power failure.
I could understand that reliable storage is not in your scope, but the
rest of the board seems to be reliable, so thats a surprise. A broken
out SPI+power and a few /CS lines from the ESP32 could be a solution on
a crowded board, so that spi flash storage can be added as an optional
daugter board.
Yes, this board would be cool to test. Times having changed, we could
even use that kind of esp32+rp2040 system in future products.
Sebastien
Le 26/10/2022 à 11:39, michael.sch...@mdc-service.de a écrit :
Hello Sebastian,
thanks for your interest! About the Wifi antenna: The used
ESP32-WROVER-I has the wifi signal connected to the uFL connector by
default, the PCB antenna would request to solder a 0 Ohm resistor, to
use it. Because of the space limitations, we drop the idea to use the
PCB antenna. In our use cases, the EsPiFF is build into a metal
enclosure, what makes the useage of an PCB antenna impossible. As the
EsPiFF is optimized for high availability applications, the wired
Ethernet also prefered over Wifi. Because the PCB antenna is not used,
the placement close to the IO header is no problem.
It would be great, if there where smaller ESP32 modules, with 16 MB of
flash and 8 MB of PSRAM available. But unfortunatly, the smaller ESP32
modules does not have 8 MB PSRAM, and we see this as a killer feature
of the ESP32.
About data logging: There is the SDcard socket, and this is the
prefered way for data logging. Otherwise, the 16MB flash on the ESP32
could be used as well, but frequent writing on the flash limit its
live time. Nuttx have special flash files systems, to minimize this
problem, but with the SDcard available, I would prefer this. Finally,
all pins from the 40 pol header go to he RP2040, so a RasPi HAT can
add any functionality.
About FRAM: the initial idea was, to mount the FRAM into the malloc()
address range, as a fast non-volatile memory. After a power cut, a
program could continue where it was stopping before. The FRAM is byte
adressable, and with 20MHz not so slow. Footprint and protocol
compatible FRAMs are offered in various sizes, up to 256 kBytes. If
needed, we could offer a version with more FRAM, what would then cost
a little more. By also having the SDcard, what size for the FRAM would
you choose?
We will make a board revsion with JTAG headers. I will update you as
soon as we have it.
regards,
Michael
Am 2022-10-26 10:44, schrieb Sebastien Lorquet:
Hi,
A devboard with no jtag makes no sense for me! When you have a hw
revision with both the esp32 and the rp2040 debug ports broken out on
HE10-1.27mm headers (or pads if space is tight), I'm interested to get
one :)
The internal wifi antenna close to the IO header metal pins is also
not RF-optimal. Your version 2 was better on this aspect.
Also another suggestion, a large user flash available on esp32 or
rp2040 spi gpios would be very useful for data logging and storage.
Using the esp32 code flash for this is not the best design. The 2KB
fram is good for parameter storage but is quite limited, no useful FS
can be mounted on it.
Best regards,
Sébastien
Le 26/10/2022 à 08:57, michael.sch...@mdc-service.de a écrit :
Dear Nuttx developers,
we have developed the EsPiff (ESP32+RP2040 on the Raspberry Pi Form
Factor), a open source board to replace RasPi's and there clones,
where the high processing power and/or Linux is not needed, but
stability and the reuse of RasPi HATs are required.
The github home is https://github.com/MDCservice/EsPiFF
We will also offer the EsPiFF on CrowdSupply
https://www.crowdsupply.com/mdc-service-wittenburg-gmbh/espiff
We would like to send a few boards for free to Nuttx developers, to
improve Nuttx compatibility. Would there be interest?
A high level summary about the EsPiFF:
An ESP32-WROVER-I module with 16 MB Flash, 8 MB PSRAM is taking care
- wired Ethernet via a IP101 PHY,
- Wifi (need an external Wifi Antenna with uFL connector),
- 3 serial UARTs,
- one the 3 serial UARTs is used for programming via a CH340
USB-UART chip, what can be enabled/disabled with jumpers,
- I2C port expander PCA 9557 for some chip select signals and 3 user
LEDs,
- SDcard in SPI mode,
- external real time clock, with supervisior,
- 2kB FRAM,
- USB Type-C connector for up to 5V/3A, connected to the CH340
USB-UART to program the ESP32
An RP2040 (Pi Pico) what takes care the 40 pin RasPi header,
- connected to the ESP32 via SPI,
- UAB-A connector, also used to program the RP2040 (need to hold the
boot button while power the board).
In earlier versions, we had the LAN8720 PHY, but as others (Olimex,
wESP) we also got problems and replaced it with the IP101 since v3.1.
Currently, there is no HW debugging broken out on the board. But we
could add a JTAG header on the bottom side, with TDO, TDI, TCK, TMS,
GND, 3V3 in the next board production run. The ESP32 has the JTAG
pins on GPIO12, 13, 14, 15, what are used for SPI on the EsPiFF, so
code using the SPI could not be debugged while JTAG is using the
pins. Would it still make sense to build in the JTAG header?
Would be glad to get your feedback,
Michael
