Author Topic: EEVblog #858 - Red Pitaya  (Read 24969 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29983
  • Country: au
    • EEVblog
EEVblog #858 - Red Pitaya
« on: March 08, 2016, 01:14:14 am »
Dave tries to get the Red Pitaya up and running and doing some basic measurements via WiFi & Ethernet.
TLDR:
Many issues: apps freeze, WiFi didn't work, and the apps have only very basic rudimentary functionality. But it's promising, and probably a good solution for those who want to write their own custom (internet enabled or remote) apps or learn FPGA programming, or do custom SDR stuff to 50MHz.
Those that want an out-of-the-box DAQ scope/wavegen/spectrum/network analyser combo tool are better off with the Analog Discovery.

 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 1592
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #1 on: March 08, 2016, 02:45:39 am »
Why the funny name?  I feel like I'm missing a joke or something?
??
https://en.wikipedia.org/wiki/Pitaya
 

Offline smithnerd

  • Regular Contributor
  • *
  • Posts: 101
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #2 on: March 08, 2016, 02:49:15 am »
I suspect Dave would have had better luck if he started with a fresh download of the SD card image.
 

Offline Smokey

  • Super Contributor
  • ***
  • Posts: 1592
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #3 on: March 08, 2016, 03:15:18 am »


Wow... Nice "hardware"!
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 29983
  • Country: au
    • EEVblog
Re: EEVblog #858 - Red Pitaya
« Reply #4 on: March 08, 2016, 03:40:33 am »
I suspect Dave would have had better luck if he started with a fresh download of the SD card image.

Watch the extended version, I looked at that, I had the exact same version as the latest on the website.
 

Offline smithnerd

  • Regular Contributor
  • *
  • Posts: 101
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #5 on: March 08, 2016, 04:01:39 am »
I suspect Dave would have had better luck if he started with a fresh download of the SD card image.

Watch the extended version, I looked at that, I had the exact same version as the latest on the website.

I will do. Looking at the source code on their website, I see it boots a debian derived Linux image from the SD card, but runs it from a RAM disk, so it doesn't retain any state. That seems like a good idea for a device like this.
 

Offline jamie_1318

  • Newbie
  • Posts: 2
  • Country: ca
Re: EEVblog #858 - Red Pitaya
« Reply #6 on: March 08, 2016, 04:11:00 am »
I bet you had to use the IP address for the wifi in order to browse to the device's website when using wifi. The go button should probably choose the network you actually used to connect it to the web site but I guess they haven't implemented that yet.
 

Offline jeremy

  • Frequent Contributor
  • **
  • Posts: 909
  • Country: au
Re: EEVblog #858 - Red Pitaya
« Reply #7 on: March 08, 2016, 04:24:04 am »
I have used this device extensively, although not in the past year or so. As others have mentioned, it is extremely capable hardware let down by poor documentation and software. However, it is definitely a DAQ/DSP unit and not an oscilloscope (at this stage anyway), and you better learn/know how to write HDLs if you want to do useful things. If you want an oscilloscope, buy an oscilloscope.

Some of this may have changed, but a major problem is that there is no schematic. When I was using it, the uboot port was ancient as well as the linux kernel, and I actually tried to get some patches mainlined for uboot via the xilinx repository so that the device would not have some of these weird bugs that should have been fixed. The patches were accepted, but I couldn't mainline my BSP for the board because the design wasn't open enough (iirc). Also, the ethernet chipset they are using is not supported by mainline uboot, so you have to give up ethernet booting if you want to use the latest version. I believe this is due to some licensing problems. In the end, I had mainline uboot and mainline Linux 3.18 (i think, whatever was the latest at the time) running on it with debian and it was quite a neat platform.

The final issue I had with it is that I couldn't get the data out of it fast enough; I really wish it had a USB3 connection, or that those SATA connectors were actually SATA.

Also the thing gets pretty hot.

Frankly, I suggest that you completely ignore all of the software that comes with, and instead use it as a Zynq dev board with two fast converters, for which it is a splendid device. I only wish it came in Cyclone V form...

As a minor side note, in the video it is mentioned that there is also a 12bit 1MSPS ADC on board, this is actually part of the Zynq and not anything intrinsic to the red pitaya
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #8 on: March 08, 2016, 08:08:43 am »
Frankly, I suggest that you completely ignore all of the software that comes with, and instead use it as a Zynq dev board with two fast converters, for which it is a splendid device.

I would have used it like that, using the two "external digital" connectors connected to the Zynq. Unfortunately the distribution of GND pins was dreadful: too few even thought some connector pins were unused, all at one end of the connector rather than being interspersed with signals.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline station240

  • Supporter
  • ****
  • Posts: 863
  • Country: au
Re: EEVblog #858 - Red Pitaya
« Reply #9 on: March 08, 2016, 08:13:12 am »
Funny I came across this device earlier today when I was searching for something, was planning to look at it.
Guess this answers many of the questions I had, so big thumbs up.  :-+

