gmane.comp.hardware.microcontrollers.pic

Re: [EE] Raspberry Pi challengers

Mark Hanchey — 2012-05-24T12:20:05

Close up pic of the board is here:
http://www.viagallery.com/Downloadimage.aspx?name=APC%20-%20Top.jpg&cat=5 <http://www.viagallery.com/Downloadimage.aspx?name=APC%20-%20Top.jpg&cat=5>

Chip is wondermedia WM8750
http://www.wondermedia.com.tw/en/products/platform/soc/wm8750/

Sadly wondermedia is about as open as Broadcom about information.

Mark

Re: [EE] Looking for decent but small camera

Mark Hanchey — 2012-05-24T11:50:53

I purchased a canon S150is last year and have been very happy with it. 
One of the cool things about canon cameras
is that it is possible to load alternative firmware using chdk. It 
doesn't replace the cameras firmware , it is placed on the card and the 
camera will load it and run it as long as the power is on, when powered 
off and the card removed the camera will revert to its main firmware. It 
adds a lot of features like the ability to save pics as RAW, exposure 
settings, bracketing, longer exposure times, etc.

http://chdk.wikia.com/wiki/CHDK

Mark

Re: [OT] Interesting newish embedded programming language

Yigit Turgut — 2012-05-24T11:20:53

I vote for ώψπε++-+. Everything has it's ups and downs right ?

On Thu, May 24, 2012 at 9:01 AM, cdb <colin< at >btech-online.co.uk> wrote:

[OT] Interesting newish embedded programming language

cdb — 2012-05-24T06:01:09

 In EEJournal they have an article on B# a cut down  but microcontroller 
orientated C# language, According to the B# webpage it can work in uC that 
have less than 24KB of Flash and less than 2KB of RAM, 8 - 32 bit 
controllers.

Not much else to say as unfortunately to get the specs and to access the 
compiler requires emailing B# themselves.

http://www.eejournal.com/archives/articles/20120523-objectlesson/

http://www.bsharplanguage.org/index.html

Now who is going to invent a computer language using the extra letters of 
the alphabet of the latin and germanic languages.

I'm going for Icelandic and ώψπε.

Colin

--
cdb,  on 24/05/2012

Re: [EE] Looking for decent but small camera

William "Chops" Westfield — 2012-05-24T04:17:24


I'm a big believer in pocket cameras.  We've had reasonable luck with Nikons,
starting with the Nikon S1 that I got for my wife after having an interesting conversation with the camera-store salesman (he pointed out that one of the biggest failure modes of such cameras is lens motors, and the recessed lens of these cameras helps prevent that.)  We progressed to an S51 (daughter) and an S70 (wife's S1 replacement.  I now carry around the S1 with my wallet.)

(It's pretty rare to get a 5x zoom in really tiny cameras like that, though.  Also, I personally don't like not having an eye-level viewfinder.)

BillW

Re: [EE] Serial over Ethernet options

Brent Brown — 2012-05-24T02:28:45

 

Oops, the examples above weren't supposed to be email addresses. Should have 
written eg. mydevice.dyndns.com, mydevice.no-ip.com 

DynDns and No-Ip are a couple of well known DNS providers.

Re: [EE] Serial over Ethernet options

Brent Brown — 2012-05-24T01:55:40

For an off the sheIf solution look for "industrial 3G cellular router", "M2M serial 
modem" or similar. Surprising how many there are around once you know what 
you're looking for.

I've used several of the NetComm range, designed and built in Australia AFAIK. 
This one probably will do all you require but not one I've used:

http://www.netcommwireless.com/product/m2m/ntc-4000

Just throw a SIM card in it (on a data plan, with a provider that offers service in the 
geographical regions you require it to be sent to), and with a little bit of configuration 
the device takes care of the hard work of connecting through the interweb. In my 
case I've used the more expensive routers with Ethernet to create a mini network of 
vaious hardware device, PC, PLC, etc. each of which I can access over the 
interweb, but they certainly also provide an RS232 port that can be used to do 
exactly what you want.

These routers have support for several different DDNS clients (paid or free)... use it 
so when your device connects and is given a public IP address it resolves to a 
name you assign it. eg. mydevice< at >dyndns.org, mydevice< at >no-ip.com, etc. Tricks 
are the SIM card must allow for a public IP dynamic address, and the service 
provider must not block any incoming connection requests (usually the provider 
offers several APN's with different features) and you then manage all firewalling 
yourself in the config of the router (poke holes in the firewall just where you went 
them).

Telnet is one way of getting your serial data flowing across the interweb, but I'm not 
a real expert on this part sorry... I've dabbled and got things working once or twice 
that's about all. Yes the Telnet port is a known port and not secure, but in your case 
it's only open when the device is on (only while your servicing session is in 
progress, not a daily event hopefully), the public IP address is random (that is the IP 
addres is dynamic and may change between sessions but you know what it is 
because the DDNS client resolves it to a URL that only you know and don't 
necessarily share with anyone), and the protocol of the RS232 data that flows back 
and forth is also proprietary to your product.. all meaning that any attack on your 
embedded system(s) in hte field would require a very targeted and concerted effort 
possibly with inside knowledge.

Does that help and/or confuse? :-)

