Few months ago I found out that a dude created a hard wallet using raspberry pi zero and trezor wallet firmware (which is available for free) and I noticed this:
"Features: Use the original trezor One code. Only a thin layer is used to adapt the code to the raspberry pi Linux platform. "
As you can see, it uses the original trezor firmware with a slight modification.
What I also noticed is that the ESP32 and SMT32 meets the system requirements for building a hardwallet, specially because the Trezor Wallet is made using the STM32.
Technical specification
Processor ARM Cortex-M3 processor @ 120 MHz embedded on STM32 F2 microcontroller
Screen 128x64 px OLED display (UG-2864HSWEG01)
Connectivity Micro USB connector (type B)
I thought about buying a STM32, but it seemed to me that the ESP32 is be better in some aspects, specially because it has two cores, so I bought.
Yes, I'm wondering how to build a Trezor Wallet using the ESP32, since it's possible to build one using a STM32, but this is the very first time that I'm working with MCUs. For starters, how should I proceed?
ESP32 and Trezor firmware
Re: ESP32 and Trezor firmware
You did not post a link to your source material including code base!
List all the hardware interfaces you have; display, usb, wifi, ble etc.
Be careful though, you must break features (Display) down into acceptable interfaces. How do you achieve 'Display'? (SPI would be one way but there are others).
With MCUs the problem is that not all MCUs will have the hardware interfaces that you need.
An ESP32 will not do USB (not without a fight anyway).
There are ESP chips that will USB but then you might loose some other feature. You only have so many pins and so much RAM etc.
Once you have found your chip then now you can research how to achieve each feature in code.
The worked examples usually help there.
List all the hardware interfaces you have; display, usb, wifi, ble etc.
Be careful though, you must break features (Display) down into acceptable interfaces. How do you achieve 'Display'? (SPI would be one way but there are others).
With MCUs the problem is that not all MCUs will have the hardware interfaces that you need.
An ESP32 will not do USB (not without a fight anyway).
There are ESP chips that will USB but then you might loose some other feature. You only have so many pins and so much RAM etc.
Once you have found your chip then now you can research how to achieve each feature in code.
The worked examples usually help there.
& I also believe that IDF CAN should be fixed.
Re: ESP32 and Trezor firmware
I didn't post any examples cause I feared it might be considered spam.PeterR wrote: ↑Tue May 18, 2021 6:02 pmYou did not post a link to your source material including code base!
List all the hardware interfaces you have; display, usb, wifi, ble etc.
Be careful though, you must break features (Display) down into acceptable interfaces. How do you achieve 'Display'? (SPI would be one way but there are others).
With MCUs the problem is that not all MCUs will have the hardware interfaces that you need.
An ESP32 will not do USB (not without a fight anyway).
There are ESP chips that will USB but then you might loose some other feature. You only have so many pins and so much RAM etc.
Once you have found your chip then now you can research how to achieve each feature in code.
The worked examples usually help there.
This is the project using raspberry pi zero: https://www.pitrezor.com/2018/02/pitrez ... allet.html
This is device that is being copied using the raspberry pi zero: https://trezor.io
It's a cryptocurrency cold wallet.
This is the cd image: https://bit.ly/2QUQZMU
This is the Trezor firmware: https://github.com/trezor/trezor-firmware
Hardware: ESP32 WiFi + Bluetooth ESP32S - ESP-WROOM-32,
ILI9341 TFT LCD with SD card reader and Touch (https://www.xtronical.com/esp32ili9341/).
Using TFT_eSPI driver
Board ESP32 Dev Module
Re: ESP32 and Trezor firmware
Thats more like it!
I would suggest that you start with a spreadsheet with all the ESP pins.
Next allocate hardware interfaces to those pins.
Check that can map the interface to the pin. Some functions are native to certain pins. If you use the GPIO mux then that slows you down.
Does your example use different pins, if so why, what issues would you have changing? Try modifying the example to prove that you can.
The above forces you to walk through the design and you will learn a lot, hopefully enough to take the next step.
I would suggest that you start with a spreadsheet with all the ESP pins.
Next allocate hardware interfaces to those pins.
Check that can map the interface to the pin. Some functions are native to certain pins. If you use the GPIO mux then that slows you down.
Does your example use different pins, if so why, what issues would you have changing? Try modifying the example to prove that you can.
The above forces you to walk through the design and you will learn a lot, hopefully enough to take the next step.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: Larry Cruxton and 75 guests