On Apr 21, 4:56 am, Didi <d...@tgi-sci.com> wrote:
> rickman wrote:
> > .....
> > > It's possible I'm overlooking something critical. Maybe allocating
> > > huge (as compared to big) chunks of memory is hard. I'm sure
> > > a good kernel wizard can do it one way or the other. If nothing
> > > else, you hack the very early part of the kernel to put some memory
> > > in it's back pocket until you ask for it. Ugly, but effective.
>
> > That is the sort of stuff that I would not want to deal with. I am
> > much more comfortable with offloading the entire real time function
> > onto the dedicated hardware and keeping the PC out of the time
> > critical loop. When it is so easy to add a little bit of RAM to the
> > board, I don't get why anyone would want to have to make a complex OS
> > run a real time task???
>
> This is a sane reasoning I have heard more than once while discussing
> different projects (sometimes hypothetical). At this point my question
> usually is "so what is the bloody PC for in the design then?" . The
> usual
> answer is something like "well but they are so cheap and so
> popular..."...
The PC is there as the UI. If the job is using standard interfaces,
then it could be worth a bit of software work to avoid having to build
hardware. But this project is building a special board with an FPGA!
Heck, unless they have highly specialized interfaces to their project
they want to control, they could even do the whole thing on a
standard, COTS evaluation board if it has enough memory! There are
tons of boards available which include high speed interfaces like
Ethernet and USB and will support this project as-is other than a
specialized interface on the project end.
Then you can use the PC as a UI and don't even need to build
hardware!
Reply by Didi●April 21, 20082008-04-21
rickman wrote:
> .....
> > It's possible I'm overlooking something critical. Maybe allocating
> > huge (as compared to big) chunks of memory is hard. I'm sure
> > a good kernel wizard can do it one way or the other. If nothing
> > else, you hack the very early part of the kernel to put some memory
> > in it's back pocket until you ask for it. Ugly, but effective.
>
> That is the sort of stuff that I would not want to deal with. I am
> much more comfortable with offloading the entire real time function
> onto the dedicated hardware and keeping the PC out of the time
> critical loop. When it is so easy to add a little bit of RAM to the
> board, I don't get why anyone would want to have to make a complex OS
> run a real time task???
On Apr 12, 11:24 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >When you say that you don't need "real time software", I am missing
> >something. Once started, does the DMA run to completion by itself?
> >Maybe I am not up to speed with current software techniques on the PC,
> >but I thought even DMA required real time response to keep it queued
> >up and running. As far as allocating a block of memory to buffer the
> >data, I have no understanding of what it takes to allocate a buffer of
> >half a GB or more of contiguous memory. But like I said, I am not so
> >familiar with this approach.
>
> The basic idea is that you give the FPGA a pointer and length.
> It reads memory a cache block at a time as it needs it. When
> it's done, it sets a status bit and maybe generates an interrupt.
I understand perfectly how DMA works and all the permutations. But
you are glossing over all of the difficulty of getting physical
addresses from an OS and getting the software to let the hardware use
it.
> It's possible I'm overlooking something critical. Maybe allocating
> huge (as compared to big) chunks of memory is hard. I'm sure
> a good kernel wizard can do it one way or the other. If nothing
> else, you hack the very early part of the kernel to put some memory
> in it's back pocket until you ask for it. Ugly, but effective.
That is the sort of stuff that I would not want to deal with. I am
much more comfortable with offloading the entire real time function
onto the dedicated hardware and keeping the PC out of the time
critical loop. When it is so easy to add a little bit of RAM to the
board, I don't get why anyone would want to have to make a complex OS
run a real time task???
But like I said before, we are all comfortable with different
things.
Reply by James Waldby●April 15, 20082008-04-15
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?
In article <fd9dc69f-eb74-45d8-820e-
5d75b59b9a8e@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 **
Reply by Didi●April 14, 20082008-04-14
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.
Hi Didi,
"Didi" <dp@tgi-sci.com> wrote in message
news:018c2551-78ca-4749-8d91-c5bbed3c41d7@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
Reply by Didi●April 14, 20082008-04-14
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.
"Didi" <dp@tgi-sci.com> wrote in message
news:fd9dc69f-eb74-45d8-820e-5d75b59b9a8e@p25g2000pri.googlegroups.com...
> 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.
> Actually they typically think this is windows runing underneath on the
> first
> sight...
My first guess would have been DOS with an extender. :-)
> So it is all about plain human nature - practiclly all people I know
> are
> too scared to make a step aside of the known path, it takes some
> threat to their existance to venture that.
With most people, yes, this is absolutely true. Businesses as an entity are
the same way -- they'll keep using crappy tools that are well-known to them
because the thought of changing to something else just looks too risky... and
no one wants to be the fall guy if it turns out their evaluation of the
alternatives were wrong.
---Joel
Reply by Didi●April 14, 20082008-04-14
Joel Koltner wrote:
> "Didi" <dp@tgi-sci.com> wrote in message
> ...
> > But this is me, the rest of the world seems to consider designs which
> > do not rely on some intel/linux/MS monstrosity illegal nowadays.
>
> It's just that finding people to code on those platforms is easier and -- if
> you need the complexity of a GUI or full TCP/IP stack
> ....
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).
More, it fits it in a fraction of the flash space the wintelinux
alternatives
take.
> I bet plenty of people ask why your software doesn't "look" like standard
> Windows, don't they?
Actually they typically think this is windows runing underneath on the
first
sight...
As for programmers interfacing to this or that system the overhead is
negligible if you will use DPS. For this particular application -
moving
data from a tcp connection into some fifoed hardware - the job to do
on behalf of DPS can be explained in a message shorther than this one.
So it is all about plain human nature - practiclly all people I know
are
too scared to make a step aside of the known path, it takes some
threat to their existance to venture that. It does not matter how
tempting
those nice things under that tree look, danger may be lurking around
if
the place is so desolated.... :-).
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/0a16cc12dffb1ba5?dmode=source