Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Would this be possible with the Netduino Go


  • Please log in to reply
18 replies to this topic

#1 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 05 April 2012 - 08:42 AM

Would it be possible to:

...use this Net Gadgeteer camera module (Socket U) on one of the gadgeteer S-U-X module ports, to capture .Jpeg images

..and then, to display those on the Nwazet LCD display module on another go!Module port?

I realize it would be very slow, with a serial camera transmitting at 38.4K Baud, but is this kind of mix and match doable?

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 05 April 2012 - 01:06 PM

Hi mtylerjr, Ooh, that's a very good question. We recently purchased a JPEG Camera from Sytech but haven't had a chance to test it yet. As long as there's a way to do JPEG->bitmap conversion, it should work. [Please note that the Gadgeteer U module will take up a whole go!bus channel on the mainboard...but you'll still have 4 sockets left over for go!bus modules.] Also, Fabien and Bertrand (Nwazet) probably have the answer to this question. I'll see if they can pitch in with some guidance here. Chris

#3 godefroi

godefroi

    New Member

  • Members
  • Pip
  • 3 posts

Posted 05 April 2012 - 02:29 PM

I imagine memory would be the limiting factor. You need the Bitmap class included in your firmware (the camera module returns Bitmap objects). At the lowest resolution, you might have enough memory to store one image, assuming you weren't doing much else.

#4 godefroi

godefroi

    New Member

  • Members
  • Pip
  • 3 posts

Posted 05 April 2012 - 06:12 PM

I imagine memory would be the limiting factor. You need the Bitmap class included in your firmware (the camera module returns Bitmap objects).

At the lowest resolution, you might have enough memory to store one image, assuming you weren't doing much else.


Note that this post refers to GHI's camera module. A JPG camera would allow higher resolutions, but doesn't allow easy manipulation of the image if that's your goal.

#5 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 05 April 2012 - 06:51 PM

Note that this post refers to GHI's camera module. A JPG camera would allow higher resolutions, but doesn't allow easy manipulation of the image if that's your goal.


It was my understanding that the GHI module was socket H, and therefore not (easily) usable with the NGo. (The specs for the ghi module said there needed to be support for ISO usb streaming)

I'm really looking for any sort of image capture possibility with the NGo. I assume there will be an SD card module at some point, for data storage.

Im just brainstorming at this point though - no real application in mind. Just thinking out loud, really.

#6 godefroi

godefroi

    New Member

  • Members
  • Pip
  • 3 posts

Posted 05 April 2012 - 11:15 PM

It was my understanding that the GHI module was socket H, and therefore not (easily) usable with the NGo. (The specs for the ghi module said there needed to be support for ISO usb streaming)

I'm really looking for any sort of image capture possibility with the NGo. I assume there will be an SD card module at some point, for data storage.

Im just brainstorming at this point though - no real application in mind. Just thinking out loud, really.


Ah, yes, you're correct. Forgive me, I thought for some reason it was for a U socket.

One could theorize a camera module using a cheap DCIM camera and one of the STM32 variants that has the DCIM interface. It could have JPEG encoding right onboard, and give one a high-resolution camera quite cheaply (even MJPEG?).

#7 Guest_Crystal DeFrate_*

Guest_Crystal DeFrate_*
  • Guests

Posted 06 April 2012 - 06:36 AM

..<snip>.. I assume there will be an SD card module at some point, for data storage.

Im just brainstorming at this point though - no real application in mind. Just thinking out loud, really.



Yes, the Laboratories should yield a SD module shortly.

*not quite insider information.. but wanted you to know.

:) And I love brainstorming.. the activity begets wondrous things.

#8 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 06 April 2012 - 07:54 AM

Yes, the Laboratories should yield a SD module shortly.

*not quite insider information.. but wanted you to know.

:) And I love brainstorming.. the activity begets wondrous things.


Ooh, thanks for the not quite insider information.

BTW, I ordered one of these: http://macetech.com/...&products_id=23
Do you see any issues with connecting this to the Shield Base, connected to the NGo!?
Actually I ordered 2 - I am hoping to add 128 outputs to my NGo! (which arrives tomorrow)

I am also looking forwared to the promised documentation that will be released this weekend and monday. Im thinking of trying to create an RFID GO!Module (I am an embedded RFID software engineer)

(btw, what is the appropriate shorthand for the Netduino GO!? NGo?, NDGo?, NGo!, NDGO!, D!NGO? )


#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 April 2012 - 09:04 AM