Lucky the fail button wasn't within reach, would have a flat battery and broken switch by the end of this video.
 

Offline atcurtis

  • Newbie
  • Posts: 3
  • Country: us
    • Making
Re: EEVblog #858 - Red Pitaya
« Reply #10 on: March 08, 2016, 09:02:45 am »
I have found that the Red Pitaya is really sensitive to the wobbles in the power connector so probably when you were lifting up the device, it caused it to reset and reboot. I have been tempted to stick in a big cap.

I didn't like the look of the "pro" apps either so I didn't purchase them. I'm hoping that third-party devs will develop a more useful scope app.
 

Offline G7PSK

  • Super Contributor
  • ***
  • Posts: 3644
  • Country: gb
  • It is hot until proved not.
Re: EEVblog #858 - Red Pitaya
« Reply #11 on: March 08, 2016, 09:30:41 am »
Why the funny name?  I feel like I'm missing a joke or something?
??
https://en.wikipedia.org/wiki/Pitaya

I think it must stand for "Pain in the ass for you all" :-DD
 

Offline Zbig

  • Frequent Contributor
  • **
  • Posts: 856
  • Country: pl
Re: EEVblog #858 - Red Pitaya
« Reply #12 on: March 08, 2016, 10:11:35 am »
Dave, you don't have to right-click and choose "Open in new tab" on webpages; just "mouse-wheel-click" or CTRL-click on a link.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #13 on: March 08, 2016, 10:56:25 am »
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.
« Last Edit: March 08, 2016, 11:02:05 am by Howardlong »
 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 1902
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #14 on: March 08, 2016, 01:24:26 pm »
 The one in the "Nice hardware" graphics has a heatsink on the main chip - Dave's does not. Did they stop supplying that, or did Dave get one without by mistake, or is it an optional extra cost item? Or do they figure the aluminum case is sufficient? Still seems too little based on the temps you are seeing. Did anyone else notice the clear acrylic case has openings and mounting holes for a small fan? Can't be trapping that heat and melting the plastic...

 This seems like it could be a really interesting cross domain development platform, but it just isn't quite all the way there yet. A shame, because it does look quite neat in terms of capabilities.

 

Offline D_Dub07

  • Newbie
  • Posts: 1
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #15 on: March 08, 2016, 02:28:49 pm »
Dave, I'm guessing the WiFi didn't work because you had entered the wrong MAC address? The WiFi dongle and built in Ethernet should have different MAC addresses, and in the video you mentioned you entered the same MAC address.
 

Offline signals

  • Contributor
  • Posts: 17
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #16 on: March 08, 2016, 03:01:05 pm »
The one in the "Nice hardware" graphics has a heatsink on the main chip - Dave's does not. Did they stop supplying that, or did Dave get one without by mistake, or is it an optional extra cost item? Or do they figure the aluminum case is sufficient?

I believe Dave said in the video that the aluminum case presses against the chip to act as heatsink. So, the separate heatsink wouldn't be compatible with the aluminum case.
 

Offline RGB255_0_0

  • Frequent Contributor
  • **
  • Posts: 774
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #17 on: March 08, 2016, 03:39:16 pm »
Micro USB/Micro-B need to die. The sooner everything moves to USB-C the better.
Your toaster just set fire to an African child over TCP.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1758
  • Country: ch
Re: EEVblog #858 - Red Pitaya
« Reply #18 on: March 08, 2016, 03:50:09 pm »
Dave, I'm guessing the WiFi didn't work because you had entered the wrong MAC address? The WiFi dongle and built in Ethernet should have different MAC addresses, and in the video you mentioned you entered the same MAC address.
You probably missed that at some point one could see that the website mentioned that you had to enter the ethernet MAC address in all cases.

Envoyé de mon SM-G920F en utilisant Tapatalk

 

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 1902
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #19 on: March 08, 2016, 04:03:53 pm »
The one in the "Nice hardware" graphics has a heatsink on the main chip - Dave's does not. Did they stop supplying that, or did Dave get one without by mistake, or is it an optional extra cost item? Or do they figure the aluminum case is sufficient?

I believe Dave said in the video that the aluminum case presses against the chip to act as heatsink. So, the separate heatsink wouldn't be compatible with the aluminum case.

 AH. I didn't watch the whole thing, after seeing the freezes and some of the other software fails, I sort of stopped paying attention. I didn't notice anything inside the lid that would touch the chip.


 

Online HwAoRrDk

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #20 on: March 08, 2016, 05:00:26 pm »
I'm not surprised Dave had problems with the various graphing 'apps'. It boggles my mind that they would even consider doing real-time data visualisation stuff like that on a web-based system. Crazy. :wtf: :-DD

As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all. Sure, modern web browsers and HTML standards have all sorts of cool features these days, but I doubt any of it was really envisaged to be used like this. Trying to imagine how the graphing works has me thinking that they are probably using a canvas element (or perhaps SVG) for the graph, with a WebSocket channel or two for real-time streaming of the graph data between the browser and a dedicated server daemon running on the Red Pitaya. In that context, a problem like Dave was having with the scope 'locking up', but with the web page controls still being interact-able, could simply be due to the data stream for the graphing being interrupted.
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 12433
  • Country: cn
  • Power Electronics Guy
