Control LimeSDR via SPI using Arduino MCU

Hmmmmn … @Zack … I don’t suppose the 10 pin JTAG header connects to the SPI pads on the LMS7002M:

190 F30 SDIO IO_cmos1225
196 F28 SDO out_cmos1225 Serial port data out, CMOS
197 C29 SCLK in_cmos1225 Serial port clock, positive edge sensitive, CMOS
198 D28 SEN in_cmos1225 Serial port enable, active low, CMOS
199 E27 RESET in_cmos1225 Hardware reset, active low, CMOS level
?
I can see on the LimeSDR circuit diagram ref to JTAG and FPGA:

I can compile it for you during my free time if you promise to share your Arduino sketch with community ;). Just let us agree on the pinout.

I am talking about FPGA_GPIO (J12), not FPGA_JTAG (J11) you are referring to. It is possible to route J12 pins through FPGA to LMS7002M SPI pins. Or it is possible to make UART <-> LMS7002M bridge inside of FPGA; or I2C <-> LMS7002M bridge; or…

1 Like

Also guessing that when it comes to software the C driver may be a better fit for deeply embedded use:

Or maybe that’s too big for an Arduino (although the platform does range from ATmega, through ARM Cortex-M0 and up to full blown Linux systems where the sketch runs as a process).

1 Like

@Zack Fantastic! Yes, I’m more than happy to share the Arduino sketches. Let’s do it! I’ll let you decide where to put the pinouts on the GPIO headers. Please pm me the name and address to send the board and I’ll get it over to you by royal mail special delivery with return postage paid, or DHL/FEDEX if you’re not in the UK.

Thanks! :sunglasses:

Hopefully I can use some of the code in those files to get things working smoothly?

why do you want to use an arduino, when you have an FPGA?

Perfect!

OK

No need to send the board to me. I’ll provide a gateware for you and you just flash it to the FPGA (well, actually to the Flash memory).

1 Like

If you do not know FPGA stuff and if you want to do something simple, then it makes sense I think.

1 Like

From what I’ve read, programming FPGAs are a real pain in the proverbial whereas Arduinos and C++ are just pure fun. Personally, I’ll probably end up programming the FPGA eventually but just not right now if I can help it.

Oh … Much nicer! :relaxed:

Well, FPGAs are a different paradigm. In an FPGA you are literally fabricating logic to run bits around your board at the hardware level. This allows, for example, having instantaneous and asynchronous, non-clocked propagation of logic signals (concurrent logic); likewise, you can also build state machines running synchronously on some clock domain you define. FPGAs are the closest thing to the highest speed you can get, other than building a custom application specific IC (ASIC). VHDL (also Verilog) is literally a hardware definition language. Since you speak of building a PCB with these parts plced on it, you’ll need to know how to interface the electrical (things like: voltage, speed, controlling impedance…) and logical (terms like: gates, registers, clocks, domain crossing, buffers, buses, state machines, floor plans, ip cores, async and synchronous, etc.). And also the mechanical and thermal issues…

Whereas, C/C++ and other high-level languages intentionally seek to abstract and utilize various CPU architectures (bare-metal or hosted by an OS). If you have experience programming on micro controller platforms (say like an Arduino), you likely know about about getting close to the machine’s architecture - maybe directly doing things with peripherals like serial or parallel I/O via a memory mapped I/O, interrupts ISR, etc. If you know how to program in assembly language, then you have ultimate say about how things get implemented, although it falls to you to know how to precisely instruct the machine to use its hardware.

If you are doing this in the context of C/C++ on an OS (say a Raspberry Pi running some flavor of Linux) , then the abstraction is much more layered. The hardware is virtualized via the OS and requires some driver mechanism to access it, which is much more challenging to work with since it requires a lot of knowledge about the kernel, etc - AND the hardware (Multi-core, multi-threaded, ARM9, AXI / AMBA, memory blocks to keep stuff ordered… oh, my).

Finally, just to be a little more complete are things like GPUs and DSPs. The GPU is more familiar since they can be easily added to a PC platform (or already come with one). The GPU allows DSP to be done because it provides a really great way to do math quickly - specifically the Fast Fourier Transform (FFT), the work horse for efficient spectral analysis and convolution (filters). DSPs (like TI and Analog Devices) are dedicate CPU-like machines that are tuned for signals math such as FFT and filtering. These also have special direct memory access mechanisms to make the process very efficient/fast (Harvard Architecture, circular buffers, specially tuned instruction sets…).

So, now you can perhaps tailor your design toward the best approach for your spectral display project.

Sorry if that was too much of a response, I read the thread and thought I’d just offer a few things, however, my fingers just kept going… :>)

Cheers,
John

1 Like

@e2jw thanks for the info - it reads like poetry !

1 Like

Hello @TegwynTwmfatt,

So, promises from my side fulfilled.

Here you will find custom FPGA gateware, connection diagram as well as Arduino example sketch file on how to read/write LMS7002M registers.

Note please, that you have to use 5V to 3V3 voltage converters on outputs from Arduino. I’ve used 200 Ohm serial resistors for this purpose. Not very elegant way, but did the job. Tested with Arduino Duemilanove.

Let me know if you will have any questions.

Now is your turn :slight_smile:

1 Like

@Zack … Fantastic! … and an example Arduino sketch helps enormously … Thank you! :relaxed: Must dig out that logic level shifting chip that fell behind the radiator.

Arduino Due uses 3.3v logic…

It is 5V. No chance for Atmega to work at 16MHz and 3.3V supply. Check Due schematic for more info.

Here is another thought. For simple application like spectrum scanner or even simple audio transmitter/receiver it should be possible to program LimeSDR for standalone operation. Cpu within cypress is more than enough to control external display with touchscreen. And with some fpga aid it should even be able to handle audio codec connected through fpga gpio. Imagine shield board connected to limesdr with touch display and audio input/output. That would make truly portable software radio.

1 Like

@modimo … That makes sense to me! :slight_smile: There’s probably enough silicon inside the FPGA to custom build a cpu inside that as well or program it to perform the modulation/demodulation directly.

There’s already a CPU built inside it, a NIOS II :slight_smile: And also a GSoC project to replace that with a RISC-V core.

Definitely lots of potential for doing what you describe.

2 Likes

I was talking about the Arduino Due, which has a Cortex M3 processor and uses 3.3v logic, NOT the Arduino Duemilanove that you are thinking about.

But if you are willing to dive into FPGA programming, I admire your ambition. I don’t think my old brain is still functional enough to take on that level of education. Best of luck with your project!

John Toscano, W0JT