>> Or just, you know, the Pi emulator, which doesn't cost money. ;-)
>
> Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P



Presumably if you hunt far enough you can find one for available at the 


> Drawback of the Pi emulator is that it doesn't come with all those neat
> I/O pins ;)

Pffft. What would I even do with those? It's not like any high-level 
language lets you interface with them anyway. And you'd have to hook up 
a bunch of relays to use them to drive anything that takes more than 
0.3mW of power. :-P

Post a reply to this message

Am 05.02.2015 um 19:49 schrieb Orchid Win7 v1:

>>> Or just, you know, the Pi emulator, which doesn't cost money. ;-)
>>
>> Because a Raspberry Pi is soooooo extraordinarily expensive, sure... :P
>


Ah, yes... if you insist on buying yet another keyboard, mouse, USB hub, 
micro-USB power adaptor, WiFi dongle and HDMI cable with that...

If you already do have those components flying around your house 
somewhere, you /might/ however try ordering a bare Pi mainboard for 18 
to 40 GBP, depending on the model. At Maplin. No further hunting required.


>> Drawback of the Pi emulator is that it doesn't come with all those neat
>> I/O pins ;)
>
> Pffft. What would I even do with those? It's not like any high-level
> language lets you interface with them anyway.


Is Haskell a high-level enough language for your taste? :P

http://hackage.haskell.org/package/HPi


Not to mention C, C++, C#, Ruby, Perl, Python, Scratch, Java, Pascal and 
BASIC of course; you can even control them from the command shell:

http://elinux.org/RPi_Low-level_peripherals#GPIO_Code_examples


> And you'd have to hook up
> a bunch of relays to use them to drive anything that takes more than
> 0.3mW of power. :-P

Well, yeah, that's the usual way to drive anything even remotely 
power-hungry with any digital controller.

As for the 0.3mW, if you go for the Model A you can go up to 0.5mW.

Post a reply to this message

Am 02.02.2015 um 19:16 schrieb Orchid Win7 v1:
> Is it even still *possible* to map the graphics card's
> framebuffer into the CPU's address space?

On Linux (and surely other unix clones): no problem at all!

Just open /dev/fb0, making some ioctl()'s on it to get the size and the
pixel type of the frame buffer and you can call mmap() to the file
descriptor to map the whole frame buffer memory into your address space.

> Similarly, if I want to ask the harddisk to do something, do I need to
> explicitly construct ATAPI commands, or does the chipset do that for me?

just mmap() your /dev/sd* to your address space and feel free to
read/write into it.

> I'm not trying to actually *write* a device driver, I'm just curious as
> to how this stuff works these days.

It works good. And a lot of software use these interfaces today (X
server, database systems etc.)

Lars R.

Post a reply to this message

On 17/02/2015 11:15 PM, Lars R. wrote:
>> Similarly, if I want to ask the harddisk to do something, do I need to
>> explicitly construct ATAPI commands, or does the chipset do that for me?
>
> just mmap() your /dev/sd* to your address space and feel free to
> read/write into it.

Yeah, that's not quite it.

When you ask the kernel "hey, mmap() this file for me, will ya?", what's 
actually happening is that when you try to access those memory pages, 
your application gets suspended while the kernel goes and issues the 
necessary disk I/O commands to read a copy of that file into memory. 
Your application then gets resumed, making it *look like* the logical 
file is indeed mapped into the address space.

This isn't the same thing at all. This is clever software making the 
process *look* simple, which isn't at all the same as the process 
actually *being* simple.

Case in point: you can mmap() files residing on an NFS server on another 
continent. Clearly the CPU and chipset know *nothing* about TCP sliding 
windows and go-back-N acknowledgements. That's why you have a huge, 
complex operating system controlling the CPU. ;-)

What I'm asking is, can the hardware itself map the framebuffer (or 
whatever) into the address space, not whether some program can simulate 
this behaviour.

Post a reply to this message

> What I'm asking is, can the hardware itself map the framebuffer (or
> whatever) into the address space,

Even good-old ISA cards were able to do so (ok only in the first 16 MB
of physical address space *G*). With PCI they became able to tell the
chipset about the size of their "card memory" and the memory controller
in the chipset will respect these in its internal memory mapping (and
tell it to the CPU (and the operating system) so the CPU will disable
its interlal L1 caches etc. for these address ranges etc.)

Just look at /proc/iomem to see how heterogenious the physical address
space is on modern computers.

The mmap() just maps portions of this physical address space into your
logical/program/user address space.

Lars R.

Post a reply to this message

On 18/02/2015 12:15 PM, Lars Rohwedder wrote:
> Just look at /proc/iomem to see how heterogenious the physical address
> space is on modern computers.

Now *that* sounds interesting...

Post a reply to this message