Riscos and BlueTooth on a Pi

[John Greenwood]

Can the BlueTooth connectivity on a Rasberry pi 0 W be used by risc os?

John Greenwood

[Chris Hughes]

In message <584ae9114di...@john-greenwood.co.uk>

John Greenwood <icon.n...@john-greenwood.co.uk> wrote:

> Can the BlueTooth connectivity on a Rasberry pi 0 W be used by risc os?

Simple answer is No.


--
Chris Hughes
Wakefield Show - 18th April 2020 - https://www.wakefieldshow.org.uk

[Chris Evans (CJE/4D)]

In article <584ae9114di...@john-greenwood.co.uk>, John Greenwood

<URL:mailto:icon.n...@john-greenwood.co.uk> wrote:
> Can the BlueTooth connectivity on a Rasberry pi 0 W be used by risc os?

I did reply to the question when you first posted it on the 20th Feb!

# ch...@cjemicros.co.uk> wrote:
# In article <584561b36fi...@john-greenwood.co.uk>, John Greenwood
# <URL:mailto:icon.n...@john-greenwood.co.uk> wrote:
# > I see that some versions of the Rasberry pi, such as pi 0 W has Bluetooth.
# >
# > My question is, If Risc os is running on this board, can it use the
# > Bluetooth conectivity directly?
#
# There is no support in RISC OS for a Pi's Bluetooth or WiFi
#
# I know someone looked at Bluetooth a while ago but he didn't get far before
# having to admit defeat. Searching the ROOL forum should return this answer.
#
# Re WiFi: The third stage of the Network (TCP/IP) bounty should give us WiFi
# but stage two is still Ł4,000 short of its target!
#
#
# Chris Evans

Chris Evans

--

****** IGEPv5: The fastest RISC OS computer so far! *******
------------ http://www.cjemicros.co.uk/igepv5 ------------
CJE Micro's 'Raspberry Pi & RISC OS Specialists'
Tel: +44 (0)1903 523222
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
Unit 16 Arunside Ind. Est., Fort Road, Littlehampton, W.Sussex BN17 7QU

Don't let the urgent things in life, crowd out the important things!

[John Greenwood]

In article <ant03121...@client.cjemicros.co.uk>,

Chris Evans (CJE/4D) <ch...@cjemicros.co.uk> wrote:
> In article <584ae9114di...@john-greenwood.co.uk>, John Greenwood
> <URL:mailto:icon.n...@john-greenwood.co.uk> wrote:
> > Can the BlueTooth connectivity on a Rasberry pi 0 W be used by risc os?

> I did reply to the question when you first posted it on the 20th Feb!

Sorry about that. Not sure how I missed reply.

> # ch...@cjemicros.co.uk> wrote: # In article
> <584561b36fi...@john-greenwood.co.uk>, John Greenwood #
> <URL:mailto:icon.n...@john-greenwood.co.uk> wrote: # > I see that
> some versions of the Rasberry pi, such as pi 0 W has Bluetooth. # > # >
> My question is, If Risc os is running on this board, can it use the # >
> Bluetooth conectivity directly? # # There is no support in RISC OS for
> a Pi's Bluetooth or WiFi

Pity. As a matter of interest only, what operating systems that run on a
Pi 0 W do support Bluetooth?

I have a project which is basically about hardware but where I would need
a bit of programme that I can modify, preferably in a familiar language
such as Risc OS Basic. Bluetooth would be a bonus but not essential.

Would love to hear from anyone who could help. Results would be open
source and I would like to think of interest to the community!

> # # I know someone looked at Bluetooth a while ago but he didn't get
> far before # having to admit defeat. Searching the ROOL forum should
> return this answer.

Had a look, thought I found a post dated 2020 but can't find it again.

[druck]

On 04/03/2020 12:39, John Greenwood wrote:
> Pity. As a matter of interest only, what operating systems that run on a
> Pi 0 W do support Bluetooth?

Every other supported OS, see https://www.raspberrypi.org/downloads/ but
I would stick to Raspbian as that has the best support for drivers.

> I have a project which is basically about hardware but where I would need
> a bit of programme that I can modify, preferably in a familiar language
> such as Risc OS Basic. Bluetooth would be a bonus but not essential.

