Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30133 > unrolled thread

Driving 7-Segment LEDs on Raspberry Pi

Back to article view | Back to comp.lang.java.programmer

Contents

  Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-20 01:28 -0700
    Re: Driving 7-Segment LEDs on Raspberry Pi Gordon Levi <gordon@address.invalid> - 2014-10-21 01:42 +1100
      Re: Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-24 05:20 -0700
        Re: Driving 7-Segment LEDs on Raspberry Pi Arne Vajhøj <arne@vajhoej.dk> - 2014-10-24 21:37 -0400
    Re: Driving 7-Segment LEDs on Raspberry Pi ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-20 17:16 +0000
      Re: Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-21 00:09 -0700
        Re: Driving 7-Segment LEDs on Raspberry Pi ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-21 09:22 +0000
          Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-21 08:43 -0400
            Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 06:42 +0000
              Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-10-22 08:02 +0000
                Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 10:49 +0000
              Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-22 08:52 -0400
                Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 14:00 +0000
                  Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-22 10:43 -0400
                    Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] thinbluernime <thinbluernime3@gmail.com> - 2014-10-22 16:34 +0000

#30133 — Driving 7-Segment LEDs on Raspberry Pi

For those, like me, who have been doing Java for a long time, it is truly amazing that Java lets us effortlessly drop down to the 0/1 bits and hardware level.

I had no experience of Raspberry Pi, and just a few hours of exploring and programming allowed me to control a cascade of five 7-segment LED displays.

Here's a detailed article of my experience:

http://www.artekit.eu/controlling-the-ak-mr-wood-l-from-java-se-on-a-raspberry-pi/

The ease with which the above was made possible is, admittedly, in part due to the existence of the Pi4J library for the Rpi.

Does anyone know of any other techniques to hit the Raspberry GPIO pins without using Pi4J?

   Laurence

[toc] | [next] | [standalone]

#30134

javalaurence@gmail.com wrote:

>For those, like me, who have been doing Java for a long time, it is truly amazing that Java lets us effortlessly drop down to the 0/1 bits and hardware level.
>
>I had no experience of Raspberry Pi, and just a few hours of exploring and programming allowed me to control a cascade of five 7-segment LED displays.
>
>Here's a detailed article of my experience:
>
>http://www.artekit.eu/controlling-the-ak-mr-wood-l-from-java-se-on-a-raspberry-pi/
>
>The ease with which the above was made possible is, admittedly, in part due to the existence of the Pi4J library for the Rpi.
>
>Does anyone know of any other techniques to hit the Raspberry GPIO pins without using Pi4J?
>
>   Laurence

Java ME is available for the Pi <http://tinyurl.com/o8dobkm>. Oracle
have a free on-line course showing how to program it remotely with a
Windows box using Netbeans <http://tinyurl.com/l87oss6>. To reach a
comparable level to your blog you just need a breadboard and a GPIO
breakout similar to the one you described plus a push button switch
and a couple of LEDs. The course goes on to cover several other ways
to communicate with a Pi.

I have installed xrdp and samba on my Pi so I can use Windows Remote
Desktop and Windows Explorer to talk to it. Of course, you can just
use the Pi to program Java ME but I am comfortable with Windows and it
is a much faster and more convenient environment for me.

[toc] | [prev] | [next] | [standalone]

#30172

Op maandag 20 oktober 2014 16:42:38 UTC+2 schreef Gordon Levi:
> javalau@gmail.com wrote:
> 
> >For those, like me, who have been doing Java for a long time, it is truly amazing that Java lets us effortlessly drop down to the 0/1 bits and hardware level.
> >
> >I had no experience of Raspberry Pi, and just a few hours of exploring and programming allowed me to control a cascade of five 7-segment LED displays.
> >
> >Here's a detailed article of my experience:
> >
> >http://www.artekit.eu/controlling-the-ak-mr-wood-l-from-java-se-on-a-raspberry-pi/
> >
> >The ease with which the above was made possible is, admittedly, in part due to the existence of the Pi4J library for the Rpi.
> >
> >Does anyone know of any other techniques to hit the Raspberry GPIO pins without using Pi4J?
> >
> >   Laurence
> 
> Java ME is available for the Pi <http://tinyurl.com/o8dobkm>. Oracle

Brrr... Java ME. Made sense in the late 90s and early 2000, but nowadays.. ?

I admit to feeling a bit guilty at needing a full-blown Linux + Java SE to drive some LEDs, but I'm afraid that's the way of the world these days: more ann more there's a Don't Care attitude towards efficiency.. as long as it works.

