Two techie questions for Pandaboard (ES) owners

I couldn’t think of anything more useful than a git repository for source code. The idea of having a PDF with the printed source code is hilarious.

Really, complying with the GPL is not difficult. It just gets difficult if you start to invent preposterous ways of complying.

Steffen: I agree. Surely this is a fairly simple case of set up a github repository, and include in the SD card build a link to the github repository version which was checked out for the source?

I was just trying to think of a way of complying without using any ROOL bandwidth, without encouraging novices to tinker with the firmware (to make support easier). Printed listings is a perfectly conventional way of circulating software and a PDF is ‘machine-readable’. Just not very conveniently.

Personally I find github (whose chose the name ‘git’ anyway) impenetratable – the idea that all you need is the file datestamp of the binary and you can check out the right version of the source is laughable. Having the source in a single file makes searching for the bit you are interested in much easier.

without encouraging novices to tinker with the firmware (to make support easier).

Surely we want the novices to tinker? How else will they become experts? ROOL can easily direct them towards the forums for any help they require, as it’s quite clear that we all spend more time here discussing things than we probably should.

Also I’d be concerned about the experts, who don’t want to spend hours working out how to extract the text from a PDF so that they can work on the code.

Printed listings is a perfectly conventional way of circulating software

In 1970, yes. But not so much any more. People soon realised that using electronic forms of distribution (tape, floppy, CD-ROM, internet) was much more convenient, faster and reliable than sitting at a keyboard for hours typing in listings by hand.

Personally I find github impenetrable

I’ll agree with you there; either I’ve missed something, or github’s web interface doesn’t make it very easy to track which changes came from where. But as a source control system, git is very good in many aspects – there’s a reason why it’s become so popular.

(whose chose the name ‘git’ anyway)

I like it.

the idea that all you need is the file datestamp of the binary and you can check out the right version of the source is laughable.

The sensible way of doing things is to use either the commit hash or a release tag to find the right source code. Using the datestamp is a last-ditch resort for when you aren’t given any other information.

Having the source in a single file makes searching for the bit you are interested in much easier.

Depends on how well you use your development tools. Other platforms have comprehensive IDEs that allow you to easily search through lots of source. On RISC OS we don’t really have that, but there are various file search utilities available. E.g. the RISC OS port of grep that’s in ROOL’s CVS allows the results to be displayed in a throwback window, making it much closer to the experience you’d get with using an IDE.

Printed listings is a perfectly conventional way of circulating software and a PDF is ‘machine-readable’.

While in a strict sense a PDF is “machine readable” (it isn’t a human that reads PDFs), I think you’ll have to look really really far to find any sort of compiler that would contemplate using PDF as input. While it is not spelled out, I believe that the clear assumption, when referring to source code is that “machine readable” means something that can be fed to a compiler to turn the source provided into the executable provided.
Really, it is ideas such as “supply it as a PDF” that would bring about a GPLv4…and v3 was bad enough.

Surely we want the novices to tinker? How else will they become experts?

Indeed. I don’t get the “makes support easier” reason, given that this is not a commercial project, nobody here is under any obligation to provide technical support, and the sorts of people who would want to build the bootloader are probably the sort of people least likely to require support (for our licence requirement is for the source code – getting a working toolchain and extracting a runnable binary from it is their concern).

Having the source in a single file makes searching for the bit you are interested in much easier.

Not particularly so, because finding stuff in multiple files was a problem that was solved years ago. Using a single file does make most other aspects of software development and maintenance a lot more difficult, however.

Depends on how well you use your development tools. Other platforms have comprehensive IDEs that allow you to easily search through lots of source. On RISC OS we don’t really have that, but there are various file search utilities available.

I have to take slight issue with that. Most projects on RISC OS are small enough to allow loading all source files into StrongED. You can then use the search facility to easily search through all files.

If you don’t want to load all the source files then StrongED has an add-on that can be used to search all files in the same (source) directory. This currently uses a Lua script but it probably wouldn’t be too hard to create an add-on using grep.

With all source files loaded you jump straight to a function or label definition (in most modes) cutting down the amount of searching.