BTW, I ordered one of these: http://macetech.com/...&products_id=23
Do you see any issues with connecting this to the Shield Base, connected to the NGo!?
Actually I ordered 2 - I am hoping to add 128 outputs to my NGo! (which arrives tomorrow)

Clever setup :)

Right now, the Shield Base (Beta) supports: InputPort, OutputPort, TristatePort, AnalogInput, and some PWM.

We'll be adding SPI, SerialPort, and I2C shortly. We need to switch it from the slow comm channel to the high-speed SPI-CRC comm channel.

SPI and SerialPort are both implemented on the Shield Base itself already. If you want, you can break out the socket pins and write some code on it directly, to get your Centipede up and running.

Once we switch over to the high-speed channel, you'll be able to use the same code on your Netduino Go...and interact with this shield. Should be cool :) Although eventually...you could just plug in a few shield bases :)

I am also looking forwared to the promised documentation that will be released this weekend and monday. Im thinking of trying to create an RFID GO!Module (I am an embedded RFID software engineer)


Oh that would be cool. We'll start posting the electrical docs. We're in the process of moving the modules from custom firmware to a new standardized virtualized IO firmware... If you'd like to be involved in that process, we can get help you design your RFID go!module so it works with the new firmware (which you'll just flash onto your STM8S chip).

Chris

#10 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 07 April 2012 - 12:35 AM

Clever setup :)

Right now, the Shield Base (Beta) supports: InputPort, OutputPort, TristatePort, AnalogInput, and some PWM.

We'll be adding SPI, SerialPort, and I2C shortly. We need to switch it from the slow comm channel to the high-speed SPI-CRC comm channel.

SPI and SerialPort are both implemented on the Shield Base itself already. If you want, you can break out the socket pins and write some code on it directly, to get your Centipede up and running.

Once we switch over to the high-speed channel, you'll be able to use the same code on your Netduino Go...and interact with this shield. Should be cool :) Although eventually...you could just plug in a few shield bases :)



Oh that would be cool. We'll start posting the electrical docs. We're in the process of moving the modules from custom firmware to a new standardized virtualized IO firmware... If you'd like to be involved in that process, we can get help you design your RFID go!module so it works with the new firmware (which you'll just flash onto your STM8S chip).

Chris


I'll look for them!

Meanwhile, My Go! arrived today. Awesome.

About half my peripherals arrived (Button modules, RGBLED Module, Shield Base, Sainsmart ProtoBoard shield and sensor shield)

I was also expecting the LCD touch display and mounting plates from nwazet today (they said they would consolidate the order into one package) but no luck there. Hopefully the other stuff will arrive tomorrow.

Everything looks very cool. I even like the blue boxes and black anti static bags. My only feedback is I wish each module at least came with its own cable. right now I have two cables, one for the Shield base, and one for one of the other modules. Maybe I will go to Frys and see if I can get the pieces to make a cable or two.



Still, I have enough stuff to start a project this weekend.

Are you guys going to have a basic "Module" kit, that comes with interface module on a protoboard, so we can start developing our own modules more quickly?

I will also be VERY excited when you get SPI/serial/I2C going on the shield base :)

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 April 2012 - 12:51 AM

Hi mtylerjr,

Meanwhile, My Go! arrived today. Awesome.

Everything looks very cool. I even like the blue boxes and black anti static bags.

:) and :)

My only feedback is I wish each module at least came with its own cable. right now I have two cables, one for the Shield base, and one for one of the other modules. Maybe I will go to Frys and see if I can get the pieces to make a cable or two.

:) We used the industry-standard 10-pin 0.05" cable (same as MiniJTAG), so you can certainly make your own cables.

We thought about including cables with each module, but didn't want to burden each one with an extra $2 of cost--and then have extra cables being dumped into landfills.

And even more importantly--we don't want to disadvantage small module makers by setting a precedent that they need to include a $2 cable ($4 after their markup) with each of their modules as well.

We find that while 10cm works for almost all modules, for some modules it's nice to have a shorter 5cm cable. We wanted to give users options--and then we included 2 free cables with the mainboard to make sure you ended up with some in case you didn't get any otherwise.

Are you guys going to have a basic "Module" kit, that comes with interface module on a protoboard, so we can start developing our own modules more quickly?

We've been thinking about it. It would be cool to have a proto-board that you could use to make your own module...and then simply formalize everything in Eagle and order boards. If we don't make one, I'm sure someone in the community will.