So if I can use SE over ME, any day ! ;-)

[toc] | [prev] | [next] | [standalone]

#30180

On 10/24/2014 8:20 AM, javalaurence@gmail.com wrote:
> Op maandag 20 oktober 2014 16:42:38 UTC+2 schreef Gordon Levi:
>> javalau@gmail.com wrote:
>>
>>> For those, like me, who have been doing Java for a long time, it is truly amazing that Java lets us effortlessly drop down to the 0/1 bits and hardware level.
>>>
>>> I had no experience of Raspberry Pi, and just a few hours of exploring and programming allowed me to control a cascade of five 7-segment LED displays.
>>>
>>> Here's a detailed article of my experience:
>>>
>>> http://www.artekit.eu/controlling-the-ak-mr-wood-l-from-java-se-on-a-raspberry-pi/
>>>
>>> The ease with which the above was made possible is, admittedly, in part due to the existence of the Pi4J library for the Rpi.
>>>
>>> Does anyone know of any other techniques to hit the Raspberry GPIO pins without using Pi4J?
>>
>> Java ME is available for the Pi <http://tinyurl.com/o8dobkm>. Oracle
>
> Brrr... Java ME. Made sense in the late 90s and early 2000, but nowadays.. ?
>
> I admit to feeling a bit guilty at needing a full-blown Linux + Java SE to drive some LEDs, but I'm afraid that's the way of the world these days: more ann more there's a Don't Care attitude towards efficiency.. as long as it works.
>
> So if I can use SE over ME, any day ! ;-)

I believe Java SE Embedded work on RaspBerry Pi.

http://www.oracle.com/technetwork/articles/java/raspberrypi-1704896.html

Arne

[toc] | [prev] | [next] | [standalone]

#30136

In article 6c324a98-b16e-4904-b014-c53fd799cb1b@googlegroups.com,
javalaurence said...

> For those, like me, who have been doing Java for a long time, it is
> truly amazing that Java lets us effortlessly drop down to the 0/1 bits
> and hardware level.

BWAHAHAHAHAHAHAHA!

"Effortlessly" ... *chortle*

Ahahahahahaha!

Thanks for the howler, buddy, I needed a good belly-laugh today. :)

[toc] | [prev] | [next] | [standalone]

#30140

Op maandag 20 oktober 2014 19:17:09 UTC+2 schreef ĵess stone:
> In article 6c324a98-b16e-4904-b014-c53fd799cb1b@googlegroups.com,
> 
> javalaurence said...
> 
> 
> 
> > For those, like me, who have been doing Java for a long time, it is
> 
> > truly amazing that Java lets us effortlessly drop down to the 0/1 bits
> 
> > and hardware level.
> 
> 
> 
> BWAHAHAHAHAHAHAHA!
> 
> 
> 
> "Effortlessly" ... *chortle*
> 
> 
> 
> Ahahahahahaha!
> 
> 
> 
> Thanks for the howler, buddy, I needed a good belly-laugh today. :)

Well, really, that's why I used the word "effortlessly"... driving the hardware is just a question of a bunch of high() and low() calls on the Pi4J pin object... what's so challenging about that?

Anyway, glad to have made your day. Love and Peace to all mankind.

[toc] | [prev] | [next] | [standalone]

#30141

In article ccc4a51a-31ee-4099-9c63-0cc2a76c6dbc@googlegroups.com,
javalaurence said...

> Op maandag 20 oktober 2014 19:17:09 UTC+2 schreef ĵess stone:
>> > truly amazing that Java lets us effortlessly drop down to the 0/1
>> > bits
>> 
>> Thanks for the howler, buddy, I needed a good belly-laugh today. :)
> 
> Well, really, that's why I used the word "effortlessly"... driving the
> hardware is just a question of a bunch of high() and low() calls on the
> Pi4J pin object... what's so challenging about that?

Well, this *is* the language whose designers had the absolutely 
*brilliant* idea of making the only byte-sized data type signed. And 
prone to being auto-promoted to int.

[toc] | [prev] | [next] | [standalone]

#30143 — Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

On 10/21/2014 5:22 AM, ĵess stone wrote:
>
> Well, this *is* the language whose designers had the absolutely
> *brilliant* idea of making the only byte-sized data type signed. And
> prone to being auto-promoted to int.

     I'll agree that making `byte' signed was a regrettable choice,
but what do you find repugnant about promoting it to `int'?  (And
do you have a similar objection to promoting `short'?)

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30152 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

In article m25kdv$tou$1@dont-email.me, Eric Sosman said...