Re: EEVblog #858 - Red Pitaya
« Reply #21 on: March 08, 2016, 05:13:37 pm »
The one in the "Nice hardware" graphics has a heatsink on the main chip - Dave's does not. Did they stop supplying that, or did Dave get one without by mistake, or is it an optional extra cost item? Or do they figure the aluminum case is sufficient? Still seems too little based on the temps you are seeing. Did anyone else notice the clear acrylic case has openings and mounting holes for a small fan? Can't be trapping that heat and melting the plastic...

If you watch carefully in full HD, you will notice residual of silicone pad's oil. That means there was a heat sink, be the Al case or a separate piece of heat sink.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10122
  • Country: 00
Re: EEVblog #858 - Red Pitaya
« Reply #22 on: March 08, 2016, 05:19:05 pm »
I'm not surprised Dave had problems with the various graphing 'apps'. It boggles my mind that they would even consider doing real-time data visualisation stuff like that on a web-based system. Crazy. :wtf: :-DD

My first thought as well.... it's probably a good thing that he never got the WiFi working.

As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all.

I guess I should be impressed that the waveform display worked as well as it did, but ... the overall insanity of the system won't let me.

So many things could break at any moment. :scared:

« Last Edit: March 08, 2016, 05:23:50 pm by Fungus »
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #23 on: March 08, 2016, 05:27:58 pm »
I'm not a web developer (by choice!) but I thought HTML 5 was designed to allow all this kind of thing, replacing Flash for example.
 

Offline zaoka

  • Frequent Contributor
  • **
  • Posts: 374
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #24 on: March 08, 2016, 06:53:27 pm »
Dave,

You promissed to do "features" video of a new Agilent meter as well as teardown of another model that you have.

Please compare to Fluke 87V, how fast it settle, how fast it autoranges etc.. :)

Thanks and great video!
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10122
  • Country: 00
Re: EEVblog #858 - Red Pitaya
« Reply #25 on: March 08, 2016, 07:26:14 pm »
I'm not a web developer (by choice!) but I thought HTML 5 was designed to allow all this kind of thing, replacing Flash for example.

It is, but that doesn't mean it's simple or reliable.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17890
  • Country: nl
    • NCT Developments
Re: EEVblog #858 - Red Pitaya
« Reply #26 on: March 08, 2016, 08:00:17 pm »
As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all.
A simple solution is to stream the waveform display as a video feed to the web-browser. That way the web interface is no more complicated than a web page with embedded video.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline TubiCal

  • Contributor
  • Posts: 5
  • Country: de
  • Tube Tinker & Mad Musician
Re: EEVblog #858 - Red Pitaya
« Reply #27 on: March 08, 2016, 08:47:59 pm »
Watching your EEVBlog2 ExTended version....

I was thinking of buying that thing, as i read some nice elektor articles about it. Thanx to you, Dave, and also for your video(s) on this thing, as you just saved me much money :)

Next is: that builtin FPGA is not really accessible by the user....you need to cross-compile your code, according to the linked git-hup page by redpitaya...but that is only for ready to compile code. So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Why they come up with such a silly thing. Combining two complete different arcitectures and only (and also barely) supporting just one...?? But advertising the FPGA capabilities like they have their own IDE...WTF???!?

In fact they have nothing, beside that scratch rip-off "visual-programming" in which i haven´t found FPGA stuff...

Just tried to access this visual....blah...blah..got this:

Error: Connection was destroyed by application
    at /data/wyliodrin/startup.js:360:19
    at /data/wyliodrin/helpers/logger.js:100:24
    at /data/wyliodrin/node_modules/raven/lib/client.js:128:15
    at /data/wyliodrin/node_modules/raven/lib/parsers.js:27:9
    at /data/wyliodrin/node_modules/raven/lib/utils.js:166:36
    at fs.js:272:14
    at Object.oncomplete (fs.js:108:15)

hahaaa...obvious..i don´t have that board....but i wanna know if the FPGA will be accessible through this, if not BiGTime FAIL...

It looks to me like a complete "we don´t know what we´re doing" project.

cheers,
TC