I agree it’s not a full IDE but things aren’t quite as bad as you make them out to be. :-)

Back on the topic of green speckles, today I was able to get a desktop environment working with Arch Linux (with their U-Boot). Running at 720p in what appears to be a 64K colour mode I get the ‘normal’ amount of speckling that other people report. So for me it looks like the speckling is a general issue which affects all OS’s.

When I get another chance to look at this I’ll try fiddling with Arch Linux some more to see if I can test some different screen modes, and the HDMI output (although I didn’t notice anything obviously wrong when I briefly had Ubuntu running). Plus if I can get some other modes working I’ll be able to try it on a different monitor.

b) Can you see green speckles on your monitor at 1920×1200? I suggest using this standard image for the test, and also stating what refresh rate display manager says, and how you connect to your monitor (VGA adapter, HDMI adapter, DVI cable, whatever).

Displaymanager says 60Hz. No perceptible distortion (apart from a tiny blue/green line between mauve and blue). HDMI to DVID cable, Monitor Asus PA248Q.

The tiny blue/green vertical line is interesting. Blowing up the image to 300%, which is as far as you can blow it up before the phenonomen disappears (because !Paint interposes black lines between pixels), the line occurs at two places on the test image: the transition between BF00F5 and C000F6 and the transition between 7F00F5 and 8000F6. Note that it is only at the transition that the effect occurs. There are many places where pixels BF00F5, C000F6, 7F00F5 and 8000F6 are rendered correctly, only where the left to right transition occurs is the effect present. It is also not the HDMI cable as I can send 1920×1200 down the same cable to the same monitor from another computer with no problems.

It is therefore not a simple colour decoding ‘mistake’.

However the effects disappear if I select 1920×1200 at 40Hz rather than 1920×1200 at 60Hz. Hence problem solved.

You can get rid of the black lines by clicking MENU over the image, then deselecting “Grid”.

Doing so reveals the phenomenon still exists at much higher magnifications, though these faint green lines never get any thicker.

If I switch the monitor to my RiscPC, the green lines do not appear.

Does anyone have an MDF for 1920×1080 at 40Hz?

One thing I came across was RComp mentioned he had a “golden” pandaboard. One that displayed perfectly at 45Hz+, other pandaboards from the same batch didn’t display properly at 45Hz+.
Can’t remember the exact details, it was a post on riscoscode, or one of the sites.
Anyway so that would tend to indicate it’s definately a hardware issue.
I think PandaLand comes with a 40Hz MDF that is OK.
If you have PandaLand support, RComp will probably supply a 40Hz version for you.
Much easier than hand crafting one!

Does anyone have an MDF for 1920×1080 at 40Hz?

Join the PandaLand scheme from R-Comp and there are MDFs for 1920×1080 at 24, 25, 26, 30, 35, 38, 40, 42 and 60Hz. This is a commercial product.

One thing I came across was RComp mentioned he had a “golden” pandaboard. One that displayed perfectly at 45Hz+, other pandaboards from the same batch didn’t display properly at 45Hz+. Can’t remember the exact details, it was a post on riscoscode, or one of the sites.

Definitely ‘one of the sites’.

I’ve just encountered something that may be relevant that surprised me.

Having bought a new TV I got an HDMI lead to connect a recorder to it. Despite the handbooks saying that using the recorder would prompt the TV to switch to its input, that didn’t happen.

So I decided the lead might not be ‘fully populated’. As a test I swapped it with the HDMI lead between my ARMiniX and its monitor.

The recorder now prompts the TV Ok.

And a screen image that used to give a ‘green tinge’ on some screen modes on my ARMiniX now looks fine!

So much as I am skeptical of the florid claims made for expensive cables, I suggest people sometimes check if changing one cable for a different type has any effect. Some HDMI cables may be poorly made and ‘encourage’ some types of flaws.

Jim

When I get another chance to look at this I’ll try fiddling with Arch Linux some more to see if I can test some different screen modes, and the HDMI output (although I didn’t notice anything obviously wrong when I briefly had Ubuntu running). Plus if I can get some other modes working I’ll be able to try it on a different monitor.