Well you aren't going to get BBC Basic, and even if you did you would
have to use a very complicated low level API. If you take a bit of time
to Python, you can take advantage of the PyBluez library which will give
you a much higher level interface, see
http://www.python-exemplary.com/index_en.php?inhalt_links=navigation_en.inc.php&inhalt_mitte=raspi/en/bluetooth.inc.php

---druck

[John Greenwood]

In article <r3p11o$u0p$1...@dont-email.me>,

Forget about Bluetooth, I just want to read some of the GPIO pins on an
interrupt. Can BBC BASIC still do this?

John

[Alan Adams]

In message <584c812832i...@john-greenwood.co.uk>

You can READ the pins. What you can't do is set up an interrupt to occur.
The GPIO mo0dule doesn't allow setting up of interrupts, and even if
writing assembler, the addresses to use aren't documented.

The offsets from the hardware base are documented, but it isn't clear
where they are mapped into the address space, or whether the mapped area
is accessible in user mode. The HAL doesn't seem to help either.

> John



--
Alan Adams, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/

[Alan Adams]

In message <3d19854c58...@ArmX6.adamshome.org.uk>

I had a similar requirement. The solution, which may not work for you, was
a small amount of assembler connected to the TickerV vector, which
therefore gets called 100 times per second. Each time it used GPIO calls
to check two of the pins, and if there was a change, then it changed a
pollword, and stored information about the change in a shared memory
space. It resets the pins rready for the nexct change.

The GPIO pins can be configured from BASIC to determine whether they
respond to a rising or falling edge, or a state.

The BASIC code uses Wimp_PollIdle, with the pollword address in R3. When
the pollword changes, poll reason 13 is returned. The code on pollreason
13 looked into the shared memory for the information.

The shared memory space has to be in the RMA.

[David Higton]

In message <584bf4790bi...@john-greenwood.co.uk>

John Greenwood <icon.n...@john-greenwood.co.uk> wrote:

> I have a project which is basically about hardware but where I would need a
> bit of programme that I can modify, preferably in a familiar language such
> as Risc OS Basic. Bluetooth would be a bonus but not essential.
>
> Would love to hear from anyone who could help. Results would be open source
> and I would like to think of interest to the community!

Are you going to give us a clue as to what the app is to do?

David

[John Greenwood]

In article <3d64fa4c58.DaveMeUK@BeagleBoard-xM>,

Yes I intend to post all the details of this project on my blog site but I
have got a silly problem with passwords. I am getting help to fix this and
then I hope to reveal all!

John

[John Greenwood]

In article <de48874c58...@ArmX6.adamshome.org.uk>,

This is actually near what I want. A bit of assembler would be called,
probably on this TickerV vector, which would read the state of some of the
pins and do some bitwise manipulation and some integer arithmatic.

A considerable time ago I had a fun project to make a novel display on my
then Archemedes. This used a block of assembler running on the screen
refresh interrupt to write individual pixels to the display. My memory of
this is that it was a lot more ambitious than what I am prosing. I am
assuming that assembler editing is basically unchanged.

John

[Steve Fryatt]

On 8 Mar, John Greenwood wrote in message
<584e2238ddi...@john-greenwood.co.uk>:

> A considerable time ago I had a fun project to make a novel display on my
> then Archemedes. This used a block of assembler running on the screen
> refresh interrupt to write individual pixels to the display. My memory of
> this is that it was a lot more ambitious than what I am prosing. I am
> assuming that assembler editing is basically unchanged.

Aside from it needing to be ARMv7 (possibly v5 for the Pi 1) compliant, no.
That's still a learning curve if you're knowledge is all stuff that ran on
the ARMv2 in the Arc, however.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[John Greenwood]

In article <mpro.q6w0ml04...@stevefryatt.org.uk>,

Thanks for the warning. I can see that I need to be wary of pushing off
into the deep end!

[David Higton]

In message <584e2238ddi...@john-greenwood.co.uk>

John Greenwood <icon.n...@john-greenwood.co.uk> wrote:

