Anyone have a FV-1 plus microcontroller design which emulates EEPROM?

[phstomp]

@Digital Larry: Ok, thats cool.

I will still mention that in fvduino, all the FV-1 algorithms
do have their default settings which do get written to the EEPROM
whenever they are tweaked and saved in a preset. So there
is no need to re-edit them the next time. So, in a way it is not nearly
as limiting as having just 8 presets and thats all. Those 8 presets
are just the ones which can be recalled with the footswitch.

@jack: an atmega328 also costs about 2$ Its current consumption
is only about 3 mA at 3.3V, 8 MHz, so it is not very noisy part in my
experience.

@free electron: Thanks!

[Digital Larry]

@Digital Larry: Ok, thats cool.

Don't get me wrong, I am stealing most of your ideas.



Thanks again for sharing them.

[free electron]

It works! 1st FV-1 booted from a network drive Sort of...

@phstomp Thanks for posting your code. I have adapted the send_algo() function to work on the ESP8266. It's nicely simplified to deliver what the FV-1 requires and keep up with the timing.
ESP version required a few mods to make it work. The most important being to make it work directly from RAM, not FLASH. Fetching it from external flash was too slow.
I also added a timeout in the while loops. If something goes wrong (mismatched i2c reply) and the MCU won't receive full 512 clocks it will hang up in the while loop with interrupts turned off. Only watchdog reset will help if it's turned on.
I was thinking about using the stock i2c slave software implementation, but after reading about people having problems with achieving standard 100kHz transfers (worked @~30kHz, we need 10x that), clearly a custom, optimized for the FV1 solution was needed.

I have tested the code and it works reliably up to 44.1kHz samplerate for the FV-1. Breaks at 48kHz.

Too bad the ESP8266 doesn't have any hardware PWM built in. I could use it to generate the clock for the FV-1, as i did in the BaseStar project. With that it would be possible to lower the Fclk to 32KHz for the upload time and then set it back to whatever it was before.

But even without it it's pretty useful: compile hex, click upload, click enable and one of the 8 buttons to load the patch into FV-1. 3MB of disk space is enough for over a hundred of hex files. If it's still not enough, the esp board can be modded to have an 8MB flash chip. No need to do any extra operations on the hex file. Direct SpinAsm output works fine.
Another idea: use an FTP server on the ESP8266, mount it directly in the system as a disk/folder and point the SpinAsm or SpinCad to save the hex file directly into the ESP. Could save the step of manually uploading the file.

I'll clean up the code and post it soon.

-EDIT-
That was quick. FTP access works, ESP's disk is mounted as a folder in my home directory:

[potul]

It works! 1st FV-1 booted from a network drive Sort of...
...
That was quick. FTP access works, ESP's disk is mounted as a folder in my home directory:

This looks amazing.... so you can compile directly into the development board, and then control via web server what to load to the fv-1.

Did you use Arduino IDE or Espressif-SDK?

[potul]

I was just starting with my idea of using an SDCard, but looking at your ESP8266 solution, I'm changing my mind. This looks really convenient, connecting via WIFI to the pedal and upload new hex files.

The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.

Will you be sharing your code?

[free electron]

I'm using arduino, not their IDE, but VScode + Platformio.
Yes, i'll share the code once it's cleaned up from all that debug stuff i put in. The htmls also need some more work.

WiFi:
i don't like these IoT gadgets on my main network, so usually i set them as Access Points and connect directly to the device using a 2nd usb/wifi dongle.
In this case the board creates it's own WiFi with a name "FV1DevRemote" with a password you set in firmware. No direct internet connection. FTP is not secure, but it can handle a single client only anyway.
I'm not sure about putting it in a diecast alu box, though (WiFi range).

What i'd like to add later on are 3 sliders controlling the pot inputs via pwm.

[pruttelherrie]

The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.

That's what WiFiManager is for.

[Digital Larry]

Yeah I used an Android app from one of the ESP-IDF examples to get wifi connected.

[potul]

The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.

That's what WiFiManager is for.

Great. ESP8266 is quite new for me, I was not aware of it. This is even more exciting... new platform, interesting project... 

[Digital Larry]

Great. ESP8266 is quite new for me, I was not aware of it. This is even more exciting... new platform, interesting project... 

Not sure if you're interested in OSC, but here's some ESP32 code I did which includes support for OSC over Wi-Fi.  FX code was compiled from Faust.  However the OSC implementation is external to Faust and could easily be used to do other things like set pot voltages (if you can figure out how to do that).  Combine this with TouchOSC... you'll be mad with power!

https://github.com/HolyCityAudio/ESP32/tree/master/faust/flangerOSC

[pruttelherrie]

Thinking further...

I built a few FV-1 pedals where the I2C is on a header, so I can program the EEPROM with a Pikcit2:



If I can put the on-board EEPROM on a different address with a jumper, and I connect an ESP8266 box to this header, I can play and upload to my hearts content since the on-board EEPROM will not react to the FV-1, only the ESP8266 will.
Then when I'm happy with the bank (only 3 programs are selectable in this pedal, with an On/Off/On toggle), I can flash the bank into the on-board EEPROM and remove the jumper. For this the ESP8266 must switch into I2C master mode, should be doable I think.