> On 10/21/2014 5:22 AM, ĵess stone wrote:
>>
>> Well, this *is* the language whose designers had the absolutely
>> *brilliant* idea of making the only byte-sized data type signed. And
>> prone to being auto-promoted to int.
> 
>      I'll agree that making `byte' signed was a regrettable choice,
> but what do you find repugnant about promoting it to `int'?  (And do you
> have a similar objection to promoting `short'?)

The problem is mainly the interaction with that and the signedness of 
bytes. So you end up with binary 11001001 turning into 
10000000000000000000000001001001 and when you later truncate or mask off 
the high bytes you wind up with 01001001, which is wrong. So you have to 
watch that you don't lose the high bit when something causes auto-
promotion. And it's tricky, because it can happen even if you have a 
computation "entirely in bytes", i.e. nothing but bytes in and assignment 
to a parameter or local of byte size. Java may still turn some of the 
intermediate calculations silently into ints, when it seems that work 
with bytes into bytes ought to not do that.

Ultimately, this stems from treating bytes mainly as really small 
integers, assuming you'll mainly use them to do arithmetic with wider 
types and will want wide output, when in reality bytes are mainly used 
for fiddling with binary data at a low level.

Preferable would have been a byte type that required explicit casts to 
widen, and which of course was unsigned. In theory it could still be 
added, by adding a "ubyte" type or similar (breaking source compatibility 
with older Javas by adding a new reserved word, though) with unsigned 
semantics and no auto-promotion to wider types -- only explicit casts or 
direct assignment to a wider type would widen it. For easy interoperation 
with legacy code it should be assignable to the existing byte type 
without the binary being changed (meaning that, numerically, 255 would 
turn into -1 when such an assignment was performed).

[toc] | [prev] | [next] | [standalone]

#30153 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

ĵess stone <j3ss.st0n3@gmail.com> wrote:
> The problem is mainly the interaction with that and the signedness of 
> bytes. So you end up with binary 11001001 turning into 
> 10000000000000000000000001001001 [...]

That's not how sign-propagation works.

The 'int' version of the given byte-value is:
 11111111_11111111_11111111_11001001 
so, masking will safely bring back the original
byte value.

The problem with propagation is mostly a cosmetic 
one, namely that you casually need some extra casts:

byte a = 1, b = 2, c; c = (byte)(a + b);

[toc] | [prev] | [next] | [standalone]

#30154 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

In article slrnm4ep45.fp3.avl@login.logic.tuwien.ac.at, Andreas Leitgeb
said...

> ĵess stone <j3ss.st0n3@gmail.com> wrote:
>> The problem is mainly the interaction with that and the signedness of
>> bytes. So you end up with binary 11001001 turning into
>> 10000000000000000000000001001001 [...]
> 
> [calls me a liar]

No! None of the nasty things that you have said or implied about me are 
at all true.

> The problem with propagation is mostly a cosmetic one, namely that you
> casually need some extra casts:
> 
> byte a = 1, b = 2, c; c = (byte)(a + b);

That doesn't help either.

[toc] | [prev] | [next] | [standalone]

#30155 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

On 10/22/2014 2:42 AM, ĵess stone wrote:
> In article m25kdv$tou$1@dont-email.me, Eric Sosman said...
>
>> On 10/21/2014 5:22 AM, ĵess stone wrote:
>>>
>>> Well, this *is* the language whose designers had the absolutely
>>> *brilliant* idea of making the only byte-sized data type signed. And
>>> prone to being auto-promoted to int.
>>
>>       I'll agree that making `byte' signed was a regrettable choice,
>> but what do you find repugnant about promoting it to `int'?  (And do you
>> have a similar objection to promoting `short'?)
>
> The problem is mainly the interaction with that and the signedness of
> bytes. So you end up with binary 11001001 turning into
> 10000000000000000000000001001001

     Um, er, no.

> and when you later truncate or mask off
> the high bytes you wind up with 01001001, which is wrong.

     If promotion produced the result you predict, masking would indeed
produce the wrong answer you show.  But promotion doesn't behave as
you say, and the masked value is in fact the original 11001001.

> So you have to
> watch that you don't lose the high bit when something causes auto-
> promotion. And it's tricky, because it can happen even if you have a
> computation "entirely in bytes", i.e. nothing but bytes in and assignment
> to a parameter or local of byte size.

     Assignment does not promote, so the trickiness level is zero.

