Search found 22 matches
- Tue Nov 17, 2020 9:45 pm
- Forum: General Discussion
- Topic: Retrieve SPI number (spi_host_device_t) from spi_device_handle_t
- Replies: 0
- Views: 2076
Retrieve SPI number (spi_host_device_t) from spi_device_handle_t
Hi, I'm trying to retrieve the SPI number (spi_host_device_t) from a spi_device_handle_t to free it (spi_bus_free) at closing of a driver. I've not managed to do it without trying to de-reference the handle... int SPI_Close(void *spiHandle) { spi_device_handle_t devHandle = *(spi_device_handle_t *)s...
- Thu Jul 16, 2020 10:43 am
- Forum: General Discussion
- Topic: best practices- logging framework with cloud integration
- Replies: 2
- Views: 4573
Re: best practices- logging framework with cloud integration
You could use esp_log_set_vprintf to set a custom vprintf function. This function could look like this : /* * vprintf-like function to replace the logging output method */ int dual_vprintf(const char *fmt, va_list ap) { // 1. Log to a custom handler (could be a MQTT queue, UDP socket etc) char str[2...
- Thu Jul 16, 2020 9:37 am
- Forum: General Discussion
- Topic: Ethernet PHY best practices for low cost design
- Replies: 15
- Views: 19515
Re: Ethernet PHY best practices for low cost design
GPIO17 is not suitable for WROVER & PSRAM users (& who would not want 4MB of RAM!) because ROM (?) locked GPIO17 as PSRAM CS. How do we stand on GPIO16 citations? On the WROVER IO17 is SRAM clock and IO16 is SRAM chip select. So both are out of the equation... IO16 and IO17 are respectively EMAC_CL...
- Fri Jul 10, 2020 1:37 pm
- Forum: General Discussion
- Topic: Ethernet PHY best practices for low cost design
- Replies: 15
- Views: 19515
Re: Ethernet PHY best practices for low cost design
To get around the issue with option A, that interferes with flashing when using GPIO0, I used the EN pin of the ocilator to disable its clock output. I think you are referring to option B where an external 50MHz oscillator is used (they usually have an enable pin). For option A there is no enable o...
- Fri Jul 10, 2020 8:29 am
- Forum: General Discussion
- Topic: Ethernet PHY best practices for low cost design
- Replies: 15
- Views: 19515
Re: Ethernet PHY best practices for low cost design
@ESP_Sprite: It appears the ESP32 EVB from Olimex does not have on-board PSRAM (ESP32-WROOM-32). Would you consider the clocking of the PHY through IO16/17 or IO0 a stable feature in IDF >v4.x.x ? EDIT: Do you have more information also on using a 25MHz crystal with the LAN8720 and feeding the REFCL...
- Thu Jul 09, 2020 5:14 pm
- Forum: General Discussion
- Topic: Ethernet PHY best practices for low cost design
- Replies: 15
- Views: 19515
Re: Ethernet PHY best practices for low cost design
Thanks Peter for your reply. I know the programming/reset circuit must be designed with care if the clocking is done using GPIO0 as an input. My question is more oriented on the other solution though, which fit my constrains better (low cost, low components count). Of course the goal is to have some...
- Thu Jul 09, 2020 2:55 pm
- Forum: General Discussion
- Topic: Ethernet PHY best practices for low cost design
- Replies: 15
- Views: 19515
Ethernet PHY best practices for low cost design
Hi, I'm currently designing a low-cost device which needs Ethernet connectivity. I selected the LAN8720A PHY for its availability and cost. I understand the clocking of the PHY and MAC is a bit tricky and that there are a few possibilities. The current documentation states 3 modes: A. The PHY is clo...
- Mon Jun 29, 2020 1:55 pm
- Forum: General Discussion
- Topic: wearleveling filesystem image uploading
- Replies: 22
- Views: 28854
Re: wearleveling filesystem image uploading
I understand your idea, but the application already takes a lot of flash and I can't have twice the filesystem memory usage (once for the SPIFFS initial data, and one for the FatFS). I might be able to use the RAM available before any initialization to read and store the SPIFFS data, and then format...
- Sat Jun 27, 2020 11:26 pm
- Forum: General Discussion
- Topic: wearleveling filesystem image uploading
- Replies: 22
- Views: 28854
Re: wearleveling filesystem image uploading
I preferably want the filesystem to be ready when programmed and not have to run a factory program on the ESP32 itself (which is not very convenient for mass production). When updating the firmware using OTA, both the filesystem content and wear leveling status must be preserved. Updating the filesy...
- Fri Jun 26, 2020 2:11 pm
- Forum: General Discussion
- Topic: wearleveling filesystem image uploading
- Replies: 22
- Views: 28854
Re: wearleveling filesystem image uploading
Hi,
Any news on an "official" way to program a pre-formatted FatFS image to use with wear leveling and VFS API?
A tool similar to spiffsgen.py (included in the esp-idf) would be really great for mass-production scenario where certificates and PEM keys must be stored and possibly updated at runtime.
Any news on an "official" way to program a pre-formatted FatFS image to use with wear leveling and VFS API?
A tool similar to spiffsgen.py (included in the esp-idf) would be really great for mass-production scenario where certificates and PEM keys must be stored and possibly updated at runtime.