Jan 13

D-Bus tutorial

So at work, we use D-Bus to allow our programs to talk to each other. However, when first learning how to use D-Bus, all of the information that we were able to find on the internet was either laughably out of date or otherwise useless. So I’ve taken it upon myself to create a good tutorial that shows you exactly how to use the D-Bus. Hopefully, you can find it helpful.

Note that it’s not done quite yet. I’m going to add more information on signals, plus sample code once I’m done. I should have time to finish it this weekend.

On a related note, the tutorial is the first page that uses my new page-generator. It’s basically the same as a new post, but it’s more static to the extent that it will stay on the left hand side under ‘navigate’. With this in place, we are coming up on a fully-featured CMS system. Of course, this is nowhere near ready to release, but the basic framework is mostly in place at this point.

Jan 08

Adventures in PIC programming

Recently, I got a PICKit2 programmer from Microchip, for a project. I haven’t started, I’ve just been learning my way around the chip, using the included lessons. They’re somwhat lacking though, so from time to time I’ll post some (possibly useful) information on here.

Just so we’re on the same page, I’m using the second type of PICKit2 that Microchip sells, the DV164120.

Now, on to the possibly useful part. The first lesson is to turn on a single light, and the 4th lesson is to make those lights rotate around and chase each other. It took me a while to figure out exactly what was going on, so let’s go dive into lesson 1.

Start:
bsf STATUS,RP0 ; select Register Page 1
bcf TRISC,0 ; make IO Pin C0 an output

bcf STATUS,RP0 ; back to Register Page 0
bsf PORTC,0 ; turn on LED C0 (DS1)

goto $ ; wait here
end

This is relatively simple, so let’s try and set two LEDs on at a time. First, let’s make all of PORTC to be output. That code is given in Lesson 3. Plus, let’s set the second bit on PORTC to set the second light on.

Start:
bsf STATUS,RP0 ; select Register Page 1
clrf TRISC ;from lesson 3, set all of TRISC to output

bcf STATUS,RP0 ; back to Register Page 0
bsf PORTC,0 ; turn on LED C0 (DS1)
bsf PORTC,1

goto $ ; wait here
end

However, this doesn’t work! You’ll notice that only LED C1 turns on. Huh. That’s interesting, because we definitely set two bits, bits 0 and 1 to turn on DS1 and DS0.

Well, so what would happen if we were to, say give the bsf command a hex value that had both bits 0 and 1 set, like 0x03? Well, as it turns out, that will actually turn on DS4. What?!

The key here is that bsf is setting the [i]bit[/i] value. Basically, you give it a variable and you set the actual bit in that region. However, you can also load in a value to that region, which is what the rotate lesson does. Now, let’s look at the datasheet for the PIC, and look at the PORTC:

Notice how this is only 7 bits. These bits control which outputs are on at a time. We’re only concerned with the first 4 bits, because we only have 4 lights plugged into the PIC. Now let’s look at the relevant code for the rotate that sets what light to put on:

 bcf STATUS,C ; ensure the carry bit is clear
rrf Display,f
btfsc STATUS,C ; Did the bit rotate into the carry?
bsf Display,3 ; yes, put it into bit 3.

Basically, what this does is it clears the carry bit, which is in the STATUS register. Now, we rotate the Display variable to the right, after moving it into f. Let’s step through this from the starting point, where Display has the value of 0x8(note that the Microchip code has this as 0x08, however only one byte is relevant and needed, since PORTC is only 8 bits(1 byte) wide). The next part shows only the last 4 bits of the byte, as those are the only relevant bits for this example.

1000 ;display at beginning
0100 ;rotate display to right, in C this would be Display >> 1
;is there anything in the carry bit? no, don't put anything in bit 3
0100 ;display next loop
0010 ;display after rotate
;is there anything in the carry bit? no, don't put anything in bit 3
0010 ;display next loop
0001 ;display after rotate
;is there anything in the carry bit? no, don't put anything in bit 3
0001 ;display next loop
0000 ;display after rotate
;is there anything in the carry bit? yes, set bit 3
1000 ;display at end. repeat

Now back to our original question, which was how to set multiple lights to be on? Well, we need to do basically the same thing that we did for the rotate. We make a variable, and then we load the [i]variable[/i] with the hex value of what two lights we want on.

cblock 0x20
Display
endc

org 0
Start:
bsf STATUS,RP0 ; select Register Page 1
clrf TRISC ;set all IO pins C to output

bcf STATUS,RP0 ; back to Register Page 0
movlw 0xA ;1010 binary. Lights DS2 and DS4
movwf Display
movf Display,w
movwf PORTC
goto $ ; wait here
end

Simple once you understand it.

Dec 16

Thoughts on Net Neutrality

So for the past few years, we’ve been hearing about this thing called “Net Neutrality”. Basically what that is, is that all content on the internet is delivered the same. There is no preference over what sites get better speed and/or service to the users of the internet.

Recently however, some companies have looked to tiered internet(where you pay more for faster speeds) and/or a download limit. We’ve already seen Time Warner institute a policy on this, albeit on a very limited scale.

My real thought on the matter though, is why? Why do the ISPs want to charge more for a higher download limit? While I do agree that most people may not download a lot in a month, there’s really no good reason to have a download cap like this.

Basically, what Time Warner is saying is that it costs more to send 10GB of information than it does to send 40GB of information. This isn’t true(or, at least as far as I know). While cable internet access is shared among all of the people on the network, that only matters if everybody is downloading a lot of information at one time. Anyway, my point is that there isn’t a noticeable cost difference between downloading 10GB and downloading 40GB.(if there is, link me to something that shows that!) Because of the nature of the network, the more you use it, it does not get correspondingly more corroded. For example, charging based on water usage makes sense. There is a finite amount of water for people, and for each gallon processed you need to clean the water, pump it, etc. As well, the more water you push through the system the more strain is put on the system over a period of many years.

“But wait!” you say. “Since cable is a shared medium among subscribers, isn’t that just the same as the water line, which is shared among customers?” Well, yes. Paying for faster speeds makes sense, as basically all that is doing is making the pipe which comes to your house larger. However, unlike the water system, where how much it costs is directly related to how much you use, this is not the same with the internet. Network hardware does not have a certain lifespan, to the extent that it can only take X number of packets before it needs to be replaced. How long before a part of the water system needs to be replaced is almost always directly related to how old it is. While it is true that network hardware does need to be replaced eventually(as it will eventually break), the amount of data does not determine this. If we try to force 10,000 gallons of water though a 1-inch pipe in one minute, that pipe will have to be replaced very soon, as the pressure is very high. If we try to force 10,000 packets through a piece of network hardware that can only take 8,000 packets a second, the 2,000 remaining packets simply disappear. There is no forcing of the packets through the hardware.

Note: Don’t quote this information as factual. Anything stated here is to the best of my knowledge. I’m not really a network guy.

So, to conclude: Internet based on how fast you can download makes sense. Internet based on how much you download doesn’t.