Because Tubes run hotter than any 1/2(0nDUCK<>
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 369
Re: EEVblog #858 - Red Pitaya
« Reply #28 on: March 08, 2016, 09:09:45 pm »
Seems like a great piece of hardware hampered by immature software
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #29 on: March 08, 2016, 09:14:30 pm »
So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Vivado WebPack is free-as-in-beer for small Zynqs.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10122
  • Country: 00
Re: EEVblog #858 - Red Pitaya
« Reply #30 on: March 08, 2016, 09:19:32 pm »
As a web developer myself, I can only begin to imagine the hoops they must be jumping through just to get that kind of thing working at all.
A simple solution is to stream the waveform display as a video feed to the web-browser. That way the web interface is no more complicated than a web page with embedded video.

Nah. A display like that needs lossless compression and that would never work across WiFi/whatever - too slow.

And no, you can't invent special data compression schemes. It has to run in a standard browser with no plugins.

It's easy enough to find out though: Have a look at the page source and see if it uses an HTML canvas plus a whole load of JavaScript to download data. Anybody got one to look at?

« Last Edit: March 08, 2016, 09:27:28 pm by Fungus »
 

Offline TubiCal

  • Contributor
  • Posts: 5
  • Country: de
  • Tube Tinker & Mad Musician
Re: EEVblog #858 - Red Pitaya
« Reply #31 on: March 08, 2016, 09:33:48 pm »
So you need a FPGA IDE to utilize that thing ->  Vivado Lab Edition made by xilinx....with all their price-policy....No way.

Vivado WebPack is free-as-in-beer for small Zynqs.

Hmm, need to check for that, thanx :)

Done, looks cool.....need to test that!

Here´s the link if anybody is also interested in this:

http://www.xilinx.com/products/design-tools/vivado/vivado-webpack.html

