hi all,
we are planning to use the netduinoplus core on a new product we are developing. Unfortunately no one has experience in our company in drivers development. What we need is for instance a fast parallel bus (i.e. 10MHz-16bits) to interface color TFT or do data transfer with a FPGA (i.e. PAL or NTSC) . All I could find so far on netduinoplus are slow interfaces (SPI, UART ...). Do you know any company or freelance people that can help us to get started in drivers implementation (we are based in south of France)?.
thanks a lot for your support,
greg.
drivers support
Started by gwa, Apr 24 2012 07:48 AM
5 replies to this topic
#1
Posted 24 April 2012 - 07:48 AM
#2
Posted 24 April 2012 - 08:24 AM
Hi,
I know http://www.nwazet.com has experience in this. They also developed the touch display for Netduino Go!.
Perhaps you could also use a Netduino Go! instead of Plus, since it has a bit more power?
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#3
Posted 24 April 2012 - 09:15 AM
Hmmm....the Gameduino might fit your needs?
http://www.watterott.com/de/Gameduino
Exactly what's the project?
http://www.watterott.com/de/Gameduino
Exactly what's the project?
Biggest fault of Netduino? It runs by electricity.
#4
Posted 24 April 2012 - 09:26 AM
Are there working .NETMF drivers for that shield already? Would be an awesome one!Hmmm....the Gameduino might fit your needs?
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#5
Posted 24 April 2012 - 10:02 AM
Are there working .NETMF drivers for that shield already? Would be an awesome one!
I don't think so. It's just a FPGA shield (no MCU/CPU), which can be connected to any Netduino (probably should be easier to glue to the Go!).
It's just because Greg asked for FPGA+video capabilities. I guess should be easier than hacking heavily the Netduino* core. Also not sure that a native driver could be manage a so high speed data transfer (in real-time), without cutting a lot of perf for the above MF.
Finally, there would be serious impact on the available RAM, which has to be shared (how?) between video and MF: not easy at all, IMHO.
I'd bet on an external controller for sure.
Cheers
Biggest fault of Netduino? It runs by electricity.
#6
Posted 24 April 2012 - 10:12 AM
The only issue I can see with writing a driver for it is that it will want the CS to latch after each byte, is sent looking at the some of the code snippets.
so the standard netmf SPI implementation will probably be a bit on the slow side for it, I may be wrong, just basing my assumptions on the work i have done to get some Maxim SPI uarts to work properly.
I posted a more detailed reply yesterday regarding latching the SPI interface via a firmware mod, or Mario's hardware solution can probably be adapted although would be harder to do with a pre-built shield
digitalWrite(9, LOW); // start SPI transaction SPI.transfer(highByte(0x0113)); // start read from 0x0113 SPI.transfer(lowByte(0x0113)); byte value = SPI.transfer(0); // read byte at 0x0113 digitalWrite(9, HIGH); // end SPI transaction digitalWrite(9, LOW); // start SPI transaction SPI.transfer(highByte(0x0a00) | 0x80); // start write to 0xa00 SPI.transfer(lowByte(0x0a00)); SPI.transfer(value); // write byte at 0x0a00 digitalWrite(9, HIGH); // end SPI transaction
so the standard netmf SPI implementation will probably be a bit on the slow side for it, I may be wrong, just basing my assumptions on the work i have done to get some Maxim SPI uarts to work properly.
I posted a more detailed reply yesterday regarding latching the SPI interface via a firmware mod, or Mario's hardware solution can probably be adapted although would be harder to do with a pre-built shield
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users