Brent.

On 23 May 2012 at 7:11, Denny Esterline wrote:

Re: [EE] Serial over Ethernet options

Chris Roper — 2012-05-23T22:19:52

The Telit Modules are good if you want a GSM solution.
They have a micro on board that you could create the interface code
and they have a Python interpreter too for quick solutions.
A Telit Module, max232, 3V8 PSU and antenna is all you need in the box.
Get your Service Provider to give you a unique APN and you have secure
end to end serial communications.

Cheers
Chris

Re: [PIC]: PIC32 for camera capture

Isaac Marino Bavaresco — 2012-05-23T22:03:54

Em 23/5/2012 16:32, Andre Abelian escreveu:


Your sensor is 12-bit, so each "byte" will be 12-bit.

When I say "grayscale" image, I'm talking about a B/W sensor (or a color
one that can be configured to output B/W images) that outputs only the
luminance (Y) component of image.
The image is composed of a sequence of 12-bit values representing the
brightness of each pixel.

A color sensor outputs the image as a sequence of two values (12-bit
each in your case), first the luminance (Y) and then the color component
(CbCr) for each pixel.
Some color sensors can output the image in RGB format (usually 5:6:5
bits) or in the YUV format.
In a color sensor in YCbCr or YUV mode, if you discard the second value,
you get the grayscale image.


Isaac

Re: [PIC]: PIC32 for camera capture

Mark Hanchey — 2012-05-23T22:00:39

The Pic isn't up to that task , not at 5mp resolutions. You really need 
something with dedicated dsp abilities to start manipulating data like 
that .  Here is a site about open source cameras for micros, even there 
best designs cannot do 5mp and they are involving ARM chips.

http://www.cmucam.org/

If it were me I wouldn't do 5mp as that high a resolution isn't needed 
to do motion detection, 640x480 can do that easily and color also isn't 
needed.
Mark

Re: [EE] Raspberry Pi challengers

Ruben Jönsson — 2012-05-23T20:16:15

So, if it is Android based, does it include an RTC (unlike the RPi)? I didn't 
see a battery.

A VGA connector is also a big plus, I think.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
ruben< at >pp.sbbs.se
==============================

Re: [EE] Looking for decent but small camera

Dwayne Reid — 2012-05-23T20:12:10

I very much appreciate the camera suggestions.  Thanks, especially, 
to everyone who pointed out shortcomings of the various cameras that 
others suggested.

I've purchased a Canon S100 that I can play with for 14 days before 
I'm stuck with it.  This choice was based on visiting Ken Rockwell's 
site as suggested below.

Its more money than I had intended to spend but I tend to take good 
care of my stuff and it should last me until it becomes completely 
obsolete.  That's what happened to my last expensive camera purchase: 
its a Sony Mavica CD-1000 that still works very well (and takes 
*gorgeous* pictures) - but is just too darned huge to pack 
everywhere.  I still use it in the shop, though.

