Are you using this example http://arduino.cc/en/Tutorial/ChatClient? I’ll try to replicate your issue, but I need more information. Which version of firmware does your board have? Are you using an SD card? If that’s the case which image are you using?
Hello, I wrote a small program to test otherthan putty and have had better results connecting, still get nuisance problems. Now I have started streaming sensor data I have found that it slows the program to the point that it's not useable. I have set pin 13 to blink on e a second which it does nicely, but when I make a connection to the board this becomes on e every ten seconds ... I have placed debug code in my sketch and have that client.available() creates this delay???? is this really the performance of the board or am I missing something? If I add a wifi card to the board will I get better performance, otherwise I will have use a different board?
I think what you are missing is the subtle differences in programming for a micro-processor based Arduino and a System based Arduino.
The 400 Mhz performance of the Quark is more than enough to service many ethernet connection, poll sensors and blink an LED once per second - it's finding out how to do it which is tricky.
In processor based kits, such as Genuine Arduino UNO, your program has exclusive use of the processor, in a systems based kit, like Galileo (or Beagle Bone Black I think too?), you run under an operating system and your program is scheduled accordingly. You can still get the same great performance, but your programs need to know how to take advantage of the operating systems native calls and signals.
I think for more complex programs one needs to ditch the Arduino IDE and write native Linux programs, using one of the various Linux builds with the dev-tools included.
At first I was not using the SD card ... I now have a second board with a SD card, with the latest build from your downloads and latest IDE and have updated the firmware to the latest.
This has made no difference to the Ethernet connection. If I client.println("a string") ... it takes several seconds; what I have found is the client.available in the loop takes for ever to execute, near to 10 seconds at times!
So hoping that a wifi card would fix this; I have now got a wifi card fitted and have got it connected; then using the wifi chat program put a client.println("a string") into the sketch .. it also so takes forever, same problem.
SpiderKenny comments are noted. However, I cannot see how the Ethernet on this board is usable it is just incredibly slow, surely it is not designed like this? I've built a great project around this board and whilst the IO is slow my project can handle this; but I need to stream the sensor data, unless it can stream it properly I am going to have to bin these boards ......
I hope there is a way to improve this; surely the Ethernet doesn't run this slow?
The delay is caused by the function available. This happens because it is checking all the sockets and trying to restart the server for each one in file <Arduino>\libraries\Ethernet\EthernetClient.cpp. Another option is to modify the source to just check a specific socket.
I cannot reply for soMe reason, on paper I thought this board would be great but the performance is no good for use ... FYI it also seems to run fine for hours and days and then bricks itself ... All the LEDs go out on the board and the only way to recover is to power off and on
This board does have great performance.
Like I said in my earlier post, it's a matter of doing the right type of code for the board.
With the right code these boards could far outpace an ATMega based Arduino UNO.
The arduino headers and compatibility are there to get you going, and to help rapidly develop hardware interfaces, but you need to know what you are dealing with.
Most Arduino UNOs are mere toys compared to Galileo.
For example, I set up a Galileo to run as a 4 channel audio server, with an on board 20+20 W Amplifier, web interface, telnet interface supporting up to 16 clients, mp3 decoder in software (mpg123) and OLED display and it still has loads of capacity left.
I think that Intel didn't do a great job of explaining how far Arduino compatibility goes. To really get to the power of Galileo you need to drop down to Linux and work there, or you need to write your own Arduino libraries to get the most from the beast and still work in Arduino.
Hi SpiderKenny ..
I bought several of these boards based upon Intel's marketing that it can emulate an arduino ... but it does a really poor job of this; 10 seconds for a Ethernet poll .. that's not just disappointing I find that incredible that they did not know this and even then still went ahead with marketing it ... its not useable. I agree if I had time to learn how you would go about programming this then maybe its a great board ... but for now, I have a project that I had hoped this board would work for and it does not ... so now frantically assessing how I move forward.
When I read the marketing and specification I read into it as you state, heres a board that is not an arduino hobbyist board, but a professional board with from INTEL ... unfortunately its marketing is not correct!
Hi MushMan yes I think you're right, the materials don't do a great job of explain just what type of Arduino compatibility you get.
I'd just like to re-iterate that it's not the board that has poor performance but the Arduino libraries. You can always use the sources from the libraries to adapt into your own, with much better performance.
I think to develop this further with this board will be too much of a steep learning curve and take too much time ... basically we have developed a controller system and its already online with a client ... so perhaps very stupid on my part to have used this board ... but the arduino is not an option and I thought this was the professional solution ... so I am now reviewing the GHI boards ... IDE and language familiar and examples they have whilst frustrating to get working function fast and reliably .... so looking likely that this will be my end solution.
MushMan - I wish you good luck.
and I thought this was the professional solution
I think that's a valid point. Maybe it's too much of a heavy weight solution for your application? It has a full blown embedded linux subsystem after all.
Would you mind sharing a little about your end application, maybe the members here can help you along?
I have had a PCB board made for me that has 32 analog inputs 0..10v and 16 analog inputs 0..20mA with a MUX to select. In addition this board also has 6 analog outputs 0..10v controlled by SPI. Long term plan is to add more digital inputs and to have a single board made that has the controller integrated. For example the Galileo .. which seems unlikely now, however I am not being biased in selecting a solution, I need a solution that I can program, maintain etc
The PCB board is connected to a number of different sensors which my program then actions with the outputs. I then want to stream the readings, the control values to a server and also be able to send commands back ...
My program on the Galileo works well, although the IO is slow it was not a significant impact ... but when I added the Ethernet controls it became unusable, 10 seconds to poll the client.available ... and in addition and I have no idea why and how ... but the board bricks itself after running happily for a long time, days even weeks... all the LEDs go off on the Galileo ... has to have the power removed and returned to start it again? The process I am running is in the real world when it bricked itself the control stopped and it destroyed our process!!!!!
Hi MushMan So there's a couple of separate issues there.
First the ethernet - you are right, that's not good enough performance, even via Arduino sketch. You could report it as a bug and hope that it get's addressed, or reach out to the community to help develop a better solution for you.
As for the boards locking up after some days running. With the LEDs going out it seems to be entering the S5 Power state, so it is either:
- controlled shutdown from within Linux due to some unknown condition.
- power supply failure
- software glitch / exception
- over heating
Any of these is possible, however I don't suspect it will be over-heat, otherwise it would shutdown again very soon after being restarted. I don't suspect power supply failure or it wouldn't restart after removing/replugging the power. It is hard to track down this kind of issue, you'd need to set up some tests. I do suspect some kind of software glitch. Possibly memory leak or handle leak resulting in general exception. Just a guess though.
I'm sure you know already, but you need to decide if the cost of moving to a new platform (with all the uncertainty that will bring) is going to be less than the cost of resolving the issues on the existing platform. All I can say is that by the description of your application then I think the Galileo platform is a good choice and should be more than up to the job, and should be able to run with stability in the long term. Notwithstanding of course the usual disclaimer that Galileo is not certified for being sold into commercial applications (neither is any other Arduino UNO for that matter).
I did a 0-10V recording and playback system for some movie studios a couple of years back (camera tracking and replay, to be able to make the same camera moves over and over again). At that time I used a Cypress PSoC5 solution. PSoC is a unique platform that gives the flexibility of CPLD along with an Arm Core and hundreds of IO. You can build just about any interface (UART, I2C, SPI, I2S, CAN, IR, GPIO, LCD, Capacitive Touch and even host mode USB) all from it's built in 'Universal Device Blocks' and routing matrix, and it's development system 'PSoC Creator' makes it all drag and drop easy. This was all on a 66 Mhz core - so I'm pretty sure the Galileo at 400Mz should be able to cope.
*CORRECTION* I meant Client Mode USB for the PSoC5. Sorry!