> In article <de48874c58...@ArmX6.adamshome.org.uk>,
> Alan Adams <al...@adamshome.org.uk> wrote:
> > In message <3d19854c58...@ArmX6.adamshome.org.uk>
> > Alan Adams <al...@adamshome.org.uk> wrote:
>
>
> > I had a similar requirement. The solution, which may not work for you,
> > was a small amount of assembler connected to the TickerV vector, which
> > therefore gets called 100 times per second. Each time it used GPIO calls
> > to check two of the pins, and if there was a change, then it changed a
> > pollword, and stored information about the change in a shared memory
> > space. It resets the pins rready for the nexct change.
>
> > The GPIO pins can be configured from BASIC to determine whether they
> > respond to a rising or falling edge, or a state.
>
> > The BASIC code uses Wimp_PollIdle, with the pollword address in R3. When
> > the pollword changes, poll reason 13 is returned. The code on pollreason
> > 13 looked into the shared memory for the information.
>
> > The shared memory space has to be in the RMA.
>
> This is actually near what I want. A bit of assembler would be called,
> probably on this TickerV vector, which would read the state of some of the
> pins and do some bitwise manipulation and some integer arithmatic.

You could do it with a module written in C, which would spare you any
issues across different platforms - C is cross-platform, assembler
is more challenging.

Also, if centisecond resolution isn't good enough, you can set up a
faster ticker and use that. It's what I did with the USB MIDI module.

David

[John Greenwood]

In article <5c92974e58.DaveMeUK@BeagleBoard-xM>,

David Higton <da...@davehigton.me.uk> wrote:
> In message <584e2238ddi...@john-greenwood.co.uk>
> John Greenwood <icon.n...@john-greenwood.co.uk> wrote:

> > In article <de48874c58...@ArmX6.adamshome.org.uk>,
> > Alan Adams <al...@adamshome.org.uk> wrote:
> > > In message <3d19854c58...@ArmX6.adamshome.org.uk>
> > > Alan Adams <al...@adamshome.org.uk> wrote:


> > > I had a similar requirement. The solution, which may not work for
> > > you, was a small amount of assembler connected to the TickerV
> > > vector, which therefore gets called 100 times per second. Each time

> > > it used GPIO calls to check two of the pins.

> > This is actually near what I want. A bit of assembler would be called,
> > probably on this TickerV vector, which would read the state of some of
> > the pins and do some bitwise manipulation and some integer arithmatic.

> You could do it with a module written in C, which would spare you any
> issues across different platforms - C is cross-platform, assembler
> is more challenging.

You are right, C would be the sensible choice. And if things work out
maybe someone will do this.

But for now I have no experience of C but, as I mentioned above, I did
have a project using assembler some time ago.

> Also, if centisecond resolution isn't good enough, you can set up a
> faster ticker and use that. It's what I did with the USB MIDI module.

Centisecond resolution will be fine.

John

[Keys]

In article <584f1ec4cbi...@john-greenwood.co.uk>,

John Greenwood <icon.n...@john-greenwood.co.uk> wrote:
> In article <5c92974e58.DaveMeUK@BeagleBoard-xM>,
> David Higton <da...@davehigton.me.uk> wrote:

> > You could do it with a module written in C, which would spare you any
> > issues across different platforms - C is cross-platform, assembler
> > is more challenging.

> You are right, C would be the sensible choice. And if things work out
> maybe someone will do this.

> But for now I have no experience of C but, as I mentioned above, I did
> have a project using assembler some time ago.

The background to this project can be seen at:
http://www.john-greenwood.co.uk/innovation/the-writer-project/

My main objective has been to make a better keyboard for my personal use
and I have made some progress since posting the above which I intend to
post on my blog site (but this is currently broken).

A Raspberry pi 0 for £5 is a new factor which might give me easy access to
the controlling key response.

So far this has been just for myself. I quite liked the idea of writing
some assembly language, more satisfying than sudoku, but getting to grips
with usb protocols is not for me.

I am now thinking that there may be a wider project that would provide the
functionality I need on a pi. I would like to provide the experimental
keys a standardised connection.

So I have a question:

What are the part numbers of the header on the pi and the socket that fits
it? The latter would be soldered into a bit of Veroboard. (I have bought
stuff from both Farnell and RS)

I am continuing with experimenting with key hardware and having private
discussions about a wider project. When I am ready I will start a new, non
acorn related thread somewhere.

John