Needed information about FEZ Hydra I/Os performace

Archive
1

Dear Sir,

Is it possible to get an overview about FEZ Hydra I/Os performace in pure numbers? (tipical and abs. max. ratings):
(I’m using July 23rd beta release with .NET Micro 4.2 SDKs.)

-SD card write/read speeds? (e.g. Hydra with MicroSD Card Module with a Samsung x6 8GB cards, is there any preferred other SD card type?),
-SPI write/read speeds? (max. or tipical),
-I2C write/read speeds? (max. or tipical)
-‘K’ and ‘S’ UART write/read speeds? (max. or tipical)
-Analoge IN read speeds?
-PWM write performance?
-GPIO with interrupt r/w performace?
-normal GPIO without interrupt r/w performace?
-FEZ Hydra as a USB device r/w performce? (as I know it is not yet released for Hydra, so maybe an estmation based on the other similar mainboards)

Big thanks in advance !,
Péter

2

None of these tests are valid because this is a manage and interpreted system. As speed can be 200kbytes/sec burg then add some managed code to parse the file and speed will drop rapidly.

There is also RLP which makes a big difference.

Your question should be like, I want to do XYZ is this possible?

3

While giving an absolute benchmark is possible for each items, merging all your needs in the same application involves that performance will be impacted.

This is not due to the fact that it is managed code, this is a computer science law, even on our computer you can decrease drastically the performance of your USB or SD or anything else, if you are running an heavy signal processing tool due to limited memory bandwith, limited number of Gig op/sec of your processor and so on…

4

Dear Gus,
Our background: we have lot of (more than ten years ) experience of the following fields: .NET1.0, 1,1. 2, 3.5 and 4 on Win platform + real time electronic stuffs.
(e.g. focused on industrial high performance inkjet printing, non contact spectral colour measurements, general industrial automatisation: e.g. non contact temperature measurements, PID temperature control, motion control, micro fluid handling, etc. -I’m sure you can imagine: beside the electronic related tasks we have a lot a mechanical design and manufacturing, assembly, test and calibration work).

Normally we do the following (from the point of view of development, not related with NETMicro!): .NET WinXP/7 for GUI, bussiness logic, etc and we use Xilinx FPGA + lot of in-house developed hardware for real-time related tasks.

So, we just received FEZ Hydra and we love it basically (e.g. we managed to work it successfully for NON-Gadgeteer SPI based TFTs, other in-house tried and tested components like our FPGA based systems , 3rd party SPI and I2C based parallel FIFOs, etc.

Back to you question:
1., When we receive a new ‘platform’ or component the first step normally we do to test it carefully before we start the actual development (I mean with a real living project with a certain component or platform included). So, normally we would like to know what we have to hande with our real-time electronic parts and what we can expect from e.g. FEZ Hydra.

2., Actually: the planned first project with FEZ Hydra: to build a standalone measurement device with image sensor and flashing illuminant. (we have to syncronize the image sensor capture with our flash light at very low level).

This is the reason why we would like to get some more real (or tipical) numbers / details concerning the I/Os performance.
Another say: we are ready to design the real needed custom parts for a certain tasks (e.g. electronic handling of image sensor, flash, buffering memory for frames, etc.) but we have to know the Hydra part of it: as at the end-of-the-story we have to push datas for Hydra (for example to show it a display controlled by Hydra or sent it over usb or our WiFi modul).

If you have more pratical performace data (we love to read white papers) regarding FEZ Hydra, it’s should be a nice help for us.

3., Another say: from our development point of view: we can do everything (independently from Hydra), BUT: we would like to do as much as possible with Hydra because of rapid and easy development enviroment of Hydra/.NET Microframework.
All it’s about the time (and money) from our point of view.

If you want I can share some more of our next project details.

Thanks in advance,
Péter

5

Reply to: eforbanSenior:
Yes, we know the limitations of managed codes, as well the possibilities of unmanaged codes (in your platform should achived by RLP).

According ‘eforbanSenior’ absolute benchmark train of thought: yes, it’s trivial (except FPGAs :slight_smile: ), but to know the the ‘borders’ (I mean performance on a certain topic, without parallel tasks, e.g. use only one certain task in the main () ) we are able:

1., to design the system architect (in this case Hydra task and other/parts tasks)

2., more specially: to design what we have to do (outside of Hydra) with e.g.
-what we have write in C/RLP
-what we have to do with DaisyLink (maybe with a custom firmware)
-what we have to handle with our FPGA parts.

From easier (better to say in less time consuming) to more difficult -as we feel: RLP relative easy, DaisyLink is a more time consuming, and with FPGA programming and custom PCB design we are quite sure we can handle our tasks -BUT: before we start we would like to know which one to choose, not to make surplus job with something harder if we can handle it with an easier way.

Waiting for your feedback,
Péter

6

I suggest you give GHI a call and chat about this.

7

I don’t know exaclty how complex your application is, but to my opinion, if you already know that you’ll use a FPGA, why not using only the FPGA? I mean, even a small FPGA can handle now a microblaze, and you’ll find a tons of code to support SPI, USB, SD and myabe DaisyLink chains.

8

@ Gus - my Skype id is petersesztakpalettainvent. What do you think to disscuss it over Skype?

9

@ leforban - to handle all project details with fpga is illogical decision. Fpga is for real time, high performance tasks. E.g. to build gui, business logics of the software , and the maintainance of it much more easy with .net micro, I’m sure. So, concerning picoblaze soft processor: it’s 8 bit similar to microchip pic 18 series. It means performance and rapid development something far bellow of Hydra. Have nice day! Pèter