I’ve recently had another play with Arch Linux, trying out several different screen modes to look for any sign of speckles. Interestingly Arch Linux seemed to suffer from more speckling than RISC OS, even when using the same mode timings. I’m not quite sure why there’d be such a difference between the two OS’s – perhaps due to differing colour depths (Linux was using 64K colour, RISC OS was using 32K & 16M), or perhaps due to differences in the video PLL setup. I might have another go at some point and see if I can get a dump of the hardware registers so I can say for certain that both OS’s are using the same settings. Plus I still need to try using a different monitor to see if that affects things.

After a bit of fiddling I was also able to get the HDMI output working under Arch Linux, but haven’t been able to work out how to change the resolution (it was stuck at 640×480). So I can’t really say whether HDMI suffers from the same green speckling issues or not.

So much as I am skeptical of the florid claims made for expensive cables, I suggest people sometimes check if changing one cable for a different type has any effect. Some HDMI cables may be poorly made and ‘encourage’ some types of flaws.

Judging by everyone’s experiences it wouldn’t surprise me if the problem is that the green signal is slightly out-of-spec – e.g. there’s some noise being introduced from somewhere, or the voltage is slightly off, or the waveform is slightly out-of-phase from the pixel clock, etc. So it wouldn’t surprise me if using a different cable or display would make a difference for some people.

Judging by everyone’s experiences it wouldn’t surprise me if the problem is that the green signal is slightly out-of-spec – e.g. there’s some noise being introduced from somewhere, or the voltage is slightly off, or the waveform is slightly out-of-phase from the pixel clock, etc.

The possibilities that occurred to me were:

1) The characteristic impedance of the cable doesn’t match the destination (monitor). That can alter and delay the waveform edges so may cause time misalignments between the bits sent ’in parallel. So some values come out wrong.

2) Cross-talk between the parallel transmission pairs so a value on one line can affect the value on another.

IIUC the ‘send’ end of HDMI doesn’t attempt to match the cable. It just shorts or lets the line float free. If you’re as ancient as me you’ll think of TTL or ECL and the way their source impedance differs for a ‘1’ than for a ‘0 being a PITA. The ’send’ mismatch doesn’t matter unless the destination isn’t matched to the cable. If that’s not matched, things get interesting…

But what I found was a really weird effect despite the above, so I’m not at all sure of the real cause. I may sometime get some HDMI cables and test them as RF transmission lines to see just how awful they are. 8-] But as you say, the output of the Pandaboard may be odd in a specific way.

Jim

But what I found was a really weird effect despite the above, so I’m not at all sure of the real cause. I may sometime get some HDMI cables and test them as RF transmission lines to see just how awful they are. 8-]

Never looked at the cable specification, does it involve twisted pairs? If so what variance of twist per unit length?
Needless to say, with various sharp practice around, what is marked on the cable may not be what is actually done.

I took an HDMI cable apart once. I was full of hope when I found the cables split into bundles, each with individual shielding, and colour-coding that matched diagrams I found online. However, when I figured the pinout using a multimeter, I found that nothing made any sense. I’ve concluded that the manufacturer used some decent quality cable, but wired it up totally arbitrarily! Totally makes a mockery of the shielding and twisted pairs of course. Fortunately it was a very short cable…

See “A salutary lesson” in comp.sys.acorn.networking today, by coincidence.

See “A salutary lesson” in comp.sys.acorn.networking today, by coincidence.

Ah, the joy of duff cables. For some reason our desktop crew don’t all¹ subscribe to my standard procedure of testing with a known good cable, first at the user location and then direct into the switch (users and cabling companies adding new cables damage the infrastructure wiring)

¹ The wiser ones, some quite young, go with my procedures and have an easier life, they also “fix” faults with patch cables in a very permanent way – slice with side cutters and drop in bin. My view is patch cables are cheaper than the time it takes to walk across the car park to go fix a patch cable fault twice

Ah, the joy of duff cables.

In my case it depends on the definition of “duff”. So-called RJ45 connectors are used for more than just Ethernet. One example we have used here is a multi-channel serial-over-Ethernet server where all the serial connections have RJ45 connectors. The cable I had may have been for one of those, where you would prefer not to have twisted pairs. The cable did not pretend to be Cat5.

