Dave's out of the box experience was roughly like mine, although (a) I used the wired interface and (b) had the USB console running on first boot, so I avoided the WiFi nonsense.
I used a freshly made SD card, and it booted up right away.
My main use is to put it into a bit of one-off OEM gear, and as such I am developing stuff on it rather than using it as an instrument in its own right. However, of course before you start it's good to have a go with the apps. I couldn't get the built in scope app to work at all, it just flatlines. I can see the offset when I zoom in but anything more than that, zip, nada. The built in SA on the other hand worked. What wasn't clear is what you have to pay for and what you don't. I downloaded some of the Bazaar (maybe Bizzare?) apps including the online scope app which did work, but it took some time for me to realise these are different to the built in apps included on the SD card.
It does run very hot, 70C or so. My usual rule of thumb is if it's too hot to touch, it needs some more thermal management.
So, how is it for development? Firstly, the Visual Programming environment just didn't work. I used up my week's trial just trying to open up a non-working link, so I was hardly going to spend good money on a subscription. As Dave suggests, there's little point in the long term becoming depending on a propriatary playground dev environment anyway, but it would be nice to be able to flash an LED at least. It was not to be.
Then I tried to get a demonstration Python script to blink an LED. Surely that can't be so hard? Well for some obscure reason, rather than having a native Python app they decided to do it as a remote blinky using SCPI. I note now that the Python blinky code example has disappeared. Probably wise, it didn't work. But fear not, if you have a Matlab or Scilab they have a remote blinky for that. Please, the point of a blinky is to be simple in terms of deployment and function. The lowest common denominator if you like. Doing a blinky as a distributed application using a ton of irrelevant bloatware is rather self defeating under those terms.
So how about getting a cross-compiling toolchain working? Well, the instructions for a build environment simply don't work. Their Wiki, which you're directed to from their web pages, is for a significantly different and older distribution, one which used software rather than hardware floating point. It wasn't until some hours of investment I realised I'd been largely wasting my time.
To put this into perspective, it took my 25 hours to get a blinky in C built and working. Even then, I had to compile the code on the device itself. I've since got a working cross compiling toolchain working, but you have to use a mixture of out of date recipes and some random button pushing to do so, picking the right bits out of a pot pourri of instructions dotted about the internet. It turns out that you should be using the readme.md in the Red Pitaya github rather than the Wiki for making a toolchain, but the readme.md doesn't tell you how to get an IDE up and working. One other confusion is that when you clone the RedPitaya github using their instructions, not everything is downloaded. I had to download a RedPitaya master zip file and use that to get everything.
I have suggested to RedPitaya that instead of fannying about with pages and pages of recipes to make a toolchain (much of which is just wrong), they distribute a known working VirtualBox VM with a complete working toolchain including IDE for each SD build, plus any additional instructions for optional licensable software like the Xilinx stuff.
To say that my out-of-box experience was dissapointing from a development perspective would be an understatement. You need to be a fairly determined hardcore pointy head to get very far with the Red Pitaya, but it shouldn't have to be that way. One of the key development benefits is that the standard build has a set of pre-baked FPGA configurations suitable for many situations, so in many cases you don't even have to touch the Xilinx tools or hack any HDL. The website is fairly slick, but sadly that's just a veneer, there is a gaping chasm between the fancy website and the hardware especially in terms of development documentation and instrument software. The core is there, it's just not presented at all well for end users, either as instrument consumers or developer creators.
If you want a working USB bench instrument, the Analog Discovery (1 or 2) with the BNC board is without any doubt whatsoever is the way to go. If, on the other had, you have an awful lot of time on your hands, and enjoy tinkering endlessly with Linux, have a great deal of patience, and don't mind an endless game of rabbit holing mostly with dead ends, then you'll love the Red Pitaya.
Home
Help
Search
Login
Register