I also found some measurements on how the ADCs perform...(not very low-noise within audio range)
sorry german only - check post 49 for F(t) plots (c&p doesn´t work properly so you need to go to #49 maually,sorry)

http://www.qrpforum.de/index.php?page=Thread&threadID=10089&pageNo=3

There´s also a guy who done a dev SD image to make programming easier...but not even something like a real IDE

http://pavel-demin.github.io/red-pitaya-notes/debian-ecosystem/
 

cheers,
TC
« Last Edit: March 08, 2016, 09:45:13 pm by TubiCal »
Because Tubes run hotter than any 1/2(0nDUCK<>
 

Offline sram

  • Newbie
  • Posts: 3
  • Country: us
Re: EEVblog #858 - Red Pitaya
« Reply #32 on: March 08, 2016, 10:21:23 pm »
This thing looks so cool. I really want one just don't have a use for it yet. If the SDR could go higher then I could use it right away.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #33 on: March 09, 2016, 01:12:32 pm »
I'll just throw a reminder to Australian readers of this thread that someone (unknown to me) is selling an Analog Discovery on Ebay at the moment. I bought something from them and I was happy with the transaction.

There's only one. http://www.ebay.com.au/itm/Digilent-Analog-Discovery-Circuit-Design-Kit-Oscilloscope-Logic-Analyzer-/231867995678?hash=item35fc68d61e:g:BmYAAOSwqYBWmhAv

Seller claims it is unused.

Its the old one, not Analog Discovery 2.

There is very little practical difference between the AD1 and AD2: (a) a variable rather than a fixed power supply and (b) fancy new case.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #34 on: March 09, 2016, 01:56:41 pm »
I order both Red Pitaya and Analog Discovery 2 , just to compare them and see if they can be used to do anything serious.
Red Pitaya looks very pre mature, but the web interface attracts me due to that i make a lot of remote control and measurements.

I can help you there.

As a useful bench instrument

The AD fits the bill, the software is the best I've ever used on any USB instrument, plus it just plain works, I can't ever remember having any problem with the software or the hardware. It includes LA, digital pattern generator, scope and signal generator, and all can be run concurrently. The only thing I recommend is to get the BNC adapter, using the differential inputs alone is quite restrictive, and suing the BNCs affords a greater scope bandwidth.

The RP is little more a toy as far as being a useful bench instrument goes. Unlike the AD, it's not plug and play out of the box, you will need to make up an SD card and fiddle around figuring out the device's IP address, for some reason it doesn't register with my DNS or resolve as a broadcast on my LAN. Being able to access readings remotely may be a useful niche use for the RP. I am fairly certain that in its current state as a bench instrument even a beginner will be disappointed. However, as an SDR I can see this being a good use case, although it lacks front end preselection filters which is likely to be a problem if used directly on HF. Just using my finger as an antenna on the Ch1 attenuator handbag connector, I can pick up MW AM transmissions. I can also see its value as a low-IF or ZIF as part of an RF system. As an SDR was perhaps the only time I've felt that the RP excelled in any way.

As a tinkering device

If you are interested in hard core development, have reasonable Linux dev skills and are patient, then the RP might be what you want, but unlike the AD it's an unfinished article. The hardware and core software seem reasonably stable, and there is out of the box a set of reasonably useful FPGA IP configs that you can use without even having to touch any FPGA dev tools: that in itself is worthy of note. But beware, the instructions on building a functioning dev environment are woefully inaccurate and/or out of date. Having said that, my own use case is using this as part of a one off OEM design and as such there was little point in reinventing the wheel when hardware like this is already available.

For programming, the AD offers an API, but I'm not sure what you'd want to do more than the excellent software does already. I am not sure how well it can practically be used for continuous sampling, an essential requirement for SDR use, but the facility to do so is discussed briefly in the SDK. That might be a nice project for someone!

Conclusion

Both devices can be used under Windows, Linux (x86 & ARM) and OSX. The AD is USB high speed and bus powered, whereas the RP is Gig Ethernet or WiFi with the right adapter, and needs its own power supply.

In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.
« Last Edit: March 09, 2016, 05:37:06 pm by Howardlong »
 

Offline yym

  • Contributor
  • Banned!
  • Posts: 23
Re: EEVblog #858 - Red Pitaya
« Reply #35 on: March 09, 2016, 02:05:19 pm »
I was looking for something like this, FPGA with ARM core + ADC/DAC , I'd prefer Alterea though.
This would be a very good choice if it was fully open, schematic, layout and whatnot.
Without, it is worthless.

Come on.. , the apps are useless, they tried to implement a sort of app store with licensing and demo/trials LOL, they failed big time.
Visual programming interface.... yeah, because that is what one wants to do with a GHz dualcore ARM FPGA ... write silly code in a shity graphical web interface, yup pretty much...

Just sell this as a development board, with open everything.

I would buy it, it is actually cheap compared to similar (more) professional boards.
 

Offline woox2k

  • Regular Contributor
  • *
  • Posts: 54
  • Country: ee
Re: EEVblog #858 - Red Pitaya
« Reply #36 on: March 09, 2016, 02:39:52 pm »
Dave, are you sure your router does not isolate wifi/cable clients from each-other in order to improve security (some routers do it by default) That would explain why you weren't able to connect to the device over wireless.
You cannot blame Red Pitaya for all the problems you experienced because it would be impossible to guess and work around every different network configuration some people might have. I do agree that using browser/ethernet as only way of using it out-of the-box is a very bad idea on it's own and there will be a lot of disappointed customers. Same thing goes for using all available screen space. Most people have different screen resolutions and it's user interface should be very flexible to fit them all. Fact that it runs on web browser makes it even worse because desktop API's are way more flexible.
Either way if one expects to sell a device that would work perfectly out-of-the box it should have it's own screen and input system to remove all problems that might occur while user is trying to connect to it. To make it short, most user friendly scope is a standalone scope  :)
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #37 on: March 09, 2016, 05:19:08 pm »
There is very little practical difference between the AD1 and AD2: (a) a variable rather than a fixed power supply and (b) fancy new case.

And, ISTR, the most important difference: a better USB connector.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #38 on: March 09, 2016, 05:24:33 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1201
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #39 on: March 09, 2016, 05:51:14 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.

Totally agree with both.

Your AD (python) curve tracer:
https://ez.analog.com/community/university-program/blog/2013/12/07/analog-discovery-bjt-curve-tracer-program
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #40 on: March 09, 2016, 06:22:28 pm »
In short, if you want a USB instrument with scope, signal generator, LA etc it's a no brainer, go for the AD1 or AD2. If you are a pointy head with lots of time on your hands and want to come up with the next big thing in SDR, the RP is probably the better choice.

I'd also look at the effectiveness of the AD internal scripting JavaScript library. It might be usable when making, say, a small ATE system or a curve tracer. I believe it also has a more conventional API for C/Python et al.

Totally agree with both.

Your AD (python) curve tracer:
https://ez.analog.com/community/university-program/blog/2013/12/07/analog-discovery-bjt-curve-tracer-program

Very nice!
 

Offline chris_leyson

  • Super Contributor
  • ***
  • Posts: 1294
  • Country: wales
Re: EEVblog #858 - Red Pitaya
« Reply #41 on: March 09, 2016, 06:29:36 pm »
One of the reasons I bought a Red Pitaya was because of the wifi interface, it eliminates another source of common mode noise, i.e. the USB or ethernet cable to your PC, I'm just left with cleaning up the power supply.

The HTML interface is a clever idea, no special software needed just a browser, it's a bit slow though but how else do get any useful data into an iPad, not through bluetooth, Apple made sure they crippled that.

Fitted a Sunon Maglev 5V 25x25mm fan onto mine, a pair of M2.5 cap heads will cut just enough thread between the heatsink pin fins so it won't drop off.

I have to check which Edimax wifi dongle I was using, some work and some don't.
 

Offline vodka

  • Frequent Contributor
  • **
  • Posts: 456
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #42 on: March 11, 2016, 07:58:15 pm »
Quote
The HTML interface is a clever idea :palm:
   

HTML is an language interpreted that is loaded over a browser who surely will be written with other  language interpreted (Net or java).
On resume, more slow than the horse's bad with more fails than a shootgun's donnybrook.

Code: [Select]
no special software  You change the snots by slobbers , you haven't got the physical sofware in property ,else they have your program at the cloud and you have that be connected permanently or else don't work.

I have never heard the board's Pitaya, but the first effect have been very wrong(SCAM) . I think that they go off  the clever.
 

Offline rx8pilot

  • Super Contributor
  • ***
  • Posts: 3513
  • Country: us
  • If you want more money, be more valuable.
Re: EEVblog #858 - Red Pitaya
« Reply #43 on: March 11, 2016, 08:02:01 pm »
Seems like a great piece of hardware hampered by immature software
Yes, I would love to see the FRA and LCR functions mature. In the meantime, I will be looking for more capable solutions for that.

Sent from my horrible mobile....

Factory400 - the worlds smallest factory. https://www.youtube.com/c/Factory400
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #44 on: March 11, 2016, 08:49:51 pm »
HTML is an language interpreted that is loaded over a browser who surely will be written with other  language interpreted (Net or java).
On resume, more slow than the horse's bad with more fails than a shootgun's donnybrook.

That is wrong in so many ways and on so many levels that it is difficult to know where to begin to correct it.

The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 12433
  • Country: cn
  • Power Electronics Guy
Re: EEVblog #858 - Red Pitaya
« Reply #45 on: March 11, 2016, 08:55:01 pm »
HTML is an language interpreted that is loaded over a browser who surely will be written with other  language interpreted (Net or java).
On resume, more slow than the horse's bad with more fails than a shootgun's donnybrook.

That is wrong in so many ways and on so many levels that it is difficult to know where to begin to correct it.

The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.

I think he meant HTML is interpreted by a browser, and the HTML is generated by a scripting language such as PHP, which is making sense.
The browser itself is obviously not written in an interpreted language. Java and MSIL are NOT interpreted language. They are called byte code. Also, C++.net can be compiled to native code.
 

Offline vodka

  • Frequent Contributor
  • **
  • Posts: 456
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #46 on: March 11, 2016, 09:44:49 pm »
Quote
The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.

Simply ,that is a design a pure conversational ,at Christian, the software is done a polling continually to the server. Now you imagine that connected at same time 10 k of users , the server collapse it.
Because as we saw Dave's video the software was freeze or went very low to load, due to a bad logic design

Quote
The browser itself is obviously not written in an interpreted language. Java and MSIL are NOT interpreted language. They are called byte code. Also, C++.net can be compiled to native code.

Java at the 90% is interpreted, when you compile the source java that is converted to OPCODE'S JAVA(no is the traaditional ASM) and when you executed the program the opcode's java are translate to real assembler machine in time-run. And the same with the .Net if you don't change the settings compiler.

Example interpreted language  :

       Spanish(native) to English(Language mid)  to Chinese(native)

Example compilated language:

    Spanish(Spain) to  Spanish(Cuba)
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #47 on: March 11, 2016, 10:08:19 pm »

Fitted a Sunon Maglev 5V 25x25mm fan onto mine, a pair of M2.5 cap heads will cut just enough thread between the heatsink pin fins so it won't drop off.


The one I've been using sounds the same, RS part number 7588204 mfg pn MC30060V1-000U-A99. They're bloody noisy when used with the acrylic enclosure!

Wireless, I have the prescribed Edimax EW-7811UN which I tried after getting it working on Ethernet, but after 3/4 of an hour gave it up as a bad job.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #48 on: March 11, 2016, 11:05:58 pm »
Quote
The major issue with responsiveness in a networked soft realtime application are the latency traversing the network stack, latency getting access to the PHY medium, latency traversing the PHY, and the corresponding issues in the server. Note that none of those depend on the application-level language.

Simply ,that is a design a pure conversational ,at Christian, the software is done a polling continually to the server. Now you imagine that connected at same time 10 k of users , the server collapse it.
Because as we saw Dave's video the software was freeze or went very low to load, due to a bad logic design

In which case it is nothing to do with HTML and nothing to do with implementation of HTML and nothing to do with the browser. It is the application.

No surprises there.

Quote
Quote
The browser itself is obviously not written in an interpreted language. Java and MSIL are NOT interpreted language. They are called byte code. Also, C++.net can be compiled to native code.

Java at the 90% is interpreted, when you compile the source java that is converted to OPCODE'S JAVA(no is the traaditional ASM) and when you executed the program the opcode's java are translate to real assembler machine in time-run. And the same with the .Net if you don't change the settings compiler.

For Java, no.
  • Java has always been JITted, which is a 30 year old technology developed by L Peter Detusch for Smalltalk.
  • And 15 years ago Java got significantly faster due to the Hotspot JVM technology developed for Self.
To understand the significance of Hotspot, consider that if the same techniques are applied to optimised C code running on processor X, then the code can run faster when running inside an emulation of processor X that is itself running on processor X. In other words, with Hotspot type techniques, an emulated processor+program is faster than the real processor+program. See http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

Obviously neither C/C++ nor C# can do that since they can only do staric opimisations based on what the compiler guesses the code will do. HotSpot optimises what the code actually does.

There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline blueskull

  • Supporter
  • ****
  • Posts: 12433
  • Country: cn
  • Power Electronics Guy
Re: EEVblog #858 - Red Pitaya
« Reply #49 on: March 11, 2016, 11:52:09 pm »
Java at the 90% is interpreted, when you compile the source java that is converted to OPCODE'S JAVA(no is the traaditional ASM) and when you executed the program the opcode's java are translate to real assembler machine in time-run. And the same with the .Net if you don't change the settings compiler.

Example interpreted language  :

       Spanish(native) to English(Language mid)  to Chinese(native)

Example compilated language:

    Spanish(Spain) to  Spanish(Cuba)

I think you underestimated how fast IL JIT can be. FYI, some super demanding programs are written in Java, such as Hadoop.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #50 on: March 12, 2016, 07:52:53 am »
I realise I'm somewhat of a Luddite, but I've yet to see any real world evidence, as opposed to contrived examples and a very few edge cases, that the profile based adaptive optimisation provides any gains in an overall sense compared to static optimisations.

We've had similar techniques in the database world for a couple of decades now, the main problem with these techniques is lack of determinism which is a serious frustration when troubleshooting particularly non-functional facets of a system. All that code you diligently tested is now doing something different, but not all the time. I'd much rather have a consistently slowly performing system to troubleshoot I can reproduce than one that sometimes randomly starts running ten or a hundred or a thousand times slower.

My point is that something you non-functionally tested in lower environments is more likely to behave differently in higher environments because it's virtually impossible to come up with a practical test matrix.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #51 on: March 12, 2016, 09:14:22 am »
I realise I'm somewhat of a Luddite, but I've yet to see any real world evidence, as opposed to contrived examples and a very few edge cases, that the profile based adaptive optimisation provides any gains in an overall sense compared to static optimisations.

That would be an extraordinarily difficult thing to do with a real-life application - how can you meanigfully compare, say, a Java application with a C application? In all such cases the quality of the libraries and application, the development timescale and availability of staff would totally dominate any results.

However, the key point about the HP Labs report, http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html is that it unambiguously shows the surprising power of HotSpot-class techniques. It destroys the ignorant prejudice that "Java has to be slow because it is interpreted".

I say "surprising" because they weren't looking for such a significant result. Some commentators have even described it as "accidentally becoming a viable C compilation technique", but I think that is overblown!

I've personally witnessed key portions of  an application-server based code become 3 times faster as Hotspot kicked in. BTW, as you know, realistically it has to be server based, not embedded!

Quote
We've had similar techniques in the database world for a couple of decades now, the main problem with these techniques is lack of determinism which is a serious frustration when troubleshooting particularly non-functional facets of a system. All that code you diligently tested is now doing something different, but not all the time. I'd much rather have a consistently slowly performing system to troubleshoot I can reproduce than one that sometimes randomly starts running ten or a hundred or a thousand times slower.

I'd argue that your system architecture's function must be insensitive to detailed timing delays, since that's what will occur in production. Of course, when benchmarking performance, it is vital to "warm up" a HotSpot JVM before doing the performance test, but that is neither difficult nor lengthy.

Quote
My point is that something you non-functionally tested in lower environments is more likely to behave differently in higher environments because it's virtually impossible to come up with a practical test matrix.

In that case the system architecture and implementation is badly defective, unless you restrict "differently" to mean "slower but still correct".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online rsjsouza

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: EEVblog #858 - Red Pitaya
« Reply #52 on: March 12, 2016, 01:08:25 pm »
It seems they have a business model focused on the Hardware and accessories (with some third party contribution), therefore saying that a closed hardware detracts from the product is way too narrow. One can argue one way or the other, but IMO the effort put into such compact DAQ must be rewarded in some way.

Also, developing a polished GUI is not an easy task, but the large number of drop-down menus, the large buttons, the apparent empty areas (for a desktop browser at least) and the "wheel" at the bottom are a clear giveaway they were trying to cater tablets or modern notebooks and their touchscreens.

I agree with others regarding the Wifi issues: it is really difficult to address all different configurations and their pitfalls, and I have the impression your router is getting in the way. This is traditionally addressed by FAQs and documentation, but it is not easy to do in a newly released product (which I think this is, but maybe I am wrong).

Interesting to see the design decision to go for a dual A9 core integrated into a FPGA - perhaps the compactness was a very important factor. In other times I would have never expected to see this combination simply due to the power density.

All that said, IMO the issues shown in the video (and corroborated by others) make the product unusable as a DAQ.
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #53 on: March 12, 2016, 01:26:01 pm »
I realise I'm somewhat of a Luddite, but I've yet to see any real world evidence, as opposed to contrived examples and a very few edge cases, that the profile based adaptive optimisation provides any gains in an overall sense compared to static optimisations.

That would be an extraordinarily difficult thing to do with a real-life application - how can you meanigfully compare, say, a Java application with a C application? In all such cases the quality of the libraries and application, the development timescale and availability of staff would totally dominate any results.

That's really part of my point.

Quote
Quote
We've had similar techniques in the database world for a couple of decades now, the main problem with these techniques is lack of determinism which is a serious frustration when troubleshooting particularly non-functional facets of a system. All that code you diligently tested is now doing something different, but not all the time. I'd much rather have a consistently slowly performing system to troubleshoot I can reproduce than one that sometimes randomly starts running ten or a hundred or a thousand times slower.

I'd argue that your system architecture's function must be insensitive to detailed timing delays, since that's what will occur in production. Of course, when benchmarking performance, it is vital to "warm up" a HotSpot JVM before doing the performance test, but that is neither difficult nor lengthy.

No I'm talking predominently about non-functional aspects, in particular systems running fast one minute and slow the next, frequently by orders of magnitude. One of the key facets in troubleshooting is having a consistently reproducible scenario. The problem is that stochastic methods like this bring indeterministic results (in terms of performance) that are frequently difficult to reproduce in a controlled environment. Also bear in mind that much of the time it is not even possible to test with real data in certain domains such as financial or other areas that include personally identifiable information.

Quote
Quote
My point is that something you non-functionally tested in lower environments is more likely to behave differently in higher environments because it's virtually impossible to come up with a practical test matrix.

In that case the system architecture and implementation is badly defective, unless you restrict "differently" to mean "slower but still correct".

Yes, that is why I said "non-functional". I am sure we've all been on the end of a phone to a call centre when they say "the system's running slow today", or when something unexpectedly takes longer than usual. As an end user, I'd much prefer to have something that consistently runs in, say, 5 seconds than something that runs in 1 second 95% of the time and a minute 5% of the time for example, even though the aggregated time in the latter case is less.

Anyway I'm now waaay off topic!
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4756
  • Country: gb
Re: EEVblog #858 - Red Pitaya
« Reply #54 on: March 12, 2016, 01:36:33 pm »
I am not sure what I did, but I spent three hours of my life today trying to get the WiFi to work. I did succeed, but in trying to document the steps, I ended up back at square one.

One of the confusing things I am sure is that after making certain changes to the SD card, such as adding the wpa_supplicant.conf, you need to reboot the RP a second time after the change. I am pretty certain I did this, as documented, and it didn't work, but having polished up my "penguin skills" (I love that!) and randomly pushing buttons and reading through dozens of mostly half relevant and out-of-date topics online, I got it to work.

In documenting my changes, I went back to a blank SD card, followed the instructions without my changes first, and it started working. so rather frustratingly now I have no clue what I did to get it to work.

Basically, though, I'll say this...

o Note that by default, the RP tries to work as an AP rather than as a WiFi client which confuses things
o After adding the wpa_supplicant.conf to the SD card from your main computer, don't forget to reboot twice.

 

Offline vodka

  • Frequent Contributor
  • **
  • Posts: 456
  • Country: es
Re: EEVblog #858 - Red Pitaya
« Reply #55 on: March 12, 2016, 07:08:10 pm »
Quote
It destroys the ignorant prejudice that "Java has to be slow because it is interpreted". In other words, with Hotspot type techniques, an emulated processor+program is faster than the real processor+program.
.

Simply is ilogical ,because when you emulated a processor always you need more RAM and ROM space furthermore with the the program loaded that is impossible that go more fastest than an original processor with the compilated program. Unless ,the computer that contains the emulated processor have more resources in RAM , ROM and the computation power . Then that is posible,but isn't fair play.

When i emulated Nintendo64 game in a AMDK6 went bad, even so with the updated graphic card,i had turned  off the sound because only heard beeps.

The Hotspot JVM programmed C++ and above Oriented to Object (So that God catch us  confessed ) :palm:
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10127
  • Country: gb
    • Having fun doing more, with less
Re: EEVblog #858 - Red Pitaya
« Reply #56 on: March 12, 2016, 09:02:48 pm »
Quote
It destroys the ignorant prejudice that "Java has to be slow because it is interpreted". In other words, with Hotspot type techniques, an emulated processor+program is faster than the real processor+program.
.

Simply is ilogical ,because when you emulated a processor always you need more RAM and ROM space furthermore with the the program loaded that is impossible that go more fastest than an original processor with the compilated program. Unless ,the computer that contains the emulated processor have more resources in RAM , ROM and the computation power . Then that is posible,but isn't fair play.

No. Read the HP Dynamo report before you repeat incorrect statements. Then you will be surprised, and finally you will understand your errors.

The subject under discussion is speed, not memory usage. There was sufficient RAM for all programs; ROM is irrelevant to this discussion. The same PA-RISC processor and operating system (HP-UX) was used throughout.

From the abstract: "the performance of many +O2 optimized SPECint95 binaries running under Dynamo [i.e. emulated] is comparable to the performance of their +O4 optimized version running without Dynamo.".  Think about that: the more optimised code running normally sometimes performed worse than the less optimised code being emulated. Static compilation of C code simply cannot be very efficient due to C language features (especially the possibility of aliasing). And if you don't believe/understand that, then you should discuss it with the High Performance Computing crowd that have been pushing machine performance professionally for half a century.

Quote
When i emulated Nintendo64 game in a AMDK6 went bad, even so with the updated graphic card,i had turned  off the sound because only heard beeps.

OK; that shows you don't know how to write emulators. Big deal. Fortunately other people do know how to write emulators.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf