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

[potul]

I'd consider:
a) USB interface.  I don't even want to mess with shlepping SD cards in and out.
b) aux EEprom for storage instead of SD card (to be combined with USB interface to allow fast, in place loading of patches from PC).  How big do they make them?

DL

Sorry I sort of highjacked your thread and created some confusion. SDCard was only MY idea, phstomp project is embedding the fv1 programs into the Arduino code. This means that everytime you need a new program, you need to:

-complile it and get the hex or bin
-Do some sort of transformation of it, compress, etc..
-Add it to the Arduino source code.
-Program the Atmega with it.

[Digital Larry]

Hey, who's in charge here?   

It's interesting to see how what people have developed is different than what I imagine - mostly because I want a platform to develop and maintain a library of diverse patches, which really means:
- a lot of memory to store both patches and presets
- ease of connection of PC to transfer data
- real time code updating

The OLED and knob interfaces are cool.  Lots of great ideas.

[phstomp]

The SD card is actually a great idea, it removes the need
to cram everything to 32k memory, which is a bit of a pain
and also decouples the FV-1 algorithms from the atmega
code. Could also save presets there and make backups.

I'm almost out of free atmega328 pins though, so it would be
a bit difficult to implement.

[Ice-9]

Hey, who's in charge here?   

It's interesting to see how what people have developed is different than what I imagine - mostly because I want a platform to develop and maintain a library of diverse patches, which really means:
- a lot of memory to store both patches and presets
- ease of connection of PC to transfer data
- real time code updating

The OLED and knob interfaces are cool.  Lots of great ideas.

If it is easy loading of new programs libraries you are looking at why not look into a smart cart option, something like an Atmege163 which has an Atmega163 CPU and a 24lc256 eeprom embeded could be a great solution. A massive effects library in your wallet.
Something like this can store many effects plus all the data for effects names and pot names.

[free electron]

Also to handle the hex files directly there would have to be some kind of hex2bin implemented to get the raw binary data.
Staying within Arduino territory, a SAMD51J19A (Adafruit uses them in their "feather" boards) with 512k of flash could do the job, too. With plenty of external storage options.
Recently found out about these SMT chips, basically an SD card in 8pin chip form:
https://lcsc.com/products/FLASH_501.html?q=XTSD
I doubt GB's would be needed, though. With SPI there is lots of flash chips to choose from.

Nice alternative to the OLED displays are these tiny IPS 160x80 SPI ones:
look for "IPS display 0.96 inch TFT LCD Display Screen 80*160 ST7735" or something like that.
I have used one in a recent current/voltage/power meter project:



Paid about 1.50€ apiece. There are larger models, too.

[potul]

Also to handle the hex files directly there would have to be some kind of hex2bin implemented to get the raw binary data.

This can be done by the Arduino easily. The Intel Hex format is not difficult to parse, specially if we already know in advance it's an FV1 program, so you can skip most of the bytes and focus on the data ones.
This could be done at the moment we load the program into RAM buffer to avoid interfering with I2C timing.

[amz-fx]

Another technique:

http://www.muzique.com/news/adding-memory-to-the-fv-1-reverb/

regards, Jack

[Digital Larry]

I dug out my Teensy 3.2 board I got a couple years ago.  Set up Arduino and added Teensyduino.  Wow this thing is cool!  Within about an hour of messing around I had it responding to MIDI clock over USB.  The possibility of syncing FV algorithms to MIDI, even brute force by tap-tempo techniques, opens up a lot of creative territory. 

There is also "I2C slave" object in the library but it's not clear whether it will work with the FV-1.  I guess I can try it.  The approach of putting multiple 24LC32A chips on the board works too.

[potul]

I dug out my Teensy 3.2 board I got a couple years ago.  Set up Arduino and added Teensyduino.  Wow this thing is cool!  Within about an hour of messing around I had it responding to MIDI clock over USB.  The possibility of syncing FV algorithms to MIDI, even brute force by tap-tempo techniques, opens up a lot of creative territory. 

There is also "I2C slave" object in the library but it's not clear whether it will work with the FV-1.  I guess I can try it.  The approach of putting multiple 24LC32A chips on the board works too.

Great. Teensy might be able to handle the slave I2C without timing issues, give it a try.

Changing gears for a second, I recall a project I found long ago that was handling the presets by modifying the program at specific spots before sending it to the FV-1. All programs were identical at the very beginning, so you could know what byte to tweak to change a register value.  Curious. But I can't find it anymore.... my memory is getting bad.

