 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:
>
>> As I understand it the kernel may as well be the
>> same, assuming the same processor, but the interfaces, i.e. drivers, to
>> the rest of the stuff, isn't.
>
> Um, no, actually, the APIs would be the same because it's the same kernel
> code.
The kernel code (at least, the "same" kernel code) is generally not what
provides the APIs to device drivers on embedded devices.
> Wait, what? You seem to be contradicting yourself....
No, he's saying you *could* do it, but generally that isn't what happens.
People don't port X11 to their cell phone, they use directFB. People don't
port Pulse to their cell phone, they use whatever API works with the
hardware. They don't use udev, they just write directly to the USB devices
they support. Etc.
That the drivers are in the kernel tree on *your* devices doesn't mean
they're part of the kernel on other devices.
> unless you're talking
> about something like the proprietary NVidia or ATI drivers.
Well, unless you're talking about anything that's not generic, really. Does
the standard Linux kernel have device drivers for CDMA chips? 4" LED
touchscreens? Power control modules for turning on and off various parts of
various chips? GSM codec hardware?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 31 Oct 2010 14:13:59 -0700, Darren New wrote:
> Jim Henderson wrote:
>> Without a doubt. Windows' roots (starting with NT) was on DEC
>> equipment, after all, not x86.
>
> Heh. I don't think they took actual VMS code and tried to port it for
> Windows.
Maybe, maybe not. I have a vague recollection of a book by Dave Cutler
(I think it was) who went to MS from DEC and was responsible for the bulk
of kernel coding in NT. Probably didn't take DEC code (otherwise DEC
could've sued him), true.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 31 Oct 2010 14:21:44 -0700, Darren New wrote:
> Jim Henderson wrote:
>> On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:
>>
>>> As I understand it the kernel may as well be the
>>> same, assuming the same processor, but the interfaces, i.e. drivers,
>>> to the rest of the stuff, isn't.
>>
>> Um, no, actually, the APIs would be the same because it's the same
>> kernel code.
>
> The kernel code (at least, the "same" kernel code) is generally not what
> provides the APIs to device drivers on embedded devices.
Device drivers talk to the kernel through APIs the kernel provides,
though.
>> Wait, what? You seem to be contradicting yourself....
>
> No, he's saying you *could* do it, but generally that isn't what
> happens. People don't port X11 to their cell phone, they use directFB.
> People don't port Pulse to their cell phone, they use whatever API works
> with the hardware. They don't use udev, they just write directly to the
> USB devices they support. Etc.
DirectFB IIRC is in the kernel...X isn't. Pulse isn't kernel-level
stuff, it's middleware. Sure the middleware isn't the same.
My router's kernel has devpts mounted and uses procfs. Those are
provided by the kernel (or by kernel drivers interfacing to the kernel).
> That the drivers are in the kernel tree on *your* devices doesn't mean
> they're part of the kernel on other devices.
>
> > unless you're talking
> > about something like the proprietary NVidia or ATI drivers.
>
> Well, unless you're talking about anything that's not generic, really.
"something like the [...]" - now does that imply anything other than
"anything that's not generic"?
> Does the standard Linux kernel have device drivers for CDMA chips? 4"
> LED touchscreens? Power control modules for turning on and off various
> parts of various chips? GSM codec hardware?
Define "standard Linux kernel"?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Maybe, maybe not. I have a vague recollection of a book by Dave Cutler
> (I think it was) who went to MS from DEC and was responsible for the bulk
> of kernel coding in NT.
Yep. But the fact that Cutler came from DEC says nothing about how portable
the OS he helped write based on his experience was. People give them crap
for "stealing" VMS, but when you work at that level, your experience is why
you get hired.
Also, I think the XBox360 runs a version of Windows ported to a PowerPC, so
I think it's more ambiguous than you might think.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/31/2010 1:51 PM, Jim Henderson wrote:
> On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:
>
>> How so? Drivers can be compiled into kernel, but most are not any more,
>> and they can be added or removed, without effecting the kernel itself.
>> You do have to compile it for the specific processor though, so where
>> exactly do you think I contradicted myself?
>
> Looking at the source for the version of Android on my phone, I see the
> drivers in with the kernel source.
>
> My router (which is not Android-based, but Linux based) is the same. Not
> x86 hardware, but it uses drivers for hardware that is readily available
> on x86 systems, so the drivers are in the kernel tree.
>
> Jim
Yes, but, as I said, you could add ones you don't have, or remove the
ones that are there. The kernel needs to know how to talk to the
hardware, but it doesn't give a crap, beyond the obvious need to run on
the processor you compiled to, *what* that hardware actually is. That
was my point. Sure, for stand alone cases, a lot of the drivers are in
the kernel tree. Same, to an extent, for "some" of the common ones for
PCs. Doesn't mean they have to be there, beyond the basics needed to get
something loaded in the first place.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 01 Nov 2010 17:45:06 -0700, Patrick Elliott wrote:
> Yes, but, as I said, you could add ones you don't have, or remove the
> ones that are there. The kernel needs to know how to talk to the
> hardware, but it doesn't give a crap, beyond the obvious need to run on
> the processor you compiled to, *what* that hardware actually is.
As software, it *can't* "care". I don't understand your point at all.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/28/2010 3:12 PM, Darren New wrote:
> Well, no. There's interrupts, sensors saying how many coins are there,
> to signal when it's out of coins or has been filled incorrectly, timing
> delays for releasing various coins, dealing with power going out and
> coming back on while the mechanism is operating, etc.
Surely a lot of that should be handled by the firmware. How does it
communicate? RS232/RS485, TCP/IP, USB, CAN, etc?
What data does the device communicate back to the host? What does the
host send to the device?
Obviously there must be some sort of protocol, and the device's firmware
probably only communicates the bare minimum to work with the host. If
you don't have the messages it expects and the messages it sends laid
out for you, it could be a bit of a challenge. You'll probably miss a
corner case somewhere. (For example, upon host init, the coin counter
expects to be sent a certain set of data to initialize properly, or
perhaps you missed the "coin stuck" message because you never saw it in
your reverse engineering tests)
> Everything's trivial if you aren't the one writing the code.
Of course!
>> I guess the real question is "why are people manufacturing devices
>> that will only ever be used as part of an embedded system writing
>> drivers for it that won't work as part of an embedded system?"
>
> Except it *is* a driver working as part of an embedded system, obviously.
>
Also, less expensive to support only one embedded OS.
Of course, I wouldn't be surprised that even if the device communicated
over a common, easily accessible protocol that it's opaque through a set
of DLL's. I've seen a lot of devices like that when I was working on HMI
code. Some of the basic sensors are really quite easy to deal with. We
had a prox sensor whose communication protocol was to raise a single
line (RTS, I think ...) on the RS232 port as an indicator that something
was in proximity. Extremely simple to deal with.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/28/2010 4:35 PM, Orchid XP v8 wrote:
>
> More specifically, given that Windows should never, ever, under any
> circumstances, be running on a single-function device like this, why are
> all the device drivers being written for Windows?
>
Um... Because Embedded Windows is extremely common, and very easy to
write software for? Embedded Windows isn't your garden variety desktop
OS, though it mirrors a lot of the desktop stuff in regards to API and
such; heck, a laser projector we used had only an interface to it in C#.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/29/2010 4:04 AM, Invisible wrote:
>>> More specifically, given that Windows should never, ever, under any
>>> circumstances, be running on a single-function device like this, why
>>> are all the device drivers being written for Windows?
>>
>> What would you run instead?
>
> How about just writing the few dozen lines of C is actually takes to
> prod a few bits in the framebuffer, write some stuff on the screen, talk
> to the card reader a bit, and make the dispenser chuck out some money?
There's a reason the embedded system has an OS. Sure, if it were running
a microcontroller, you'd probably be doing just that, and spending a
huge amount of man-hours writing code to transfer bitmaps from
advertisers to the display, creating a font (or reading a well known
font format) to display information on the screen, to do basic drawing
functions for HMI stuff, to interact with the flash drive on a hardware
level, to deal with the TCP/IP protocol through an embedded NIC so it
can communicate with the machine, or to program the UART to communicate
with the one sensor that sends back everything in RS232. To handle
encryption and everything else.
Real simple. :)
> OK, you're right, it probably *is* faster to take some code that
> somebody else already wrote. But I still think grabbing the relevant
> parts of (say) the Linux kernel is going to be quicker and easier than
> porting the entire Windows OS (most of which you don't need) to a new
> platform and trying to make it work...
Always... There's a lot to it, actually. Sure, the hardware vendor may
choose to embed Linux as their OS of choice. But the more common choice
is embedded Windows, so that's what gets used.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/29/2010 11:21 AM, Patrick Elliott wrote:
> In this specific case, probably true, but then you have "phones" and
> other things running this OS too.. Gosh, my phone has 2GB memory. Gee,
> what apps do you have on it? Hmm, not much, I only have 200MB free, the
> rest is Windows. lol
>
> Ok, ok, its not *that* bad, but still.. ;)
>
We've managed to get Embedded Windows XP under 1GB.. ;) Of course, once
you install the .NET framework, and all of the other things needed to
run the machine, the install shoots up to 1.5-2GB.. :D
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