Now I've got to learn how to take pictures again - its been a LONG 
time since I packed the Mavica camera with me everywhere.  I've never 
been a good photographer but the law of averages says that if you 
take LOTS of pictures, once in a while you will get a good one.  And 
I have gotten some decent pictures over the years.

What prompted the search for a new camera was being at a customer's 
site and wishing that I could permanently document some work that I 
was doing.  The Mavica used to do that for me before I got tired of 
packing it everywhere.  This new camera should be able to do most 
everything that the Mavica could do, just in a much smaller 
package.  I do plan to purchase the Canon belt case that Ken Rockwell 
suggests and I'll start carrying it with me on my belt - and see if 
is unobtrusive enough to stay there over the long term.

I'm sure that I'll miss that huge but gorgeous lens that the Mavica 
has - I'm absolutely convinced that it is that lens that enabled the 
Mavica to take such great pictures.  But I'll try to adapt 
<grin>.  This new camera also has less zoom range: 5x instead of 10x.

For what its worth, I purchased the demo unit from my favorite Future 
Shop store here in Edmonton (Canada) - it was the only unit that 
store had available.  I could have waited a couple of weeks for new 
stock to arrive or drive 30 klicks to a distant store that did have 
new units in stock but I quite liked the 10% discount that they 
offered for the demo unit.  I also purchased their 4 year extended 
warranty - I usually regard those extended warranties as rip-off 
items but I'll begrudgingly pony up the money for expensive items.

The camera wound up costing Can $370 ($449 list) after they added in 
some other discounts, plus another Can $120 for the 4-year extended 
warranty.  They also sold me a 32GB class 10 SD card for $30, which 
seemed reasonable.  I may or may not keep the warranty, though.

By way of comparison, my Sony Mavica CD-1000 cost something like 
$1600 when I purchased it more than a decade ago.  That was after 
trading in my Mavica FD-88 (floppy-disc camera) for credit.

Anyway, thanks again!

dwayne


At 04:26 PM 5/18/2012, Vinicius wrote:

Re: [PIC]: PIC32 for camera capture

Andre Abelian — 2012-05-23T19:32:35

Isaac,

I guess I didn't explain clearly. the purpose of pic is to compare 2 pictures but
not full picture. lets say small area in the center half inch square. I am almost thinking that separate 
PIR sensor is better idea. image comparing is workable but needs better understanding and experiment.
The way I am seeing it there are lots of situations where it may create false triggering on e of them is

darkness may add noise and create false triggering.

Isaac, what I do not get it is that in datasheet only says each pixel is 12 bit wide and I do not
see how to decode? you are saying I have to read a few times in order to get gray scale and color.
based on datasheet pixel bit will output every 10.4 ns and on falling edge read 12 pins output data.
you said 1 byte for grayscale 2 bytes for color that 24 bit data. my question is how to get 24 bit data
if it outputs only 12bit.

thanks

Andre  
   







________________________________
 From: Isaac Marino Bavaresco <isaacbavaresco< at >yahoo.com.br>
To: Microcontroller discussion list - Public. <piclist< at >mit.edu> 
Sent: Wednesday, May 23, 2012 9:30 AM
Subject: Re: [PIC]: PIC32 for camera capture
 
Andre,


It seems that you are a little lost with this design. The PIC with
largest RAM have 128kB, you need at least 10MB.
And there is no way for a CPLD or whatever push data at 100MB/s into the
PIC.

You need to capture to an external memory using an autonomous frame
grabber and then process the images.

Understand that the image processing will take orders of magnitude more
time than the capture process.


Isaac



Em 23/5/2012 12:30, Andre Abelian escreveu:

Re: [EE] Raspberry Pi challengers

Chris McSweeny — 2012-05-23T18:46:58

Did you read the bit where it said all 3 are based on ARM? The
Broadcom chip has an ARM processor, and I see nothing to suggest that
the other two systems are any more likely to be completely open than
RPi is.