[niektb]

Another technique:

http://www.muzique.com/news/adding-memory-to-the-fv-1-reverb/

regards, Jack

Very clever idea Jack! Especially with an AVR controlling the I2C addresses! It would be fun to pair this with a ATTiny85 that has a USB interface!

[Digital Larry]

Great. Teensy might be able to handle the slave I2C without timing issues, give it a try.

Changing gears for a second, I recall a project I found long ago that was handling the presets by modifying the program at specific spots before sending it to the FV-1. All programs were identical at the very beginning, so you could know what byte to tweak to change a register value.  Curious. But I can't find it anymore.... my memory is getting bad.

I'm a little skeptical.  They say that it is really meant to interface with another Teensy running the matching "master" code.  I'm not sure I want to hang the project up on account of my ability or lack thereof to develop EEPROM emulation.  I've got a PCB in the works with 4 spots for 24LC32A and I think I'll add two more just for laughs, assuming I have enough GPIOs left.  I think that all you can do on these chips is to have one address pin routed to a GPIO.  If that pin is high, then that EEPROM is not selected because AFAIK the FV-1 only has the ability to address a single 24LC32A on its I2C bus.

Regarding tweaking the code as a way of managing presets... hmmm... strange.  Not sure what benefit that offers.  Not even gonna try to wrap my head around it.  I guess that would relieve you of having to generate voltages.

I now have a C# program that is capable of doing serial communication with the Teensy, e.g. so I can send it codes and settings via USB from my PC.  What's cool is that Teensyduino has a device setting which is "Serial + MIDI" so I can do both at the same time.  I'm going to see if I can get this to upload a BIN file and program a 24LC32A from it.  Don't see why that won't work.  What is also cool (for me) is that 1 week ago I wasn't thinking about any of this.  I guess I hadn't realized how easy all these libraries make things.

With a Teensy board it will be so easy to make a small thing with 8 or 10 pots to generate MIDI controller or OSC messages.  I like knobs better than mice and although touchscreens are OK I still prefer knobs. 

[amz-fx]

DL,

Get a 1P8T rotary switch to select which of the 8 memory chips is active. The common pole of the switch is grounded and the separate 8 poles go one to each chip's pin 1 to make them active in turn as the switch is rotated. Every memory chip's pin 1 will need a pull-up resistor. The switch is only $2 from common sources like:

https://www.pedalpcb.com/product/mini-1p8t/  OR   https://www.adafruit.com/product/2925

No programming. No micro. No potential for clock noise interference or aliasing.

regards, Jack

[phstomp]

I published all the code in github: https://github.com/n3ws/fvduino

Currently only the Spinsemi demo programs are included. I could add
the programs from https://mstratman.github.io/fv1-programs/ if that
is OK.

@Digital Larry: I'm ordering some FV-1 chips. Are you still interested
in obtaining a prototype or you will rather roll your own? It will take me
at least a month to have something ready. I still have to learn how
to do hot plate solder reflow, and there could be unexpected issues
with the new PCB.

Flashing the board is done with FTDI Usb programmer such as this:
https://www.banggood.com/Geekcreit-FT232RL-FTDI-USB-To-TTL-Serial-Converter-Adapter-Module-Geekcreit-for-Arduino-products-that-work-with-official-Arduino-boards-p-917226.html?cur_warehouse=CN&rmmds=buy

So, you would need to open the pedal for adding patches. Maybe
not the level of convenience that you were looking for. Also, the
workflow for getting your own programs in is as follows:
compile FV-1 program to bin -> compress -> include in header file -> recompile -> upload to board

The 8 preset limit exists because I could not be bothered
to think more color palettes for patches. Also, with one foot switch,
even 8 presets gets a bit tedious if you need to go 1 preset backwards
(7 foot presses).

The digipots work so that both full wet and full dry with boost are possible.
The granularity of the pots 1 db, which may not be fine enough for some
uses.

[phstomp]

Schematic added to github. This version is not tested yet,
but the only changes are in the audio path, not in digital parts.
Please feel free to comment. According to the D1881 datasheet,
there should probably be op amp buffers after the digipot,
but I'm a bit reluctant to add another chip to the board.

[Digital Larry]

Thanks for sharing that.  For some reason I looked at the DS1882 which wants split supplies.  Have you used the DS1881 in this application before?  Does it work OK?

