[9fans] radio

[9fans] radio

[Steve Simon]

Ok,

spurred into action. I have pushed out some work in progress.

A little radio app for plan9. This has few features and may not
seem worth the effort to some but it is planned to be the basis for
an embedded radio device so it needs a little GUI and user interface.

Currently I use this at work every day, the radio appliance has
stalled for now but should restart soon.

find the source (including audio encoders and decoders) at
/n/sources/contrib/steve/radio.tbz

unpack into /sys/src/cmd/audio

look at Readme file.

enjoy

-Steve

Re: [9fans] radio

[Bakul Shah]

On Thu, 08 May 2014 12:06:11 BST "Steve Simon" <steve@quintile.net> wrote:
>
> A little radio app for plan9. This has few features and may not
> seem worth the effort to some but it is planned to be the basis for
> an embedded radio device so it needs a little GUI and user interface.
>
> Currently I use this at work every day, the radio appliance has
> stalled for now but should restart soon.

Nice!

Looks like you forgot to include json.h

What DAC are you planning to use? And display?
The PiTFT touchscreen display looks interesting.

I need to find time to play with a couple of toys:

1. A software defined radio receiver. This may not be very
   straightforward as it goes through the dreaded USB.
   http://www.adafruit.com/product/1497

2. A GPS device, interfaces via a 9600 baud link.
   My goal is to have a stratum one clock.
   http://www.adafruit.com/products/746

Re: [9fans] radio

[Steve Simon]

I have a hifiberry (http://www.hifiberry.com/) nicely minimalist,
though no driver at present - I will await the GSOC project :-)

I have some itron VFDs from work, 256 x 64 pixel. I like these as
the visibility is excellent. The only annoyance is they have
a parallel interface and I use up all the PI's GPIOs.

I also need to interface a rotary encoder for the tuning knob which
is also a pain - not complex enough to justify an FPGA, but a bit too
much to poll when the PI is doing audio decode as well.

Thinking of adding a PIC or an AVR just for the encoder / VFD interface
and talking i2c to it.

we will see.

-Steve

Re: [9fans] radio

[Bakul Shah]

On Thu, 08 May 2014 18:58:31 BST "Steve Simon" <steve@quintile.net> wrote:
> I have a hifiberry (http://www.hifiberry.com/) nicely minimalist,
> though no driver at present - I will await the GSOC project :-)

> I have some itron VFDs from work, 256 x 64 pixel. I like these as
> the visibility is excellent. The only annoyance is they have
> a parallel interface and I use up all the PI's GPIOs.

> I also need to interface a rotary encoder for the tuning knob which
> is also a pain - not complex enough to justify an FPGA, but a bit too
> much to poll when the PI is doing audio decode as well.

No need for polling.  The BCM2835 can handle edge triggered
interrupts.  Or you can use a PAL or CPLD.

> Thinking of adding a PIC or an AVR just for the encoder / VFD interface
> and talking i2c to it.

Re: [9fans] radio

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

I suggested porting rtlsdr library for a GSoC project, but not takers;  if
anyone is interested in collaborating on this let me know. the majority of
the work is moving the library off of libusb and replacing the pthread junk
with thread(2).

rtlsdr handles any DVB-T receiver that uses the RTL2832U -- including the
product from adafruit (btw, i have two of them and they work great with
linux and mac os x).  you can do AM, FM and a lot more. i am using them for
receiving ADSB and ACARS data.

-Skip


On Thu, May 8, 2014 at 10:19 AM, Bakul Shah <bakul@bitblocks.com> wrote:

> On Thu, 08 May 2014 12:06:11 BST "Steve Simon" <steve@quintile.net> wrote:
> >
> > A little radio app for plan9. This has few features and may not
> > seem worth the effort to some but it is planned to be the basis for
> > an embedded radio device so it needs a little GUI and user interface.
> >
> > Currently I use this at work every day, the radio appliance has
> > stalled for now but should restart soon.
>
> Nice!
>
> Looks like you forgot to include json.h
>
> What DAC are you planning to use? And display?
> The PiTFT touchscreen display looks interesting.
>
> I need to find time to play with a couple of toys:
>
> 1. A software defined radio receiver. This may not be very
>    straightforward as it goes through the dreaded USB.
>    http://www.adafruit.com/product/1497
>
> 2. A GPS device, interfaces via a 9600 baud link.
>    My goal is to have a stratum one clock.
>    http://www.adafruit.com/products/746
>
>

