You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by mi...@mdc-service.de on 2022/10/26 06:57:28 UTC
Dev-Board for Nuttx
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
Re: Dev-Board for Nuttx
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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.schmid@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.schmid@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
>
Re: Dev-Board for Nuttx
Posted by mi...@mdc-service.de.
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.schmid@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
--
Chief engineer & consultant
MDC-Service Wittenburg GmbH
Bergstiftsgasse 11
09599 Freiberg, Germany
Office Gen. +49 3731 7832310
Fax +49 3731 2442369
Re: Dev-Board for Nuttx
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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.schmid@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
libpq and libscpi: how to start
Posted by mi...@mdc-service.de.
Dear all,
i would like to see Nuttx support for the PostgreSQL client library
libpq(https://github.com/postgres/postgres/tree/master/src/interfaces/libpq),
and a library for SCPI(https://www.jaybee.cz/scpi-parser/api/). These
scpi parser lib could then be used for USBTMC and LXI, 2 standards to
expose lab instruments in a standardized way to software like LabView,
GNU Octave, ect.
Both projects are under BSD license, so they should be compatible from
the license side with Nuttx.
I think, as common libraries for other app, and maybe service, they
should be placed under nuttxspace/nuttx/libs in the Nuttx tree, not in
the application tree. At least the PostgreSQL client library requires
network. What would be the advice, where to place these kind of
libraries?
For the PostgreSQL client library, there are implementations for
Arudino, additional to the PC based implementations. But because the
POSIX compatibility of Nuttx, starting from the Linux version should
make more sense, or?
regards,
Michael
Re: Dev-Board for Nuttx
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Michael,
Yes, this is the way to go!
Actually NuttX already supports loading ELF from SDCard or USB Thumb
Driver (called "pendrive" in some countries).
I created a video demonstrating it, see here:
https://www.youtube.com/watch?v=oL6KAgkTb8M
Also there is a PR in progress that will extend the ELF loading to
enable loading libraries:
https://github.com/apache/incubator-nuttx/pull/7202
About the JTAG, I think it should be nice to have an standard
connector, but of course it uses a lot of space in the board.
BR,
Alan
On 10/26/22, michael.schmid@mdc-service.de
<mi...@mdc-service.de> wrote:
> Hi Alan,
>
> I am really happy to got your interest. Replacing the Pi with an EsPiFF
> with Nuttx is also our intention.
>
> The SWD for the RP2040 is alredy broken out, on J5, pin 6(SWCLK) and pin
> 8 (SWDIO). The connector J5 is a DF11, 2mm spacing connector, we will
> add cables with 2.54 Duponts on the other side. The RP2040 have
> exclusive pins for SWD, so no limit on functionality. Just for the
> ESP32, we need to add the JTAG header. We used that DF11 connector, to
> make these pins accesable from outside, when the EsPiFf is in a
> Raspberry Pi 4 enclosure, what have 2 mini HDMI connectors at this
> position. Other connectors would be too big for the openings for mini
> HDMI.
>
> In the past, I did also STM32 boards, until the chip crisis made most of
> the STM32Fxxx unavailable. This is the big advantage of the ESP32, they
> are always available. I have not yet jumped on the GD32xxx and friends
> as pincompatible? replacement, that could be an way out. But 8 MB RAM on
> a board, means for most MCUs external RAM, whats included with the
> ESP32-WROVER. I am hoping, that (one day) to load ELF binaries from
> SDcard into memory and execute it, as Linux is doing. This will open a
> new chapter in using microcontrollers, and Nuttx is already nearly
> there.
>
> Would be happy to see the EsPiFF one day in your Nuttx Videos!
>
> best regards,
> Michael
>
> Am 2022-10-26 14:56, schrieb Alan C. Assis:
>> Hi Michael,
>>
>> Congratulations! You created a really great board!!!
>>
>> I'm sure that many people here will be interested on it, those who are
>> really interested to contribute.
>>
>> The idea of using RPI form-factor is really good. Actually we were
>> discussing about the idea of creating some RPI-like board to replace
>> high level Linux system with a system running NuttX RTOS.
>>
>> I think adding JTAG for ESP32 and SWD for RP2040 will be very useful,
>> please include it for the final board.
>>
>> A friend of mine created a nice and simple board for NuttX that he
>> released as open-source:
>>
>> https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard
>>
>> He send me some pictures that I put on my flickr:
>>
>> https://live.staticflickr.com/65535/52456145643_97eca8e9b1_o.jpg
>>
>> https://live.staticflickr.com/65535/52455885674_94eba29fcc_b.jpg
>>
>> Soon, he will submit support to mainline.
>>
>> BR,
>>
>> Alan
>>
>> On 10/26/22, michael.schmid@mdc-service.de
>> <mi...@mdc-service.de> wrote:
>>> 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
>>>
>
> --
> Chief engineer & consultant
> MDC-Service Wittenburg GmbH
> Bergstiftsgasse 11
> 09599 Freiberg, Germany
>
> Office Gen. +49 3731 7832310
> Fax +49 3731 2442369
>
Re: Dev-Board for Nuttx
Posted by mi...@mdc-service.de.
Hi Alan,
I am really happy to got your interest. Replacing the Pi with an EsPiFF
with Nuttx is also our intention.
The SWD for the RP2040 is alredy broken out, on J5, pin 6(SWCLK) and pin
8 (SWDIO). The connector J5 is a DF11, 2mm spacing connector, we will
add cables with 2.54 Duponts on the other side. The RP2040 have
exclusive pins for SWD, so no limit on functionality. Just for the
ESP32, we need to add the JTAG header. We used that DF11 connector, to
make these pins accesable from outside, when the EsPiFf is in a
Raspberry Pi 4 enclosure, what have 2 mini HDMI connectors at this
position. Other connectors would be too big for the openings for mini
HDMI.
In the past, I did also STM32 boards, until the chip crisis made most of
the STM32Fxxx unavailable. This is the big advantage of the ESP32, they
are always available. I have not yet jumped on the GD32xxx and friends
as pincompatible? replacement, that could be an way out. But 8 MB RAM on
a board, means for most MCUs external RAM, whats included with the
ESP32-WROVER. I am hoping, that (one day) to load ELF binaries from
SDcard into memory and execute it, as Linux is doing. This will open a
new chapter in using microcontrollers, and Nuttx is already nearly
there.
Would be happy to see the EsPiFF one day in your Nuttx Videos!
best regards,
Michael
Am 2022-10-26 14:56, schrieb Alan C. Assis:
> Hi Michael,
>
> Congratulations! You created a really great board!!!
>
> I'm sure that many people here will be interested on it, those who are
> really interested to contribute.
>
> The idea of using RPI form-factor is really good. Actually we were
> discussing about the idea of creating some RPI-like board to replace
> high level Linux system with a system running NuttX RTOS.
>
> I think adding JTAG for ESP32 and SWD for RP2040 will be very useful,
> please include it for the final board.
>
> A friend of mine created a nice and simple board for NuttX that he
> released as open-source:
>
> https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard
>
> He send me some pictures that I put on my flickr:
>
> https://live.staticflickr.com/65535/52456145643_97eca8e9b1_o.jpg
>
> https://live.staticflickr.com/65535/52455885674_94eba29fcc_b.jpg
>
> Soon, he will submit support to mainline.
>
> BR,
>
> Alan
>
> On 10/26/22, michael.schmid@mdc-service.de
> <mi...@mdc-service.de> wrote:
>> 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
>>
--
Chief engineer & consultant
MDC-Service Wittenburg GmbH
Bergstiftsgasse 11
09599 Freiberg, Germany
Office Gen. +49 3731 7832310
Fax +49 3731 2442369
Re: Dev-Board for Nuttx
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Michael,
Congratulations! You created a really great board!!!
I'm sure that many people here will be interested on it, those who are
really interested to contribute.
The idea of using RPI form-factor is really good. Actually we were
discussing about the idea of creating some RPI-like board to replace
high level Linux system with a system running NuttX RTOS.
I think adding JTAG for ESP32 and SWD for RP2040 will be very useful,
please include it for the final board.
A friend of mine created a nice and simple board for NuttX that he
released as open-source:
https://github.com/lucaszampar/NuttX_STM32F4_RS485_DevBoard
He send me some pictures that I put on my flickr:
https://live.staticflickr.com/65535/52456145643_97eca8e9b1_o.jpg
https://live.staticflickr.com/65535/52455885674_94eba29fcc_b.jpg
Soon, he will submit support to mainline.
BR,
Alan
On 10/26/22, michael.schmid@mdc-service.de
<mi...@mdc-service.de> wrote:
> 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
>