headers
wireless | 1 Apr 03:59
Picon

Re: pc (usb) based logic analyzers

Mike Frysinger wrote:

>> If you are looking for a full blown logic analyzer
>> then there are many listed in most Circuit cellar magazines
>> (embedded hackery).
> 
> never heard of this magazine

It's more hardware and traditional embedded; low end
devices (like 8 and 16 bit micros and such, but
a great resource. Lots of state-machine to RTOS stuff.
They are just wetting their toes on embedded Linux.

Check out the magazine:

http://www.circellar.com/

> i wasnt aware of this ... i'll make sure to ask :)

On this page:
http://hackaday.com/2009/03/06/tools-saleae-logic-logic-analyzer/

It says
"Free Trial"

for Saleae device.....

James
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karl Hiramoto | 1 Apr 08:47
Gravatar

Re: pc (usb) based logic analyzers

Mike Frysinger wrote:
>
>> One of the most popular devices (vendors) is
>> bit scope. There device may suit your
>> LA needs.
>>
>> www.bitscope.com/design
>>     
>
> they say they fully support Linux, so i'll probably give these guys a shot
>
>   
I have the bitscope BS310 and works great in linux
http://www.bitscope.com/product/BS310/

I didn't recommend it earlier because it doesn't meet your 50Mhz 
requirement tho.  40MS/s  anything over 10Mhz starts to look like 
triangle waves.   I was recently trying to debug a 25Mhz expansion bus, 
and it was impossible to use the bitscope, other than the analog probe.

That said, I've had good experience using my bitscope to debug switching 
power supplies, slow(< 16mhz) micro controllers and logic circuits.

--
Karl
Permalink | Reply | 0 comments |
headers
Jakub Ladman | 1 Apr 10:34
Picon

Re: pc (usb) based logic analyzers

Hi
I know a commercial one too.

http://tools.asix.net/dbg_sigma.htm

Jakub Ladman

Dne Tuesday 31 of March 2009 09:59:13 Mike Frysinger napsal(a):
> what do people use for their logic analyzers needs ?  i'm looking for
> something that:
>  - is portable (smaller the better)
>  - usb based
>  - runs under Linux (preferably using open source software)
>  - at least 50mhz
>  - at least 8 probes
> and no, i dont want to build my own :).  i'm not a hardware hacker, plus
> the thing needs to be durable when i slam it around in my bag while
> traveling.
>
> through work i have an Acute Pocket-LA 1616, but it's Windows only.  their
> usb stack is custom so it requires custom windows kernel drivers which
> means running under wine is a no go.  and their software frontend isnt the
> greatest piece of work to begin with ...
> -mike
Permalink | Reply | 0 comments |
headers
Christopher Friedt | 3 Apr 13:06
Picon
Gravatar

Re: eyeborg

Hi wireless,

On Tue, Mar 17, 2009 at 5:49 PM, wireless <wireless@...> wrote:
> The real pioneer is a MIT grad that is tenured in Canada:
> Steve Mann

I'm familiar with Steve Mann, and I guess that to some he's seen as a
pioneer. One of my closest friends was offered a PhD position with
him, but turned it down after meeting him, saying that he was quite
egocentric and eccentric (as one might guess).

I would say his concept of 'sous-veillance' was quite original, from a
social perspective. However, from my perspective, he was just one of
the earlier people to do 'cool stuff' with ccd's and image sensors.

He's already 'patented the concept' of putting a camera in a
prosthetic eye too, but he has to this day never shown a device to
support the patent. I call that "patent trolling".

Cheers,

Chris
Permalink | Reply | 0 comments |
headers
Christopher Friedt | 3 Apr 13:33
Picon
Gravatar

Re: eyeborg

Hi Peter,

On Tue, Mar 17, 2009 at 12:31 AM, Peter Stuge <peter@...> wrote:
> Christopher Friedt wrote:
>> Can anyone on the list recommend a good kit for a tunable USB radio
>> transceiver?
>
> That quite generic. What frequency range? What will you transceive?
> What bitrate do you need? How cooked does your interface need to be?

It would have to be in the 1-2 GHz range - this is mainly a range
imposed by the size of the required antenna.

Most digital cmos image sensors essentially have two 'channels'. The
first is unidirectional, which carries the data away from the sensor,
and the second is bidirectional, and is often an i2c bus for control
and configuration. The i2c bus is very low-frequency, 10 kHz - 100
kHz, while the data channel is rather high (up to 60fps, with 640x480
resolution, and 24bpp, in RGB24 or YUV420p format, for example). It
might be possible to do jpeg compression at the source, if power /
space permits.

In any event, a digital signal will be modulate the transceiver
signal, with appropriate coding to ensure that the information is
received correctly - right now they're getting quite a bit of noise
using a simplistic analog camera / transmitter.