Thoughts?

[Digital Larry]

Thoughts?

Anything that speeds up loading patches is good!

On a slightly different topic,  I seem to have been confused about OSC and the Teensy.  OSC requires a TCPIP stack and even though there look to be some Ethernet shields for the Teensy, it's not directly supported in Teensyduino.  I did see OSC in the Arduino IDE menus though.  On further inspection, that appears to be supported on the ESP8266.

Going back to my original thoughts about my project (which is currently based on a Teensy 3.2, just because I had one), I thought it would support OSC but possibly it would only support MIDI.  That's probably still OK as I only have 3 or 4 controllers, which can take CCs, and possibly wanting to interpret tempo from MIDI clock somehow for sync'ed delays.

I have another project in mind which is just to have a little box which sends useful OSC and/or MIDI messages over wifi.  Turns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button).  This is a HUGE oversight IMO.  However I guess I can build something using one of the ESP8266 boards I bought to try to use with Faust for OSC instead. 

[pruttelherrie]

OSC requires a TCPIP stack

Not exclusively! It is possible to route OSC packets over a serial link, using SLIP encoding.

https://github.com/CNMAT/OSC

Turns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button).  This is a HUGE oversight IMO.

Hmm.. didn't know that. That's unfortunate! What would you need a bundle for?

[free electron]

Thoughts?

Definitely doable.
I have tested the upload function by lifting the 1st pin of the 24LC32A on my dev board, pulling it up to 3.3V and connecting the ESP8266 directly to the i2c bus.
Could be done this way:

- additional "Detect" signal connected to 3.3V on the ESP8266 board, when plugged, pulls the A0 up, disconnecting it from the FV-1
- i2c slave on the ESP takes over the normally used eeprom address and supplies the firmware when asked
- a new "burn" button on the webpage, switches the i2c to master, burns the firmware to the eeprom @0x51,
- disconnecting the ESP8266 board sets the onboard eeprom's address back to 0x50, the one that FV-1 needs.
- the above operation could be used to send a pulse to reset the FV1 and trigger the firmware reload.

I have not tested the reset pulse generator in hardware, only simulated in ltspice. Couldn't find specific voltage levels for logic hi and lo in the FV-1 datasheet. If the pulse is still too high (goes down to 0.6V now) or too short the 10k can be increased.

[Digital Larry]

OSC requires a TCPIP stack

Not exclusively! It is possible to route OSC packets over a serial link, using SLIP encoding.

https://github.com/CNMAT/OSC

Turns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button).  This is a HUGE oversight IMO.

Hmm.. didn't know that. That's unfortunate! What would you need a bundle for?

Thanks for info on SLIP.  Not sure it matters but always good to know.

I would not need a bundle for anything to do with the FV-1.  However I am trying to set up a complex guitar looping arrangement with my XR-18 mixer.  What I have in mind requires setting 5 or 6 levels at the same time to set different aux sends etc. from 3 different sources.  I found  "X-Air Live Toolbox" which is an app to do that.  It might be adequate.

It's the time of year when I seem to go nuts with different ideas.  A successful year is one where I actually follow through on a couple of them.  I don't know what's going to happen this year.

[pruttelherrie]

Thoughts?

Definitely doable.
(...)
Could be done this way:
- additional "Detect" signal connected to 3.3V on the ESP8266 board, when plugged, pulls the A0 up, disconnecting it from the FV-1
- i2c slave on the ESP takes over the normally used eeprom address and supplies the firmware when asked
- a new "burn" button on the webpage, switches the i2c to master, burns the firmware to the eeprom @0x51,
- disconnecting the ESP8266 board sets the onboard eeprom's address back to 0x50, the one that FV-1 needs.
- the above operation could be used to send a pulse to reset the FV1 and trigger the firmware reload.

Awesome! Hadn't thought of automatically addressing & resetting!

Thanks for info on SLIP.  Not sure it matters but always good to know.

Yeah on second thought it doesn't help that much, you still need to get the packets from the app to the serial.

[potul]

So, I got a couple of NodeMcus this weekend and managed to install Platformio.

Great, I have my first FTP server up and running and filled with hex files... now I need to build a new FV1 board to connect to.

[free electron]

Almost done, will post a new thread about the project soon:



I like the idea of a pluggable wifi enabled programmer module, with a few small tweaks any existing FV-1 device could be adapted to use it.
So for now i abandoned the POT controls via PWM, but added the option to burn the onboard EEPROM with the currently enabled file.
The "EEPROM Enable" button turns the filesystem EEPROM emulator off and pulls down the A0 address low, FV1 will read the firmware from the EEPROM.
Handy as a last test step to see if everything works correctly. Of course, EEPROM is verified after writing the bin file content.

[Leetut]

....

[alfrede]

Here i found a projekt for a pedal platform and eeproms.
https://github.com/mstratman/fv1-pedal-platform