[phstomp]

Yeah, I'm using 1881 currently, works fine. No changes there in this revision. It needs that op amp buffer in VREF though.

[free electron]

DS1881 has an end to end resistance of 45k according to the datasheet.
10k input Z will load it and change the taper. You could scale up the R9+R10 and R14+C14 to minimize the load.

Not sure if i'll have time to finish it, as FV1 is not really on the top of my list today, but i had this idea of using one of those ESP8266 boards for something useful:
- using ESP12E module with 4MB of flash.
- made 1MB LittleFS partition for files
- wifi AP + web server
- using examples tested functional file upload via website

So the plan would be to have a web interface to program the FV1, maybe a grid of 16 squares where you can drag and drop the hex file + a drop down menu to choose one of the 8 programs inside a bank. 16 banks 8 programs each gives 128 "patches".
The software would receive the hex file, save it on the disk, convert it to bin, remove the hex to save disk space. Choosing the patch would be done by a drop down menu, set of buttons or something else, setting a new value would grab 512 bytes from the file, set up the buffer, toggle the pin to init reload and bit bang the I2C slave to the FV1. I2C on the 8266 is software only, so there are already useful functions/macros built it. Maybe it would work with the stock i2c library, haven't tested it yet.
Next step could be to add 3 pwm outputs or a digital pot to control the FV1 params via sliders on the web interface.

Having the FV1 pedal sitting in the pedalboard with all other gear and controlling it remotely from the dev machine when you write the code - now that would something very useful.

[phstomp]

@free electron: Thank you for comments. What values you would suggest for
R9+R10? I guess the op amp buffers would also do the trick.

[Digital Larry]

DL,

Get a 1P8T rotary switch to select which of the 8 memory chips is active. The common pole of the switch is grounded and the separate 8 poles go one to each chip's pin 1 to make them active in turn as the switch is rotated. Every memory chip's pin 1 will need a pull-up resistor. The switch is only $2 from common sources like:

https://www.pedalpcb.com/product/mini-1p8t/  OR   https://www.adafruit.com/product/2925

No programming. No micro. No potential for clock noise interference or aliasing.

regards, Jack

Hi Jack, that is a cool idea but it doesn't let you save presets with knob and mix and volume settings.
My goal is to really have something that is optimized for patch development and review.

It will not be:
- optimized for cost
- optimized for stage use
- guaranteed not to fall apart
- available in stores, online, or anywhere!  (for now)

Here's the idea - I develop a bunch of patches with SpinCAD but I really have to live with them and play them to know which ones will really work.  So there's a button press combo that marks a given preset as a "fave" which increments a counter in the record for that preset.  After while I look at the presets' "fave" counts. and free up space for new ones from the ones that I don't like as much.

Also, dialing in the control range for a patch can be a challenge.  I have a reverb patch with the control knob going in but the magic zone is really about 0.6 and up.  So I just need to limit it to that.  It's not really practical to iron all this out just using the simulator in SpinCAD.

@phstomp thanks for the offer on the boards, I am having fun coming up with my own thing based on my own thoughts... even if I never get around to doing it.  I mean, I think I will.  Reflecting on it, the main reason I stopped building the first FV-1 board I made was those darn SOT23-5s I picked out.  Whoo those are small!

[free electron]

@free electron: Thank you for comments. What values you would suggest for
R9+R10? I guess the op amp buffers would also do the trick.

Buffers would be ideal, but making the resistors 10x (100k + 270k, lower the feedback capacitance to get the same -3dB point) would improve the original log taper of the pots.

I have been playing more with the esp8266 based remote solution.
What i have for now is:
1. ESP12E module, partitioned as 1MB for the MCU firmware and 3MB as disk space for the web server and hex files.
2. Working web server with hex file upload and a row of buttons.
3. Once uploaded, any of the listed hex files can be "enabled", which means:
    - hex file will be parsed, checked if it really a hex file for the FV1 (always the same length)
    - intel hex has a checksum built in, that gives additional verification of the file
    - bin data is extracted and put into 4kB buffer, ESP8266 has enough RAM to keep all 8 patches there

The next step will be to handle the row of 8 buttons. Each press will set up the read address in the BIN data buffer and pass it as starting read address for the i2s slave. And then to get the i2c slave to work with the FV-1.
Haven't tried it yet, but i think the upload should also work with curl - so the whole process of building and uploading can be automated using scripts.