for a personal project I would like to wirelessly connect several self made thermostats to a central node. The thermostat design is almost finished. I’m planning on using the RFM69C modules (successor of teh popular RFM12B, SPI) for that. I would like to have logging capability in the central hub (SD card) and network connectivity. Over the network I plan to send data for logging remote and be able to control the thermostats through some kind of web interface. The end idea is to control the thermostats on a smartphone. Call me old school but I prefer a wire. The central node will be next to my router/switches anyway. This setup has been spooking through my head for a while. Originaly I thought of the Pi and lately even of the Pi with W10 IoT. But then again, the Pi has a desktop OS known to destroy the SD card after a while unless special measures are taken which would require me to dig into an OS I’m not that familiar with. W10 IoT is more marketing at the moment and I don’t want to wait for a community to build up, remember I have to write RFM69C support (driver or whatever). Arduino on the other hand seems a bit lightweight. So I ended up having another look at NETMF on which I gave up a couple of years ago.
My questions:
[ul]Hardware wise the FEZ Cerbuino Net seems to match my needs. Am I correct in assuming that the processor has 3 SPI interfaces, one is used for Ethernet, one for the SD Card and I could use the third for the RFM without having to worry about sharing the SPI? There won’t be any conflicts in this?[/ul]
[ul]I’ve been reading the last couple of days about the NETMF, my knowledge was a bit rusty. I do know my way around .NET and .NET CF though. Originally I gave up on NETMF because of several issues of which I remember networking was one. It seems this still isn’t completely solved. I read all kind of topics (maybe old ones) about freezing devices, watchdogs, aborting threads, but nothing seems like a real working solution. I’ve also read about the Netduino.IP but my gut feeling says not to trust on that one. (Maybe because of this: Split: Waiting on Netduino.IP preview builds - Netduino.IP Technical Preview - Netduino Forums ) What is the current status of the network stack? Have those issues (are they described somewhere) been solved or can they be reliably worked around? Could I run into them? [/ul]
Based on our experience I would not go with a gadgeteer model. There are significant limitations that you would not experience with a Pi or other ARM based board (Beagle board).
Just getting some of these boards up and running is a real headache.
@ LukeG
I assume you are referring to your experience in your other post? If not could you elaborate on what limitations you are talking about. I mean apart from the obvious differences in HW and SW (NETMF vs full blown desktop OS)
I have professional experience in developing drivers for Windows CE, C# desktop and compact framework. I however have almost no experience in Linux. So creating a low level hub, with some basic networking and a RFM69 ‘driver like support’ seems easier on NETMF for me. I know it can be done on the Pi as well, I have no doubt about it, I just think the challenge is easier on NETMF. (Also bearing in mind the long term stability, although that would be possible on the Pi as well, disable logging, going to RAM FS, thinking of backing up the changes because of that, …)
I would like to use Cerbuino NET. It has SD, ethernet and SPI.
If possible, I just would like to know if anyone can inform me on these. I just think it’s better to ask beforehand instead of having to find out myself:
[ul]How is the network stability. Are the issues completely solved, what can I encouter?[/ul]
[ul]Can I use the SD, ethernet and SPI at the same time, or does one exclude the other?[/ul]
[ul]Forgot to mention in the first post. I would also like to use UART at the same time[/ul]
@ Jef Patat - Since you are using a different part, you may have a different experience.
First, the stability of the Hydra has been questionable from the start. We started with Rev 1.2, and then 1.2b, 1.3, and now trying Hydra+ Rev 1. We have had significant problems with each revision, and it always takes a lot of digging to find the solutions. You can see from my other posts that between each revision there were changes not noted anywhere in the documentation. We also received no sort of end of life notice about the Hydra board. It is very easy to brick the board, and if you just forget a pull up resistor on the SPI MOSI you can put it into the bootloader mode. This was a huge headache for prototyping.
To address your questions:
Network stability - we built a prototype with the Hydra and the ENC28 ethernet adapter. We found this was not stable, and had limits (no HTTPS, no SNMP v3). Now we use the Hydra as the device controller, and a separate PIC processor to handle the web server. I would certainly not advise the gadgeteer model for IoT type projects. You said yourself the networking issues don’t look to be solved, and I have to agree.
I am not familiar with the Cerbuino, but you have to look close at the pinouts. On the Hydra connectors share functions. So if you use the Ethernet adapter, you are only left with 1 SPI. The SD card and UART were separate connectors tho. SD does not have to be SPI.
@ LukeG - I would like to mention that a LOT has changed on the software side before 2015. So please let us know what issues you have on the latest release and we will happily investigate.
Personally @ Jef Patat, I would say that whether these devices are “stable” is more a reflection of your code than the framework.
We don’t know your requirements fully to understand if Cerberus based boards are suitable or not. SSL is one area that they are not suitable for. They are also relatively memory limited, which usually isn’t that big a problem but could easily turn into one if you have complex requirements (complex network requirements for example)
GHI support many commercial customers, and I am sure there are many of those customers not on the forum reporting their successes. GHI are always approachable, you should call them up and speak to them first hand to get the best input. Typed responses on the forum are never the right place to have these kinds of conversations
@ Gus: In a few words -> just the italic part, the rest is background
My requirements are not that complex. I’m fully aware of the limitations of this setup, both HW and SW wise and I’m not asking for advice in that direction. I know that would be very hard to give.
My first question should be an easy one:
[em]Can I use the Cerbuino NET board and use ethernet, SD, SPI and UART at the same time? Does the firmware support this?[/em]
Background:The reason I’m asking is because I have had boards before that for example advertise SD and ethernet but they couldn’t be used at the same time. I had to switch, first use ethernet and then switch to SD and back and forth because they were on the same SPI.
My second question is more vague, depending on my needs, I realise that:
[em]Is the network stable?[/em]
Background: I’ve read about all kind of network related issues, boards that freeze if the remote host is not reachable etc. Brett gave a nice hint in saying that SSL is not an option, but that is not a problem to me. I’m thinking about a simple REST server like implementation. But also pushing some data to the net and maybe NTP. I don’t want to start an implementation to see it crash when the NTP is not reachable for example.
Thanks in advance and sorry if I’m not making myself clear.
Yes you can do all that plus pwm, analog and many other things together but keep in mind that a loaded system will start dropping uart data and Ethernet packets, especially on a device with limited memory. So the answer completely depends on your application and how you code it.
By the way, SD does not use SPI on any of our boards. We use a real 4 bit sd bus. And spi support multi slaves.
Network is 99.99% stable on the tcp/udp level. It works completely fine in most cases. Http has some bugs but nothing that you can’t work around. I highly recommend staying away from the gadgeteer network helpers.
So the question of are commercial customers using netmf and networking in a commercial products? The answer is yes.
We use Networking (mainly native TCP and FTP) on all our devices, which are G120 based.
G120 + ENC28 is a verry reliabale and stable Network device, even on high load.
We also use SD, SPI ADC, I2C devices, UART and CAN in parallel. No real bad issues so far.
And as Gus mentioned, I stay away from the Gadgeteer Framework at all. It’s nice for rapid prototyping and proof of concept, but plain NETMF is has less Overhead and less bugs.
I can’t speak for the Cerbuino.NET but I guess if you stay within it’s Memory limitations you should be good.
And if you go beyond the Limits of the Cerbuino.NET you can eassily Switch to a G120 based board. The code should be higly compatible.