This is a whole new ecosystem...lots of opportunity for people to build modules, for fun or for profit. We'll be creating a whole set of standardized virtual IO go!bus firmware for STM8S...to enable these scenarios.

I will also be VERY excited when you get SPI/serial/I2C going on the shield base :)

Me too! We're thinking that maybe we should bring it live now with the UART channel (albeit very slowly) to get some testing on it... That could accelerate the beta program some.

BTW, if you run your Shield Base in standalone mode (i.e. feed it 3.3V power from a Netduino and plug a USB-TTL Serial cable into pins D0/D1 and deploy NETMF code directly to it)...then you have access to all three UARTs and SPI today.

Chris

#12 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 11 April 2012 - 08:08 PM

I should have a couple of things to play around with soon, with regards to creating modules.

I have an STM8S Discovery Kit and STM32F Discovery Kit arriving from DigiKey today, intended to be the foundation of possible modules.

I also have a C329 Jpeg Camera Module and evaluation module from Electronics123.com (SPI version... it is supposed to be significantly faster than the uart version) arriving soon as well.

Im hoping to make some sort of fast, usable camera module than can be used with the Nwazet LCD touch screen and display images easily.

I also have a few 13.56Mhz RFID modules (SPI) coming from China (through ebay actually)

So, pretty soon I am going to be asking more detailed questions about the STM8 and STM32 standard module firmware that was mentioned previously :)

One question about the Nwazet display - obviously it is a smart display, and the NGO doesnt have to keep refreshing it with the entire image. I assume it will be possible to send image chunks to the Nwazet display piecemeal, and not have to have the entire image in the NGO's memory at any given time, just pieces...

Can anyone from Nwazet (stefan?) give me any pointers on how I might maximize performance? I noticed that displaying a full screen image was possible with the sample demo, when an SD card module was used to provide the images, but it appeared fairly slow in loading/displaying that image, not something that you would be able to use in real time at multiple FPS... Is there any sort of understanding on what the maximum performance can be? What should be a reasonable goal, timewise, in filling the NWazet touch screen module with a full screen bitmap image? Do you think it is possible to quickly get SPI data from one module, and send it to the Nwazet LDS Module quickly enough to get multiple FPS, or is this something thats just not going to be reachable with this architecture (.net latency etc)?

Lastly, this thing looks like it would be fun to build a module around... It's a bit pricey, but Im thinking of creating something that my 6 year old can use to design digital light-brite type images (no idea what to use for the interface yet), and then save them to/load them from the eventual SD card module..

Brainstorming IS fun...Im really excited about an RFID project, also using the nwazet displays, that I am thinking about, but I dont want to describe it and have someone else do it first ;) I might need to buy a few more though.

#13 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 11 April 2012 - 08:20 PM

By the way, if Nwazet or Secret Labs or anyone else are already going to come out with similar modules soon, or products that would soon make my tasks easier (or unnecessary!) - any unofficial hints dropped as to what and when would be appreciated and would remain confidential :)

#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 11 April 2012 - 08:22 PM

Hi mtylerjr, Awesome. You have some great ideas for modules there! Fabien or Bertrand (Nwazet) should be able to answer your questions... Let me see if I can pitch in 2 cents too... The go!bus channel can support up to around 20Mbps of serial data with CRC16. Displays use a _lot_ of data (which is why they often have 16-24 wire buses) but I know that Nwazet has done a lot to maximize throughput. You probably won't be able to create a first-person shooter where the whole display changes 30 frames a second...but you should be able to do a lot. I am pretty sure that you can stream partial images, updating only part of the screen at a time. The image is buffered on the module itself--courtesy of the on-board STM32F2 and/or TFT driver chip. Chris

#15 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 11 April 2012 - 08:40 PM

You probably won't be able to create a first-person shooter where the whole display changes 30 frames a second...



All right.. I'll put my Skyrim port to netduino Go on hold then :)

Honestly, I'd be happy with being able to update the LCD with camera images at 3 FPS. The camera module itself is supposed to be able to capture vga images and provide them at 15 FPS (@ VGA, so maybe more FPS at the nwazet LCDs 320x240 resolution), and the NGO will have to do the JPG to BMP (assuming the nwazet module cant accept jpeg data directly, I think someone mentioned that) - so I am hoping that is still reachable.. I guess I'll find out!

#16 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 12 April 2012 - 06:48 AM

