Gavin1968 Posted October 1, 2020 Share Posted October 1, 2020 (edited) 9 minutes ago, Mr Robot said: Ooh! custom url! Always, same with http://sdrivemax.shop Edited October 1, 2020 by Gavin1968 2 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted October 3, 2020 Author Share Posted October 3, 2020 I've finally got a 'working' prototype built using 2 sn74ls07 buffers to separate the FujiNet from the Atari. The buffer chips are only powered when FujiNet is ON by using some transistors and this fixes the back power issue. I unfortunately have a new issue with this setup. The FujiNet alone on the SIO bus works great, but when I connect another drive there is some questionable boot sounds. Also, I've noticed this on the v1.1 boards I made with the 2 line buffer. Any ideas what is happening here? VID_20201003_151541413.m4v Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 3, 2020 Share Posted October 3, 2020 I'm not an engineer, but if you are referring to the strange SIO loading stutter, it sounds like a buffer delayed sound. Maybe the Fujinet isn't actually separated from the bus. Could the 07 chip actually be buffering both the Fujinet and the second SIO device? On another topic..... what board assembler did you use to have the Fujinet pcbs assembled? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 3, 2020 Share Posted October 3, 2020 the stutter is because of loading something from a remote server. He's referring to the almost ring modulated quality of the atari beeps. -Thom Quote Link to comment Share on other sites More sharing options...
mozzwald Posted October 4, 2020 Author Share Posted October 4, 2020 1 hour ago, Dropcheck said: On another topic..... what board assembler did you use to have the Fujinet pcbs assembled? makerfabs.com Quote Link to comment Share on other sites More sharing options...
Swami Posted October 7, 2020 Share Posted October 7, 2020 Sorry, I got a little lost in the tech speak. I understand some of the capabilities such as WiFi and printing to PDF you can download to your PC, and well as statements about the ability to play cas, xex, atr and atx. However, I have an older SDrive Max and was considering getting a newer one with the upgrades and I'm wondering if, 1. via WiFi and software on your PC, can the FujiNet do all that the SDrive Max can, except wirelessly from your PC. 2. Would it work like the SIO2PC, except via WiFi? Would it use APE? 3. Does it function okay with a bunch of daisy chained peripherals, like the newer SDriveMax? Thanks! Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted October 7, 2020 Share Posted October 7, 2020 6 hours ago, Swami said: Sorry, I got a little lost in the tech speak. I understand some of the capabilities such as WiFi and printing to PDF you can download to your PC, and well as statements about the ability to play cas, xex, atr and atx. However, I have an older SDrive Max and was considering getting a newer one with the upgrades and I'm wondering if, 1. via WiFi and software on your PC, can the FujiNet do all that the SDrive Max can, except wirelessly from your PC. It has a micro SD slot on it like the SDrive-Max does, you can literally pull the card out of your SDrive, put it in your Fujinet, add the "SD" device to the Fujinet host list and carry on just like you did on the SDrive (but better with long filename support etc.) Quote 2. Would it work like the SIO2PC, except via WiFi? Would it use APE? No it doesn't work like SIO2PC at all. You can set up a bit of software on your PC called TNFSD which you point to a directory on your computer, while TNFSD is running you can point your Fujinet at it and browse that directory on your Atari just like you would browse the SD card on your SDrive. If you want to add something new, just put it in the shared directory and it instantly becomes visible on your atari. There is nothing to stop you making the TNFSD service publicly available if you want (you might want to make it read only if you do that) and there are a few people who have done this. You can connect your Fujinet to their TNFS service and you can browse those directories just like you can browse your SD card. I usually create save disks on my SD card and load my software from my read only TNFS server at Fujinet.Atari8bit.net. You can see server stats for it at https://atari8bit.net/fujinet/ it might help you visualise what is going on. *All this is optional, you can just use your SD card if you prefer. There is noting stopping you from just using it as an SDrive replacement with built in wifi-modem and printer emulation if you like. All the extra functionality is there for when you find you need it. Quote 3. Does it function okay with a bunch of daisy chained peripherals, like the newer SDriveMax? Thanks! Yes it does, there is a known issue for people who own a 1088XEL which is fixed in the next hardware revision, if you don't have a 1088XEL you don't need to worry about that. EDIT: I made this a while ago, sorry for the slow pacing. 5 1 Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 I decided to build one using spare ESP-Wroom that I had. Last year I built with ESP8266 so this time Wroom. I know, current status is Wrover but some things should work still on that board. I downloaded flasher (I'm using Linux) but it fails to flash using GUI. Here is output. Using '/dev/ttyUSB0' as serial port. Using latest firmware from fujinet.online.. Connecting........_ Detecting chip type... ESP32 Connecting........_ Chip Info: - Chip Family: ESP32 - Chip Model: ESP32D0WDQ5 (revision 1) - Number of Cores: 2 - Max CPU Frequency: 80MHz - Has Bluetooth: YES - Has Embedded Flash: NO - Has Factory-Calibrated ADC: NO - MAC Address: 30:AE:A4:97:F7:C0 Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed. - Flash Size: 4MB - Firware path: Latest from fujinet.online - Flash Mode: dio - Flash Frequency: 40MHz Erasing flash (this may take a while)... Chip erase completed successfully in 9.1s Unexpected error: '_io.BytesIO' object has no attribute 'name' I believe that error is because latest firmware does not support WROOM anymore. I also tried command line version with files downloaded from https://fujinet.online/firmware-dl/ $ sudo ./FujiNet-Flasher -p /dev/ttyUSB0 --esp32 --bootloader bootloader.bin --partitions partitions.bin --spiffs spiffs.bin --show-logs firmware.bin Using '/dev/ttyUSB0' as serial port. Showing logs: But it sits like that, nothing more shows up. `ps` shows that it forked additional processes but that's all $ ps aux| grep Fuji root 89851 0.1 0.1 11452 4460 pts/1 S+ 12:39 0:00 sudo ./FujiNet-Flasher -p /dev/ttyUSB0 --esp32 --bootloader bootloader.bin --partitions partitions.bin --spiffs spiffs.bin --show-logs firmware.bin root 89852 13.9 0.4 19480 18288 pts/1 S+ 12:39 0:02 ./FujiNet-Flasher -p /dev/ttyUSB0 --esp32 --bootloader bootloader.bin --partitions partitions.bin --spiffs spiffs.bin --show-logs firmware.bin root 89854 4.2 0.4 47816 16236 pts/1 S+ 12:39 0:00 ./FujiNet-Flasher -p /dev/ttyUSB0 --esp32 --bootloader bootloader.bin --partitions partitions.bin --spiffs spiffs.bin --show-logs firmware.bin What is the process to flash latest WROOM version? Quote Link to comment Share on other sites More sharing options...
mozzwald Posted October 7, 2020 Author Share Posted October 7, 2020 34 minutes ago, myriadcs said: I believe that error is because latest firmware does not support WROOM anymore. Correct. The flash tool only supports WROVER boards with 8MB PSRAM and 16MB flash 33 minutes ago, myriadcs said: What is the process to flash latest WROOM version? WROOM is not supported. You are welcome to fork the code and make it work if you like, but we are not supporting it. You can follow the instructions to build the code yourself https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Board-bring-up-for-FujiNet-Platform.IO-code and you need to checkout the code from https://github.com/FujiNetWIFI/fujinet-platformio/releases/tag/v0.1.ccbb292f. Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 18 minutes ago, mozzwald said: Correct. The flash tool only supports WROVER boards with 8MB PSRAM and 16MB flash WROOM is not supported. You are welcome to fork the code and make it work if you like, but we are not supporting it. You can follow the instructions to build the code yourself https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Board-bring-up-for-FujiNet-Platform.IO-code and you need to checkout the code from https://github.com/FujiNetWIFI/fujinet-platformio/releases/tag/v0.1.ccbb292f. Sure, I can build that, will be good experience Just wanted to confirm that my command line switches are ok, and it will work once I will recompile that. One thing worries me that It just stuck in CLI, without any information what is happening and no errors indicated. Is there a verbose mode so it's easier to trouble shoot? GUI seems be better as it marked error and stopped, CLI didn't. Quote Link to comment Share on other sites More sharing options...
mozzwald Posted October 7, 2020 Author Share Posted October 7, 2020 2 minutes ago, myriadcs said: Sure, I can build that, will be good experience Just wanted to confirm that my command line switches are ok, and it will work once I will recompile that. One thing worries me that It just stuck in CLI, without any information what is happening and no errors indicated. Is there a verbose mode so it's easier to trouble shoot? GUI seems be better as it marked error and stopped, CLI didn't. I've not used the command line tool myself so I can't help you there. Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 44 minutes ago, mozzwald said: I've not used the command line tool myself so I can't help you there. Ok, thanks anyway for pointers, I will find spare moment and dive into that Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 I managed to compile that firmware. I could not use GUI flasher as it's configured for bigger boards. After compilation, in .pio/build/fujinet-wroom/ I had 4 files: bootloader.bin partitions.bin spiffs.bin firmware.bin boot_app0.bin was taken from https://fujinet.online/firmware-dl/ Is that version ok for WROOM? I've used esptool with following offsets: esptool.py write_flash 0x1000 ./bootloader.bin 0x8000 ./partitions.bin 0xE000 ./boot_app0.bin 0x10000 ./firmware.bin 0x200000 ./spiffs.bin I had to play w bit with these offsets to fit. Command output look ok: esptool.py v2.6 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting........_____....._____.. Detecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 1) Features: WiFi, BT, Dual Core, Coding Scheme None MAC: 30:30:30:30:30:30 Uploading stub... Running stub... Stub running... Configuring flash size... Auto-detected Flash size: 4MB Compressed 26960 bytes to 16219... Wrote 26960 bytes (16219 compressed) at 0x00001000 in 1.4 seconds (effective 150.4 kbit/s)... Hash of data verified. Compressed 3072 bytes to 119... Wrote 3072 bytes (119 compressed) at 0x00008000 in 0.0 seconds (effective 1544.3 kbit/s)... Hash of data verified. Compressed 8192 bytes to 47... Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 7258.3 kbit/s)... Hash of data verified. Compressed 1960832 bytes to 1137946... Wrote 1960832 bytes (1137946 compressed) at 0x00010000 in 101.3 seconds (effective 154.9 kbit/s)... Hash of data verified. Compressed 1769472 bytes to 339295... Wrote 1769472 bytes (339295 compressed) at 0x00200000 in 30.2 seconds (effective 469.1 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin... It flashed but something is not ok, here is debug output: rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:4 load:0x3fff0034,len:5532 load:0x40078000,len:16488 load:0x40080400,len:4840 entry 0x400806a4 E (657) spiram: SPI RAM enabled but initialization failed. Bailing out. E (666) uart: uart_write_bytes(1111): uart driver error E (666) uart: uart_write_bytes(1111): uart driver error E (666) uart: uart_write_bytes(1111): uart driver error E (670) uart: uart_write_bytes(1111): uart driver error E (675) uart: uart_write_bytes(1111): uart driver error E (680) uart: uart_write_bytes(1111): uart driver error E (685) uart: _����垠8�(����R��`D0` @`��̀��<@$��$$"�Dz�ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:4 load:0x3fff0034,len:5532 load:0x40078000,len:16488 load:0x40080400,len:4840 entry 0x400806a4 I have tried with different offsets as well esptool.py write_flash 0x0000 ./bootloader.bin 0x8000 ./partitions.bin 0xE000 ./boot_app0.bin 0x10000 ./firmware.bin 0x250000 ./spiffs.bin But it also failed, different error this time. rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57 I guess some of the offsets are not ok. Any idea which one? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 7, 2020 Share Posted October 7, 2020 1 minute ago, myriadcs said: I managed to compile that firmware. I could not use GUI flasher as it's configured for bigger boards. After compilation, in .pio/build/fujinet-wroom/ I had 4 files: bootloader.bin partitions.bin spiffs.bin firmware.bin boot_app0.bin was taken from https://fujinet.online/firmware-dl/ Is that version ok for WROOM? I've used esptool with following offsets: esptool.py write_flash 0x1000 ./bootloader.bin 0x8000 ./partitions.bin 0xE000 ./boot_app0.bin 0x10000 ./firmware.bin 0x200000 ./spiffs.bin I had to play w bit with these offsets to fit. Command output look ok: esptool.py v2.6 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting........_____....._____.. Detecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 1) Features: WiFi, BT, Dual Core, Coding Scheme None MAC: 30:30:30:30:30:30 Uploading stub... Running stub... Stub running... Configuring flash size... Auto-detected Flash size: 4MB Compressed 26960 bytes to 16219... Wrote 26960 bytes (16219 compressed) at 0x00001000 in 1.4 seconds (effective 150.4 kbit/s)... Hash of data verified. Compressed 3072 bytes to 119... Wrote 3072 bytes (119 compressed) at 0x00008000 in 0.0 seconds (effective 1544.3 kbit/s)... Hash of data verified. Compressed 8192 bytes to 47... Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 7258.3 kbit/s)... Hash of data verified. Compressed 1960832 bytes to 1137946... Wrote 1960832 bytes (1137946 compressed) at 0x00010000 in 101.3 seconds (effective 154.9 kbit/s)... Hash of data verified. Compressed 1769472 bytes to 339295... Wrote 1769472 bytes (339295 compressed) at 0x00200000 in 30.2 seconds (effective 469.1 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin... It flashed but something is not ok, here is debug output: rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:4 load:0x3fff0034,len:5532 load:0x40078000,len:16488 load:0x40080400,len:4840 entry 0x400806a4 E (657) spiram: SPI RAM enabled but initialization failed. Bailing out. E (666) uart: uart_write_bytes(1111): uart driver error E (666) uart: uart_write_bytes(1111): uart driver error E (666) uart: uart_write_bytes(1111): uart driver error E (670) uart: uart_write_bytes(1111): uart driver error E (675) uart: uart_write_bytes(1111): uart driver error E (680) uart: uart_write_bytes(1111): uart driver error E (685) uart: _����垠8�(����R��`D0` @`��̀��<@$��$$"�Dz�ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:4 load:0x3fff0034,len:5532 load:0x40078000,len:16488 load:0x40080400,len:4840 entry 0x400806a4 I have tried with different offsets as well esptool.py write_flash 0x0000 ./bootloader.bin 0x8000 ./partitions.bin 0xE000 ./boot_app0.bin 0x10000 ./firmware.bin 0x250000 ./spiffs.bin But it also failed, different error this time. rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57 I guess some of the offsets are not ok. Any idea which one? The code now assumes there is PSRAM. If you want to build for your WROOM, you'll need to fork from before the 1.0 tag: https://github.com/FujiNetWIFI/fujinet-platformio/tree/9aca28d29c863e7145e1c5429979a1705f373434 -Thom Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 19 minutes ago, tschak909 said: The code now assumes there is PSRAM. If you want to build for your WROOM, you'll need to fork from before the 1.0 tag: https://github.com/FujiNetWIFI/fujinet-platformio/tree/9aca28d29c863e7145e1c5429979a1705f373434 -Thom I have used that code https://github.com/FujiNetWIFI/fujinet-platformio/releases/tag/v0.1.ccbb292f I can switch to commit you mentioned and test it. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 7, 2020 Share Posted October 7, 2020 Just now, myriadcs said: I have used that code https://github.com/FujiNetWIFI/fujinet-platformio/releases/tag/v0.1.ccbb292f I can switch to commit you mentioned and test it. The key is to look for BOARD_HAS_PSRAM #ifdefs -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 7, 2020 Share Posted October 7, 2020 The device definitions for the wroom board need to go away soon. -Thom Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 5 minutes ago, tschak909 said: The key is to look for BOARD_HAS_PSRAM #ifdefs -Thom My board definition looks like: $ cat boards/fujinet-wroom.json { "build": { "arduino":{ "ldscript": "esp32_out.ld" }, "core": "esp32", "extra_flags": "-DARDUINO_ESP32_DEV", "f_cpu": "240000000L", "f_flash": "40000000L", "flash_mode": "dio", "mcu": "esp32", "variant": "esp32", "partitions": "fujinet_partitions_4MB.csv" }, "connectivity": [ "wifi", "bluetooth", "ethernet", "can" ], "debug": { "openocd_board": "esp-wroom-32.cfg" }, "frameworks": [ "arduino", "espidf" ], "name": "#FujiNet WROOM", "upload": { "flash_size": "4MB", "maximum_ram_size": 327680, "maximum_size": 4194304, "protocols": [ "esptool", "espota", "ftdi" ], "require_upload_port": true, "speed": 460800 }, "url": "https://github.com/FujiNetWIFI/atariwifi", "vendor": "FujiNet Project" } I can see that defined for other boards: $ grep BOARD_HAS_PSRAM * -R boards/fujinet-v1.json: "extra_flags": "-DARDUINO_ESP32_DEV -DBOARD_HAS_PSRAM", boards/fujinet-v1-4mb.json: "extra_flags": "-DARDUINO_ESP32_DEV -DBOARD_HAS_PSRAM", Is my board definition ok? I do not mention BOARD_HAS_PSRAM in flags, or it's defined somewhere else? Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted October 7, 2020 Share Posted October 7, 2020 JSON and the Argu-naughts Quote Link to comment Share on other sites More sharing options...
Swami Posted October 7, 2020 Share Posted October 7, 2020 6 hours ago, Mr Robot said: It has a micro SD slot on it like the SDrive-Max does, you can literally pull the card out of your SDrive, put it in your Fujinet, add the "SD" device to the Fujinet host list and carry on just like you did on the SDrive (but better with long filename support etc.) No it doesn't work like SIO2PC at all. You can set up a bit of software on your PC called TNFSD which you point to a directory on your computer, while TNFSD is running you can point your Fujinet at it and browse that directory on your Atari just like you would browse the SD card on your SDrive. If you want to add something new, just put it in the shared directory and it instantly becomes visible on your atari. There is nothing to stop you making the TNFSD service publicly available if you want (you might want to make it read only if you do that) and there are a few people who have done this. You can connect your Fujinet to their TNFS service and you can browse those directories just like you can browse your SD card. I usually create save disks on my SD card and load my software from my read only TNFS server at Fujinet.Atari8bit.net. You can see server stats for it at https://atari8bit.net/fujinet/ it might help you visualise what is going on. *All this is optional, you can just use your SD card if you prefer. There is noting stopping you from just using it as an SDrive replacement with built in wifi-modem and printer emulation if you like. All the extra functionality is there for when you find you need it. Yes it does, there is a known issue for people who own a 1088XEL which is fixed in the next hardware revision, if you don't have a 1088XEL you don't need to worry about that. EDIT: I made this a while ago, sorry for the slow pacing. So, when using just sd card, do you read from the Atari monitor like a multicart or how do you browse without the lcd screen on the sdrive max? Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted October 7, 2020 Share Posted October 7, 2020 1 minute ago, Swami said: So, when using just sd card, do you read from the Atari monitor like a multicart or how do you browse without the lcd screen on the sdrive max? Just like when you boot to D0 on your SDrive and browse using the Atari SDrive menu, the Fujinet boots to a config program that runs on your Atari and allows you to browse the software from there. Watch the video I know it's slow, sorry! 1 Quote Link to comment Share on other sites More sharing options...
jamm Posted October 7, 2020 Share Posted October 7, 2020 1 hour ago, myriadcs said: My board definition looks like: $ cat boards/fujinet-wroom.json { "build": { "arduino":{ "ldscript": "esp32_out.ld" }, "core": "esp32", "extra_flags": "-DARDUINO_ESP32_DEV", "f_cpu": "240000000L", "f_flash": "40000000L", "flash_mode": "dio", "mcu": "esp32", "variant": "esp32", "partitions": "fujinet_partitions_4MB.csv" }, "connectivity": [ "wifi", "bluetooth", "ethernet", "can" ], "debug": { "openocd_board": "esp-wroom-32.cfg" }, "frameworks": [ "arduino", "espidf" ], "name": "#FujiNet WROOM", "upload": { "flash_size": "4MB", "maximum_ram_size": 327680, "maximum_size": 4194304, "protocols": [ "esptool", "espota", "ftdi" ], "require_upload_port": true, "speed": 460800 }, "url": "https://github.com/FujiNetWIFI/atariwifi", "vendor": "FujiNet Project" } I can see that defined for other boards: $ grep BOARD_HAS_PSRAM * -R boards/fujinet-v1.json: "extra_flags": "-DARDUINO_ESP32_DEV -DBOARD_HAS_PSRAM", boards/fujinet-v1-4mb.json: "extra_flags": "-DARDUINO_ESP32_DEV -DBOARD_HAS_PSRAM", Is my board definition ok? I do not mention BOARD_HAS_PSRAM in flags, or it's defined somewhere else? The BOARD_HAS_PSRAM precompiler flag is used in several places in the source code. Since WROOM doesn't have PSRAM, it should not be defined, so it looks correct. The boards/fujinet-wroom.json file is correct in the v0.1.ccbb292f release, so you shouldn't have to do anything other than specify the correct ENV value in your PLATFORMIO.INI. This is well commented in the PLATFORMIO.INI file. Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 2 minutes ago, jamm said: The BOARD_HAS_PSRAM precompiler flag is used in several places in the source code. Since WROOM doesn't have PSRAM, it should not be defined, so it looks correct. The boards/fujinet-wroom.json file is correct in the v0.1.ccbb292f release, so you shouldn't have to do anything other than specify the correct ENV value in your PLATFORMIO.INI. This is well commented in the PLATFORMIO.INI file. my platformio.ini looks ok I think $ cat platformio.ini ;FujiNet PlatformIO Project Configuration File ; ; Build options: build flags, source filter ; Upload options: custom upload port, speed and extra flags ; Library options: dependencies, extra library storages ; Advanced options: extra scripting ; ; Please visit documentation for the other options and examples ; https://docs.platformio.org/page/projectconf.html [platformio] description = FujiNet Atari to ESP32 WiFi Multifunction Firmware ; Change this to target the device you use from the list of [env:xxx] sections below default_envs = fujinet-wroom [env] ; Common settings for all enivornments platform = espressif32 framework = espidf extra_scripts = pre:build_version.py lib_ldf_mode = deep+ ;upload_port = COM1 ; Windows upload_port = /dev/ttyUSB0 ; Linux upload_speed = 921600 ;monitor_port = COM1 ; Windows monitor_port = /dev/ttyUSB0 ; Linux monitor_speed = 921600 monitor_filters = time ; ESP32 WROOM [env:fujinet-wroom] board = fujinet-wroom build_type = debug build_flags = ;-D JTAG -D DEBUG_SPEED=921600 -D BLUETOOTH_SUPPORT ;-D FN_HISPEED_INDEX=0 ;-D VERBOSE_SIO ;-D VERBOSE_TNFS ;-D VERBOSE_DISK ;-D VERBOSE_ATX Only thing I can think of is boot_app0.bin which was not produced in build and I had to take it from current one. Maybe it has references to PSRAM? what that binary is responsible for? Quote Link to comment Share on other sites More sharing options...
jamm Posted October 7, 2020 Share Posted October 7, 2020 1 minute ago, myriadcs said: my platformio.ini looks ok I think $ cat platformio.ini ;FujiNet PlatformIO Project Configuration File ; ; Build options: build flags, source filter ; Upload options: custom upload port, speed and extra flags ; Library options: dependencies, extra library storages ; Advanced options: extra scripting ; ; Please visit documentation for the other options and examples ; https://docs.platformio.org/page/projectconf.html [platformio] description = FujiNet Atari to ESP32 WiFi Multifunction Firmware ; Change this to target the device you use from the list of [env:xxx] sections below default_envs = fujinet-wroom [env] ; Common settings for all enivornments platform = espressif32 framework = espidf extra_scripts = pre:build_version.py lib_ldf_mode = deep+ ;upload_port = COM1 ; Windows upload_port = /dev/ttyUSB0 ; Linux upload_speed = 921600 ;monitor_port = COM1 ; Windows monitor_port = /dev/ttyUSB0 ; Linux monitor_speed = 921600 monitor_filters = time ; ESP32 WROOM [env:fujinet-wroom] board = fujinet-wroom build_type = debug build_flags = ;-D JTAG -D DEBUG_SPEED=921600 -D BLUETOOTH_SUPPORT ;-D FN_HISPEED_INDEX=0 ;-D VERBOSE_SIO ;-D VERBOSE_TNFS ;-D VERBOSE_DISK ;-D VERBOSE_ATX Only thing I can think of is boot_app0.bin which was not produced in build and I had to take it from current one. Maybe it has references to PSRAM? what that binary is responsible for? If any part of the firmware isn't building, then obviously there's something fundamentally wrong with the setup. I recommend deleting the project directory entirely and starting with a fresh download of the v0.1.ccbb292f release. Quote Link to comment Share on other sites More sharing options...
myriadcs Posted October 7, 2020 Share Posted October 7, 2020 22 minutes ago, jamm said: If any part of the firmware isn't building, then obviously there's something fundamentally wrong with the setup. I recommend deleting the project directory entirely and starting with a fresh download of the v0.1.ccbb292f release. I have removed directory completely, downloaded zip https://github.com/FujiNetWIFI/fujinet-platformio/archive/v0.1.ccbb292f.zip unpacked, added platformio.ini as in earlier post and run build. No errors =========================================================================== [SUCCESS] Took 273.02 seconds =========================================================================== Environment Status Duration ------------- -------- ------------ fujinet-wroom SUCCESS 00:04:33.019 but boot_app0.bin is not there $ find . -name "*.bin" ./.pio/build/fujinet-wroom/partitions.bin ./.pio/build/fujinet-wroom/CMakeFiles/3.16.4/CMakeDetermineCompilerABI_CXX.bin ./.pio/build/fujinet-wroom/CMakeFiles/3.16.4/CMakeDetermineCompilerABI_C.bin ./.pio/build/fujinet-wroom/bootloader.bin ./.pio/build/fujinet-wroom/firmware.bin ./.pio/build/fujinet-wroom/bootloader/CMakeFiles/3.16.4/CMakeDetermineCompilerABI_CXX.bin ./.pio/build/fujinet-wroom/bootloader/CMakeFiles/3.16.4/CMakeDetermineCompilerABI_C.bin ./data/850handler.bin ./data/picoboot.bin ./data/850relocator.bin but also no spiffs.bin this time so I guess something must be missing in my setup. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.