I still don't get what the big deal is - with RPi you can develop apps
based on Linux, with the other two apps based on Android. You don't
need to have details of all the nuts and bolts underneath - if you do
then maybe you need to get something different. Personally my
experience of these platforms leads me to think that developing for
RPi will be a huge amount simpler.

Chris

Re: [EE] Raspberry Pi challengers

Wouter van Ooijen — 2012-05-23T18:44:29

The ARM part of the broadcom chip is as open as it can be. The video 
part is not, so the q2uation would be whether the video chip of that 
board is fully and openly documented.

Re: [EE] Raspberry Pi challengers

2012-05-23T17:56:48

But Raspberry PI is based on Broadcom - closed system.
And if I understood well  those  systems 
described at 
http://www.bbc.co.uk/news/technology-18163419
are based  on ARM .
If it is true, I think they will be more successful than Raspberry PI.
I think Raspberry PI is sold cheap so no big money for  advertising. 
Besides Broadcom does not open completely datasheets for the develepers.
My guess is that there will be less developers with PI. And having good application is very 
important for users

Re: [EE] Serial over Ethernet options

Bob Ammerman — 2012-05-23T17:12:06

I googled the magic string:

remote serial over http

And got many hits that look like what you need.

The advantage of this scheme is that at least one end of the link look to 
its network environment like just another PC using a browser to access the 
internet. Few networks will restrict that type of access.

Re: [PIC]: PIC32 for camera capture

Isaac Marino Bavaresco — 2012-05-23T16:56:43

You want to compare two images, so you must hold both in RAM.
They may be two consecutive images or a base image plus another taken
some time in the future.

Each image has 5,000,000 pixels. A grayscale image uses one byte per
pixel, a color image uses two bytes per pixel.
So a grayscale image needs 5,000,000 bytes of RAM and a color image
needs 10,000,000 bytes of RAM.
Thus the figures, 10MB for grayscale images and 20MB for color images.

For capturing, each pixel is read once and stored, but the comparison
algorithm may need to do several passes over the captured data.


Isaac



Em 23/5/2012 13:19, Andre Abelian escreveu:

Re: [PIC]: PIC32 for camera capture

Isaac Marino Bavaresco — 2012-05-23T16:30:13

Andre,


It seems that you are a little lost with this design. The PIC with
largest RAM have 128kB, you need at least 10MB.
And there is no way for a CPLD or whatever push data at 100MB/s into the
PIC.

You need to capture to an external memory using an autonomous frame
grabber and then process the images.

Understand that the image processing will take orders of magnitude more
time than the capture process.


Isaac



Em 23/5/2012 12:30, Andre Abelian escreveu:

Re: [PIC]: PIC32 for camera capture

Yigit Turgut — 2012-05-23T16:24:17

As Isaac stated, you don't need dual ram, it all can be done in CPLD.
 5MP sounds big to me, why do you think you need 5MP? What kind of
algorithm are you planning to use for comparison ?

On Wed, May 23, 2012 at 6:30 PM, Andre Abelian <abelian.andre< at >yahoo.com> wrote:

Re: [PIC]: PIC32 for camera capture

Andre Abelian — 2012-05-23T16:24:35

Martin,

I am thinking to use 144 pin cyclone 2 with dual ported ram connected with pic32
to sense a motion change in center of the image. fpga will continually scan and update
ram and pic try to figure out the change. I agree with Isaac to use higher ram.
i will go with 16mb just incase.

AA




________________________________
 From: M.L. <m< at >lkeng.net>
To: Microcontroller discussion list - Public. <piclist< at >mit.edu> 
Sent: Wednesday, May 23, 2012 8:26 AM
Subject: Re: [PIC]: PIC32 for camera capture
 
On Wed, May 23, 2012 at 7:25 AM, Yigit Turgut <y.turgut< at >gmail.com> wrote:


I agree with Yigit that you need more processing speed. An FPGA is a
good option and is in fact used in many custom and professional camera
applications.