There has been some interest expressed in getting KD8CEC Nano Every (more memory, more flash storage, slightly faster) working with KD8CEC.

The challenge here is that the Nano Every only has 256 bytes of EEPROM and KD8CEC uses all of the 1024 bytes available on the Nano 3.0. (Enhanced CW Support, Keyer, VFO Memory, WSPR, etc)

The good news is that if you want a functioning radio, you don't seem to loose much functionality at 256 bytes (at least with the limited tests I have done). However, the uBITX Memory Manager will likely *not* work because the first thing it does when loading the EEPROM is ask for 1024 bytes and so it will timeout..

So there are two options here:
1. Add an external EEPROM  - I have done that and boards designs are available on github (see sig below) The latest commit has a NANO Every #define
2. Use a EEPROM to flash emulator - not done yet

In either case, you will need a new version of KD8CEC. And any work I do will be in the 2.0 (not 1.2) base.(others are welcome to retrofit to 1.2 of course)

The benefit with #2 is that this supports *existing* Raduino boards. So you buy a Nano Every (Mouser and Digikey have them in stock), Steps would be:
a. backup your EEPROM using  uBITX Memory Manager
b. Update the firmware to a version that supports this configuration
c. Plug the Nano Every in
d. Restore the EEPROM to the new configuration.

There are two problems with this approach:
1. The current flash emulators that I have found for the Nano/Nano Every require the EEPROM emulation space to be re-loaded after *every* firmware update. -hasn't been a lot of new KD8CEC firmware versions lately...
2. The flash emulators require an explicit "commit()" to update the emulation space to minimize EEPROM writes. I haven't figured out where to put such a statement and it is likely you will loose some features like setting things to "last VFO-A/B memory" on boot up.


I am not thrilled with the disadvantages of the EEPROM emulation software. And personally, I wouldn't go down that path. If I needed the benefits of a Nano Every, I would just give up the extra features of KD8CEC that dont fit into 256 bytes or go for an external EEPROM settup.  But, I have plenty of Raduinos of my own design running with an external EEPROM. So  I am not representative here.

So thought I would ask the community? Perhaps someone has found a better flash eeprom-flash emulation alternative?

73
Mark
--
AJ6CU
KD8CEC 2.0, Nextion Screens,  and open source uBITX Raduino boards for Arduino IOT, BLE, RP2040, Teensy
https://github.com/aj6cu

Another idea is to detect the size of the eeprom, and adjust what is stored/retrived accordingly. There is a lot of cruft in the 1024 EEPROM and there is *lots8 of additional space in the external eeprom. 

73
Mark
--
AJ6CU
KD8CEC 2.0, Nextion Screens,  and open source uBITX Raduino boards for Arduino IOT, BLE, RP2040, Teensy
https://github.com/aj6cu

On Sun, Nov 20, 2022 at 09:51 AM, Mark Hatch wrote:

So there are two options here:
1. Add an external EEPROM  - I have done that and boards designs are available on github (see sig below) The latest commit has a NANO Every #define
2. Use a EEPROM to flash emulator - not done yet

After reading the Nano every posts I decided to order one direct from the Arduino store. Looks like an interesting board with a second (more powerful? ARM) processor on board to program the 8 bit AVR chip. Might be some possibilities to take advantage there.

Somehow direct memory storage manipulation of the radio settings bothers me like self modifying code does. Although I've gleefully done both. However, in the "Every" case enough flash that a proper dictionary type parameter storage (along with some "cat" commands to modify them) could be implemented. 

What about using one of the cheap tiny SD card adaptors and a small capacity SD card? I believe if you don't care about speed only a very few pins of the SD card need to be connected. Probably enough flash on the Every processor to include a DOS file system, or just just treat the SD card like a serial storage device with no file system. Could even solder wires directly to a SD card if no file system and no need to ever remove it from the system.

Couple more observations about the Every. I'm surprised they did not include a crystal. They went all out and included additional fancy power management parts and a whole extra processor, why not another 10 cents for a crystal? (Maybe just a 32khz crystal and calibrate the main RC CPU clock and baud rates to the 32khz crystal on startup) I'm looking forward to playing with the Every, also bought the screw terminal board to go with it.

Also, I'm finding I like these AVR 0-Series chips with the single pin programming/debug interface. I've been using the tiny 8 pin versions for various projects, so will be interesting to have a Mega version of these chips. 

Tom, wb6b

Tom,

Thanks for your thoughts as you explore the Every. Had not considered a SD card since it wasn't part of the original Raduino desigh. But certainly an option. Think the main disadvantages is occupied space on the board and access (got to take the cover off).. Guess you could do a ribbon cable, but I am not RF smart enough to understand whether that could cause any noise in the radio (or not).

I have thought about the EEPROM libraries that offered a Python dictionary type access. I used dictionaries a lot in my python re-implementation of the uBITX Memory Manager. I avoided them originally because I was trying to minimize changes in the KD8CEC code until it got stabilized on new platforms. But if I start thinking about a re-organization of the EEPROM based on available size, it is certainly an option. The current way things are stored and accessed in EEPROM has been one of my headaches in the port. The READ/WRITE functions of EEPROM library will read a INT/LONG, etc. But when the size of an INT changes from 16 to 32 bits, the 32 bit platform gets a few extra extraneous bytes that can create interesting  bugs...

