From: Didi on
Joel Koltner wrote:
> ...
> > you get that under DPS as well - with a lot of functionality as a
> > bonus and
> > with a few uS worstcase IRQ latency (try *that* on the wintel things).
>
> Sure, it's just that for anyone with DPS experience (where's their web site,
> btw?) you'll probably find at least 100 people with Windows or Linux
> experience.

DPS is less popular than that. It is all my work, my property etc.
Comes
on my products. I have been wanting to put a cheap product with it on
the market but I just got a setback and may be unable to do it this
year
yet again....

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/6911f3aa16da2c35?dmode=source
From: Joel Koltner on
Hi Didi,

"Didi" <dp(a)tgi-sci.com> wrote in message
news:018c2551-78ca-4749-8d91-c5bbed3c41d7(a)1g2000prf.googlegroups.com...
> DPS is less popular than that. It is all my work, my property etc.

You wrote the TCP/IP stack from scratch? That's a lot of effort! Good work.

> Comes
> on my products. I have been wanting to put a cheap product with it on
> the market but I just got a setback and may be unable to do it this
> year
> yet again....

I hope you'll be able to do it eventually; I'm sure many people would be
interested.

---Joel


From: Didi on
Joel Koltner wrote:
> Hi Didi,
>
> ....
> > DPS is less popular than that. It is all my work, my property etc.
>
> You wrote the TCP/IP stack from scratch? That's a lot of effort! Good work.

Thanks. It took me about 6 months to do (including the DNS and some
high
level clients), and is not such a great part of DPS (about 10%).

>
> I hope you'll be able to do it eventually; I'm sure many people would be
> interested.

So do I hope (hope, that is)! ... :-). I will eventually, it won't
take that much - I
know I'll do it, as for those interested I wish I knew a bit
more.... :-).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/4ccece298795c6b8?dmode=source
From: Robert Adsett on
In article <fd9dc69f-eb74-45d8-820e-
5d75b59b9a8e(a)p25g2000pri.googlegroups.com>, Didi says...
> It does not matter how tempting
> those nice things under that tree look, danger may be lurking around
> if the place is so desolated.... :-).

If the place is so desoloated it is dangerous. Such places are away
from support. Also there is extra danger on first approach since the
hazards are unfamiliar.

I rather suspect many in this group prefer the hazards and beauties of
the new, unfamiliar (and desolate) to the dangers of the crowds. If
nothing else for the thrill of treading less travelled paths.

Is the metaphor broken yet :)

Robert
** Posted from http://www.teranews.com **
From: James Waldby on
On Sat, 12 Apr 2008 09:38:30 -0700, John Larkin wrote:
[re "box that will control a scientific gadget" possibly using "an
Intel-cpu SBC and a custom board" where "SBC would talk gigabit
ethernet to the customer's system and PCI to our board." with SBC
like http://us.kontron.com/index.php?id=226&cat=527&productid=1726

> Our board would have a PCI interface driving a biggish FIFO, say 8k deep
> by 48 bits wide, inside an FPGA. [...]
> OK, we finally get to a question: If we run some flavor of Linux on the
> SBC, what's a good strategy for keeping the fifo loaded? Assuming that
> we have the recipe for an entire experimental shot in program ram, some
> tens of megabytes maybe, we could...
....
> 3. Best, if possible: set up a single DMA transfer to do the entire
> shot. That involves a dma controller that understands that the target is
> sometimes busy [...]

If the linux kernel is given a "mem=n" parameter at boot time, it will use
only n bytes of memory, which leaves the balance of memory to be contiguously
allocated later with "dmabuf = ioremap(...)" (see "Allocating the DMA Buffer"
and "Do-it-yourself allocation" in Chap. 13 of Linux Device Drivers, by
Rubini and Corbet; eg http://www.xml.com/ldd/chapter/book/ch13.html .)

If high memory isn't usable by the DMA controller, you could build a
kernel with your device driver using preallocated fixed buffers,
rather than loading the driver as a module.

User code can access the buffer as a memory-mapped file; see
eg http://www.scs.ch/~frey/linux/memorymap.html for background, and see
eg http://linux.die.net/man/2/mmap for notes on some flags that can lock
the mapped pages in memory, make them private, map to fixed location, etc.

> 4. If it's a dual-core cpu, is it hard (under Linux) to assign one cpu
> to just do the fifo transfers?

Root can use cpusets, described at http://lwn.net/Articles/127936/
to allocate cpu's and memory nodes, or can use system calls as
described in http://linux.die.net/man/2/sched_setaffinity to
control which cpu's given processes will run on.