[-- Attachment #2: Type: text/html, Size: 2186 bytes --]

Re: [9fans] radio

[Steve Simon]

Perhaps we should  a page on the wiki:

	"Work in progress"
	"Stalled projects"
	"Work I plan to progress"
	"Work I would like somone to do"

The theroy is it might inspire people and maybe reduce duplication of effort.

Just a thought.

-Steve

Re: [9fans] radio

[Steven Stallion]

On Thu, May 8, 2014 at 2:04 PM, Steve Simon <steve@quintile.net> wrote:
> Perhaps we should  a page on the wiki:
>
>         "Work in progress"
>         "Stalled projects"
>         "Work I plan to progress"
>         "Work I would like somone to do"
>
> The theroy is it might inspire people and maybe reduce duplication of effort.

+1, though I believe this has already been done in TODO, hasn't it?

Re: [9fans] radio

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

that's what i was thinking too. i think most of the time, most of the
information is available; it's just that they don't show up in a search or
no search is done.

P.S. i'm sure sp9sss conspiracy theorists will disagree :)



On Thu, May 8, 2014 at 1:07 PM, Steven Stallion <sstallion@gmail.com> wrote:

> On Thu, May 8, 2014 at 2:04 PM, Steve Simon <steve@quintile.net> wrote:
> > Perhaps we should  a page on the wiki:
> >
> >         "Work in progress"
> >         "Stalled projects"
> >         "Work I plan to progress"
> >         "Work I would like somone to do"
> >
> > The theroy is it might inspire people and maybe reduce duplication of
> effort.
>
> +1, though I believe this has already been done in TODO, hasn't it?
>
>

[-- Attachment #2: Type: text/html, Size: 1277 bytes --]

Re: [9fans] radio

[Steve Simon]

> Looks like you forgot to include json.h

I put my libjson.tgz and libxml.tgz on sources.

-Steve

Re: [9fans] radio

[erik quanstrom]

On Fri May  9 08:36:54 EDT 2014, steve@quintile.net wrote:
> > Looks like you forgot to include json.h
>
> I put my libjson.tgz and libxml.tgz on sources.

i would recommend renaming the J* files to j* files, and the functions
from J* to j*, as the tradition is to use lowercase.

- erik

Re: [9fans] radio

[lucio]

> i would recommend renaming the J* files to j* files, and the functions
> from J* to j*, as the tradition is to use lowercase.

Go standards strike! (not the J* files, though)

++L

Re: [9fans] radio

[erik quanstrom]

On Fri May  9 08:56:34 EDT 2014, lucio@proxima.alt.za wrote:
> > i would recommend renaming the J* files to j* files, and the functions
> > from J* to j*, as the tradition is to use lowercase.
>
> Go standards strike! (not the J* files, though)

this is not go.  we should not use go standards in plan 9 c,
we should use plan 9 c standards in plan 9 c.

- erik

Re: [9fans] radio

[Krystian Lewandowski]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

I was working on GPIO under Plan9 - very simple thing but also supports
edge-raising/falling events. I had simple C code to print what pin
triggered an event. I'll try to push this simple test to github during
weekend. Though i'm not sure how it can be integrated - is events counting
enough?

Krystian
https://github.com/elewarr/plan9-bcm

2014-05-08 20:36 GMT+02:00 Bakul Shah <bakul@bitblocks.com>:

> On Thu, 08 May 2014 18:58:31 BST "Steve Simon" <steve@quintile.net> wrote:
> > I have a hifiberry (http://www.hifiberry.com/) nicely minimalist,
> > though no driver at present - I will await the GSOC project :-)
>
> > I have some itron VFDs from work, 256 x 64 pixel. I like these as
> > the visibility is excellent. The only annoyance is they have
> > a parallel interface and I use up all the PI's GPIOs.
>
> > I also need to interface a rotary encoder for the tuning knob which
> > is also a pain - not complex enough to justify an FPGA, but a bit too
> > much to poll when the PI is doing audio decode as well.
>
> No need for polling.  The BCM2835 can handle edge triggered
> interrupts.  Or you can use a PAL or CPLD.
>
> > Thinking of adding a PIC or an AVR just for the encoder / VFD interface
> > and talking i2c to it.
>
>

[-- Attachment #2: Type: text/html, Size: 1971 bytes --]

Re: [9fans] radio

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

FYI, another item on my todo list is porting the RF24 library to plan9-bcm.
i use nrf24l01+ devices between arduinos and a pi (in Go on linux) for
temp/humidity telemetry.  the device uses the SPI interface.

on a somewhat related note, is anyone building support for Go on Plan 9/ARM?



On Fri, May 9, 2014 at 7:11 AM, Krystian Lewandowski <krystian.lew@gmail.com
> wrote:

> I was working on GPIO under Plan9 - very simple thing but also supports
> edge-raising/falling events. I had simple C code to print what pin
> triggered an event. I'll try to push this simple test to github during
> weekend. Though i'm not sure how it can be integrated - is events counting
> enough?
>
> Krystian
> https://github.com/elewarr/plan9-bcm
>
> 2014-05-08 20:36 GMT+02:00 Bakul Shah <bakul@bitblocks.com>:
>
> On Thu, 08 May 2014 18:58:31 BST "Steve Simon" <steve@quintile.net> wrote:
>> > I have a hifiberry (http://www.hifiberry.com/) nicely minimalist,
>> > though no driver at present - I will await the GSOC project :-)
>>
>> > I have some itron VFDs from work, 256 x 64 pixel. I like these as
>> > the visibility is excellent. The only annoyance is they have
>> > a parallel interface and I use up all the PI's GPIOs.
>>
>> > I also need to interface a rotary encoder for the tuning knob which
>> > is also a pain - not complex enough to justify an FPGA, but a bit too
>> > much to poll when the PI is doing audio decode as well.
>>
>> No need for polling.  The BCM2835 can handle edge triggered
>> interrupts.  Or you can use a PAL or CPLD.
>>
>> > Thinking of adding a PIC or an AVR just for the encoder / VFD interface
>> > and talking i2c to it.
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2731 bytes --]

Re: [9fans] radio

[Bakul Shah]

On Fri, 09 May 2014 16:11:00 +0200 Krystian Lewandowski <krystian.lew@gmail.com> wrote:
>
> I was working on GPIO under Plan9 - very simple thing but also supports
> edge-raising/falling events. I had simple C code to print what pin
> triggered an event. I'll try to push this simple test to github during
> weekend. Though i'm not sure how it can be integrated - is events counting
> enough?

I think for a rotary encoder you'd want to know about every
transition. One idea is to return 1/0 on a up/down transition
to a blocking read. Let the user re-enable the corresponding
interrupt by writing 1 to the same fd.

The user code reads from two pins and figures out which way
the knob is turning. Similarly you can have user code count
events if that is what you want.

Re: [9fans] radio

[Krystian Lewandowski]

Wiadomość napisana przez Bakul Shah <bakul@bitblocks.com> w dniu 10 maj 2014, o godz. 01:21:

> On Fri, 09 May 2014 16:11:00 +0200 Krystian Lewandowski <krystian.lew@gmail.com> wrote:
>> 
>> I was working on GPIO under Plan9 - very simple thing but also supports
>> edge-raising/falling events. I had simple C code to print what pin
>> triggered an event. I'll try to push this simple test to github during
>> weekend. Though i'm not sure how it can be integrated - is events counting
>> enough?
> 
> I think for a rotary encoder you'd want to know about every
> transition. One idea is to return 1/0 on a up/down transition
> to a blocking read. Let the user re-enable the corresponding
> interrupt by writing 1 to the same fd.
> 
> The user code reads from two pins and figures out which way
> the knob is turning. Similarly you can have user code count
> events if that is what you want.
> 


Hi,
i’ve added a simple edge events listener test. 

The test reads 32 bits from #G/gpio/event where each bit position corresponds to „bcm” naming scheme, so bit 17 means GPIO0 (was easier this way).
#G/gpio/event blocks on read, while #G/gpio/GPIO0 does not - just returns current value (and there is no need to seek to beginning).

Works with a single button. ;)

https://github.com/elewarr/gpio_test/blob/master/events.c

cpu% ./events
1: pin 17, state changed
	GPIO0 state=0
2: pin 17, state changed
	GPIO0 state=1
3: pin 17, state changed
	GPIO0 state=0
4: pin 17, state changed
	GPIO0 state=1

Cheers,
Krystian