73
Mark
--
AJ6CU
KD8CEC 2.0, Nextion Screens,  and open source uBITX Raduino boards for Arduino IOT, BLE, RP2040, Teensy
https://github.com/aj6cu

On Mon, Nov 21, 2022 at 07:22 AM, Mark Hatch wrote:

Think the main disadvantages is occupied space on the board and access (got to take the cover off).

Interesting. I'd pondered the idea of just reprogramming the Nano in the uBitx to just be a slave I/O peripheral to another processor. Either connecting to the USB serial port of the uBitx Nano or directly to the serial pins of the Nano. For the latter you would need to take the cover off, but would only have two fairly low speed data lines to possibility need to put some RF bypass caps on.

The main thing is finding a generic, and not too bloated or specialized, protocol to communicate between the uBitx Nano and the second microprocessor that becomes the main processor. The main processor could be a small processor like the Every, an ESP32, Blue Pill or even a full fledged computer. 

I started to look at two things to as examples, or even to use directly. 

I recently upgraded my 3D printer to use Klipper. This is an example where the firmware on the printer controller is replaced by firmware that is simply a slave to the computer running Klipper; I'm my case a Raspberry Pi. The firmware just steps the motors as commanded by the RPi Klipper program and returns things like temperature to the Raspberry Pi. 

Another source of possible inspiration is the Adafruit Seesaw devices. The idea would be to program the uBitx Nano to act somewhat like a Seesaw peripheral chip.

Regarding Python. I've played with MicroPython on the ESP32 modules and the Raspberry Pi Pico boards. I like MicroPython. It would be cool to have a version of firmware/software for the uBitx written in MicroPython.

Tom, wb6b

Tom,

One of the advantages of the newer processors like the Arduino BLE is that they have wifi built in and a second processor that just manages networking. This definitely makes it possible for the radio to provide simple web commands, maybe even a full html content to control the radio without burdening the main processor. Not sure if i will ever get around to it, but I thought it was an interesting idea (assuming the wifi didn't cause RF issues...)

73
Mark
--
AJ6CU
KD8CEC 2.0, Nextion Screens,  and open source uBITX Raduino boards for Arduino IOT, BLE, RP2040, Teensy
https://github.com/aj6cu

Hi,

My Every arrived, below are a couple of photos, including the Arduino screw terminal adaptor board, and a Nano clone for comparison. 

-- Just noticed, the Nano clone board has been sitting in a box and it looks like my cat may have lounged on it. As is looks like a number of cat hairs showed up in the photo. Oh well... --

Best I can tell Arduino managed to make the pinout and pin names identical. The Every fits in the same sockets as the old Nano. So looks like hardware wise, a drop in replacement. Great in the case of upgrading a uBitx.

The AVR chip now has 48 pins vs. the old Nano with 32 pins. So there may be some extra I/O that could be harvested, if you wanted to bother with hacking the board. 

There are some pogo pads on the back side. Hopefully, those are for reprogramming the ARM chip, for those people that might want to hack the second processor with their own code. 

-- Re: uBitx.
The main reason I'm interested in just reprogramming the Nano on the uBitx to be a dumb slave I/O device is the Nano fits in the socket and doesn't require building adaptor boards or cut and jumpering odd cables to another processor. 

Even in this parts shortage, the processors are too inexpensive to try to have only one processor in a design. However, the Every, because it looks like Arduino has tried to make this a direct plugin replacement, for those folks that don't have a directly soldered in Nano, the Every looks like it might fill the bill for a simple (on the hardware side, anyway) upgrade processor.

By, in essence, turning the uBitx into a simple I/O device (Serial interface or like an I2C chip [a physically very large I2C chip, none the less]), you can use a whole variety of chips to control the uBitx to create what the user sees as the radio. The ESP32 modules would be good because they can do Bluetooth and WiFi, as well as they have enough resources to run MicroPython. That would be a great way to program a uBitx that could be run on different processors with potentially very little porting of the code. 

Thinking about the previous comment regarding the RF noise of a WiFi capable processor in the uBitx enclosure, the ESP32 could be located in a shielded area of the case or outside in plastic covered case/dome/window to let the WiFi signal work. 

Anyway most upgrade solutions to the uBitx seem to focus around replacing the Nano board. I think just relegating the original Nano board to being a simple I/O device with a second processor taking over the main functionally is a viable solution that does not require designing adaptor boards or cutting things up on the uBitx board. The Seesaw protocol might be a good, already supported with client libraries, protocol to adapt to talk between the main and slave (the old nano board on uBitx) processors. 

Tom, wb6b

------
-
------

On Tue, Nov 22, 2022 at 06:41 AM, Mark Hatch wrote:

One of the advantages of the newer processors like the Arduino BLE is that they have wifi built in and a second processor that just manages networking.

Interesting. I missed knowing about this Arduino board. Yes, plugging in this processor to a uBitx might be another really good upgrade solution. My Nano is directly soldered in on my uBitx, might actually get out the soldering iron and install a socket to try out this board. Maybe the BLE power level would be low enough to not be an issue with the uBitx receiver. 

Tom, wb6b