The display only accepts .bmp and raw 16-bit bitmaps at the moment as I had no time to support anything else unfortunately. Having said that, nothing prevents jpeg support from being added to the display's firmware (hopefully, we'll start seeing community contributions soon Posted Image).
As far as frame rate goes: SPI is not well suited for high FPS / large image transfers. One possible mitigation would be increasing the size of the communication buffer that the display firmware uses today (set @ 8KB, which is a good size for most GUI applications, but sub-optimal for achieving any kind of high FPS with large bitmaps).

Finally, please keep in mind that the size of a full screen .bmp is about 153KB (240 x 320 x 16bit/pixel, or can even be larger @ 240 x 320 x 18bit/pixel) which is more than you can fit in the memory of the Netduino Go! So, you'll have to read images from a stream somewhere... SD cards come to mind, but that's SPI too and not always super fast....

The final point is that the STM32F2xx in the 64-pin package used by the display module today doesn't support the FSMC feature which allows driving devices such as displays in hardware. That in itself is a major factor in limiting frame rate.

I hope this helps with understanding what is achievable.

Cheers,
-Fabien.

#17 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 12 April 2012 - 07:12 AM

The display only accepts .bmp and raw 16-bit bitmaps at the moment as I had no time to support anything else unfortunately. Having said that, nothing prevents jpeg support from being added to the display's firmware (hopefully, we'll start seeing community contributions soon Posted Image).
As far as frame rate goes: SPI is not well suited for high FPS / large image transfers. One possible mitigation would be increasing the size of the communication buffer that the display firmware uses today (set @ 8KB, which is a good size for most GUI applications, but sub-optimal for achieving any kind of high FPS with large bitmaps).

Finally, please keep in mind that the size of a full screen .bmp is about 153KB (240 x 320 x 16bit/pixel, or can even be larger @ 240 x 320 x 18bit/pixel) which is more than you can fit in the memory of the Netduino Go! So, you'll have to read images from a stream somewhere... SD cards come to mind, but that's SPI too and not always super fast....

The final point is that the STM32F2xx in the 64-pin package used by the display module today doesn't support the FSMC feature which allows driving devices such as displays in hardware. That in itself is a major factor in limiting frame rate.

I hope this helps with understanding what is achievable.

Cheers,
-Fabien.



Thank you for the feedback!

Yeah, I realized I would not be able to contain the entire image file in the go's memory at once, which is why I wondered about sending chunks of the image to the display module - read a managable chunk from the camera module's spi stream, route it to the display module, repeat until the image is completely displayed, etc. That was the vague idea, anyway.

You say that SPI isnt well suited for high FPS - is that in general? My other option was a UART based module, but that seemed to be much much slower still, about 1/7th the speed or so - Is there some advantage to using a UART based camera module, or were you saying that SPI still just isnt fast enough?

Oh well - a high FPS wasnt something that was for a specific application, I was just curious. I still think the LCD module is a fantasic item. As soon as I sell some stuff on Ebay, I am going to most likely buy another one. Native Jpeg support would still be a cool feature. But I guess we can write it ourselves!


(So.. Anyone want to buy a large collection of san jose sharks NHL collector pins? :D)

#18 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 12 April 2012 - 03:48 PM

You say that SPI isnt well suited for high FPS - is that in general?




Yes, in general: SPI is a serial bus architecture (clocking 1 bit at a time)
High FPS applications require a parallel bus architecture (clocking 8/16/32/64/128/...bits at a time).


A UART interface is also a form of serial bus, similar to SPI in many regards and is also slower than SPI.


If you're interested in learning more about interfacing with a serial camera module, I wrote an article on the subject last year: http://fabienroyer.w...ith-a-netduino/

Hope this helps.

Cheers,
-Fabien.

#19 mtylerjr

mtylerjr

    Advanced Member

  • Members
  • PipPipPip
  • 106 posts
  • LocationChristchurch, New Zealand

Posted 12 April 2012 - 07:01 PM




Yes, in general: SPI is a serial bus architecture (clocking 1 bit at a time)
High FPS applications require a parallel bus architecture (clocking 8/16/32/64/128/...bits at a time).


A UART interface is also a form of serial bus, similar to SPI in many regards and is also slower than SPI.


If you're interested in learning more about interfacing with a serial camera module, I wrote an article on the subject last year: http://fabienroyer.w...ith-a-netduino/

Hope this helps.

Cheers,
-Fabien.


Fabien, that does help. Thank you. Ive bookmarked your article and Im sure it will help me a great deal.

So... when does the Netduino LamberGo!ni, with 8 high speed parallel Go!Bus2 ports come out? :)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.