If you have any ideas about certain chips, I would love to hear them.
Size and power are of course the main concern.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Stuge | 6 Apr 04:21
Picon

Re: [embedded] first step in programming geode target

Dear Eric,

esa wrote:
> It's my first step to program a embedded system.

Fantastic! Welcome to the world of embedded Linux.

I have a customer who was in a situation almost identical to yours.

I would like to try to break down your questions a little, I think it
can help. Also I would like to say that if you do not have a strong
UNIX/Linux background you are facing a very large project.

You are basically going to start from scratch, learning hundreds if
not thousands of details about a new computer operating system, and
one or several new programming languages. Then you're going to
re-implement your application on top of all those new things.

It is relevant to know what your application does to make any
accurate estimates, but even without knowing any of that I can say
that you're in for a development and learning effort several years
long, and that the technical outcome in the end can be very much
state of the art.

The outcome can also be a problem filled pile of mistakes. In
particular, I feel strongly that trying to "cheat" the process of
learning a new system through the use of RAD (Rapid Application
Development) tools when producing software for an embedded system
creates more problems than it solves. It is even worse if said RAD
tools aren't open source. The problem is that there are so many
(Continue reading)

Permalink | Reply | 1 comment |
headers
esa | 6 Apr 07:11
Picon
Favicon

Re: [embedded] first step in programming geode target


Dear peter,

Thanks for your reply.
You are right. There is a lot of documentations to read and that's what I do
;-).
I already make a little linux for my board by following the gentoo embedded
manual.
On my target, there is busybox and uclibc installed.

Now, I look for a IDE for programming.
I found that Eclipse is frequently used to develop for embeded device.
So, I install it ( on windows first . Only to learn how it work ).
Again, you are right, it's best to program directly by using a little
editor, make, makefile, etc...
I will also try to use my one makefile...

Thanks for the idea about using coreboot. I will try it, but for the
future...

Best regards
Permalink | Reply | 0 comments |
headers
Alon Bar-Lev | 15 Apr 09:40
Picon
Gravatar

[openmoko] overlay profiles/profiles.desc makes all ebuild is overlay unusable

Hello,

Once this file exists, no eclass can be found... I don't know why...
Anyway, this is what I get:

ebuild nfs-utils-1.1.5.ebuild digest
 *
 * ERROR: net-fs/nfs-utils-1.1.5 failed.
 * Call stack:
 *                ebuild.sh, line 1872:  Called _source_ebuild
 *                ebuild.sh, line 1811:  Called source
'/var/gentoo/openmoko-overlay/openmoko-target/net-fs/nfs-utils/nfs-utils-1.1.5.ebuild'
 *   nfs-utils-1.1.5.ebuild, line    5:  Called inherit 'eutils'
'flag-o-matic' 'multilib' 'toolchain-funcs'
 *                ebuild.sh, line 1211:  Called die
 * The specific snippet of code:
 *              [ ! -e "$location" ] && die "${1}.eclass could not be
found by inherit()"
 *  The die message:
 *   eutils.eclass could not be found by inherit()
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 *

Once removing this file all is fine.

Alon.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Maksim 'max_posedon' Melnikau | 16 Apr 22:11
Picon

Re: [openmoko] overlay profiles/profiles.desc makes all ebuild is overlay unusable

On Wednesday 15 April 2009 10:40:14 Alon Bar-Lev wrote:
> Hello,
>
> Once this file exists, no eclass can be found... I don't know why...
> Anyway, this is what I get:
>
> ebuild nfs-utils-1.1.5.ebuild digest
>  *
>  * ERROR: net-fs/nfs-utils-1.1.5 failed.
>  * Call stack:
>  *                ebuild.sh, line 1872:  Called _source_ebuild
>  *                ebuild.sh, line 1811:  Called source
> '/var/gentoo/openmoko-overlay/openmoko-target/net-fs/nfs-utils/nfs-utils-1.
>1.5.ebuild' *   nfs-utils-1.1.5.ebuild, line    5:  Called inherit 'eutils'
> 'flag-o-matic' 'multilib' 'toolchain-funcs'
>  *                ebuild.sh, line 1211:  Called die
>  * The specific snippet of code:
>  *              [ ! -e "$location" ] && die "${1}.eclass could not be
> found by inherit()"
>  *  The die message:
>  *   eutils.eclass could not be found by inherit()
>  *
>  * If you need support, post the topmost build error, and the call
> stack if relevant.
>  *
>
> Once removing this file all is fine.
>
> Alon.
Hi!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven Rebhan | 16 Apr 22:28

Re: [openmoko] overlay profiles/profiles.desc makes all ebuild is overlay unusable

Fixed in r328.

In short:
An overlay should not contain profiles.desc without defining a proper
metadata/layout.conf (containing master = gentoo) as otherwise the
overlay becomes the master repository (citing zmedico on this stuff).

Sven
Permalink | Reply | 0 comments |

Gmane