> [...] Ultimately, this stems from treating bytes mainly as really small
> integers, assuming you'll mainly use them to do arithmetic with wider
> types and will want wide output, when in reality bytes are mainly used
> for fiddling with binary data at a low level.

     Ultimately, the need for promotion arises from the inability of
most computers nowadays to do arithmetic on narrow integers.  CPU's
tend to lack 8-bit registers, so loading an 8-bit quantity into a
wider register has to do *something* with the rest of the register's
bits.  The principal choices at the hardware level are to leave the
remaining bits alone, to sign-extend, or to zero-extend (I've seen
all three, at one time or another), but simply vaporizing the other
bits isn't an option.

     Some machines can do a limited amount of special-purpose arithmetic
on memory-resident operands (atomic increment, compare-and-swap, that
sort of thing), but the CPU's full repertoire of arithmetic operations
is usually only available for register-resident values.  If you want to
do arithmetic on a `byte' or a `short' with a 32- or 64-bit register,
you cannot avoid the need for promotion.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30156 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

In article m289av$gdo$1@dont-email.me, Eric Sosman said...

>> The problem is mainly the interaction with that and the signedness of
>> bytes. So you end up with binary 11001001 turning into
>> 10000000000000000000000001001001
> 
> [calls me a liar]

No! None of the nasty things that you have said or implied about me are 
at all true.

>> and when you later truncate or mask off the high bytes you wind up with
>> 01001001, which is wrong.
> 
> [calls me a liar]

No! None of the nasty things that you have said or implied about me are 
at all true.

>> So you have to
>> watch that you don't lose the high bit when something causes auto-
>> promotion. And it's tricky, because it can happen even if you have a
>> computation "entirely in bytes", i.e. nothing but bytes in and
>> assignment to a parameter or local of byte size.
> 
> [calls me a liar]

No! None of the nasty things that you have said or implied about me are 
at all true.

>      Ultimately, the need for promotion arises from the inability of
> most computers nowadays to do arithmetic on narrow integers.

Nope.

> [irrelevant stuff about the hardware implementation deleted]

That has nothing to do with how a HLL's type system works, and you know 
it.

[toc] | [prev] | [next] | [standalone]

#30158 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

On 10/22/2014 10:00 AM, ĵess stone wrote:
> In article m289av$gdo$1@dont-email.me, Eric Sosman said...
>
>>> The problem is mainly the interaction with that and the signedness of
>>> bytes. So you end up with binary 11001001 turning into
>>> 10000000000000000000000001001001
>>
>> [calls me a liar]
>
> No! None of the nasty things that you have said or implied about me are
> at all true.
>
>>> and when you later truncate or mask off the high bytes you wind up with
>>> 01001001, which is wrong.
>>
>> [calls me a liar]
>
> No! None of the nasty things that you have said or implied about me are
> at all true.

     You *could* have tried it for yourself, you know.

	public class Jess {
	    public static void main(String[] unused) {
	        byte stone = (byte) 0xC9;
	        int paper = stone;
	        boolean scissors = (paper == 0x80000049);
	        System.out.println("Jess' prediction is " + scissors);
	    }
	}

This sub-thread got started when you mocked javalaurence's use of
the word "effortlessly" in connection with Java bit-fiddling, suggesting
that you yourself considered it difficult.  Others seem to have little
problem fiddling bits in Java, but in light of what you've posted I can
well believe your experience may differ.

     Also, PLONK! because ignorance is curable but rudeness isn't.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30160 — Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

In article m28fqm$8j2$1@dont-email.me, Eric Sosman said...

> On 10/22/2014 10:00 AM, ĵess stone wrote:
>> No! None of the nasty things that you have said or implied about me are
>> at all true.
> 
>      You [implied insult deleted]

None of the nasty things that you have said or implied about me are at 
all true.

> This sub-thread got started when you mocked javalaurence's use of the
> word "effortlessly" in connection with Java bit-fiddling, suggesting
> that you yourself considered it difficult.

So do many people, to judge by the rants on Bug 4504839 over at 
bugs.java.com (which, amusingly, has the utterly bogus state of "fixed"!) 
and its duplicates/etc. And then there's this:

https://webcache.googleusercontent.com/search?
q=cache:1W8Wc3-7t0kJ:in.relation.to/Bloggers/
HandholdingSucksJavaNeedsUnsignedTypes

(Google cache URL because as of this writing the in.relation.to site 
seems to be ignoring inbound HTTP requests for some reason.)

> Others seem to have little problem fiddling bits in Java,

See above.

>      Also, [insults deleted]

No! None of the nasty things that you have said or implied about me are 
at all true.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web