So it wasn’t duff in the sense of faulty (open or short), but it wasn’t an Ethernet cable.

So-called RJ45 connectors are used for more than just Ethernet. One example we have used here is a multi-channel serial-over-Ethernet server where all the serial connections have RJ45 connectors.

For convenience around work we use the same grade. That said CAT5e is the lowest we have gone for years and the infrastructure stuff is CAT6, installed as such 10 years ago, quite handy now we’re shifting to Gb/s ingress

The cable I had may have been for one of those, where you would prefer not to have twisted pairs.

We, many moons ago, ran serial over line extenders (Gandalf mini-modem beasties) and had problems on some runs which were puzzling, with intermittent but regular failures on several listing printers. Convinced that it was some sort of noise problem I even spent a whole morning monitoring the signals with a differential scope. I was just about to pack up when someone rang for the people who had moved out of the office while I ran the tests…

The phone cables ran parallel to the serial data.

So I grounded all spare cores to the DP (telephone style wiring) and grounded the DP back to the PBX frame. Since the pairs were twisted the noise reduction from grounding those twisted in wires was just the job.
Without the twist I’d have known the problem but a solution would have been more costly than the wire strippers and screwdriver version I did.

So it wasn’t duff in the sense of faulty (open or short), but it wasn’t an Ethernet cable.

Faults are more than just o/c and s/c, but having diagnosed a fault in a cable keeping it around in a potentially usable state is just kicking ones own nether region. Patch cables are way too cheap relative to labour cost to think otherwise.

Never looked at the cable specification, does it involve twisted pairs?

For the av data it uses pairs of wires in a common shield. I haven’t seen a spec requiring the two ‘inners’ have to be twisted so I assume it relies on the shield. But twisting would make sense as well albeit with one proviso I’ll mention later.

The receiver has each ‘inner’ tied to a +V rail via a resistor (100 Ohms IIRC).

To send a signal the transmitter pulls down one wire or the other. i.e. to send a ‘1’ it pulls down one wire, to send a ‘0’ it pulls down the other. Does this by sinking a chosen current from that wire. The other wire it leaves ‘unconnected’ – i.e. open switch at the transmitter, allowing the line to ‘float up to +V’.

The receiver then senses the difference between the two wires with one polarity of difference being recognised as a ‘1’ and the opposing polarity as a ‘0’.

So in theory, a differential shielded transmission which should reject interference, etc, fairly well.

The main snags:

The source impedance presented at the transmitter end doesn’t have to match the cable impedance or the receiver (load) impedance. Indeed, when a wire is ‘open to float’ the source looks like an infinite impedance. So unless the cable and receiver impedances match nicely you’ll get weird effects as the energy bangs back and forth followind a transition.

Note that in theory the current inside the shield should always be the same. It should just flip from being on one inner to the other. So in theory, no fluctuation in H-field to ‘leak out’. But that nice idea goes bang if the system isn’t carefully matched as a switch to open transmit with behave differently to a switch to current pull.

Then the real snag with the above is that there are three such pair-in-shield connections in the cable, all squashed against each other. Hence if the outer shield isn’t perfect, you’ll get fields leaked from one pair to another. i.e. crosstalk. Anyone want to bet that doesn’t happen? 8-]…

Its the kind of system that can work nicely in a lab with carefully made kit and cables. But then you think of the cowboys who knock out pound-each HDMI cables with pretty labels…

Amazing it works at all TBH. :-)

The spec also keep evolving so the details change. Hence comments about new versions of the cables, etc, being needed as the industry wants to shove more though HDMI.

Jim

OK, twisting wrt the above.

In theory twising paired differential inners within a shield can further improve reduction in crosstalk/interference.

But if you have two cables squashed together with the same pitch of twist it may not help much. May also slow down the signals and make things worse. problem is that most of the ways people think of cables assumes they sit in free space. These ones don’t. And at lower frequencies the effectiveness of a sheild depends on things like how thick it is. If some other metal is close it can couple across.

Jim