Redhatter (VK4MSL)

Embedded development

Lately I’ve been looking around at microcontrollers.

With my work with Eze Corp, I’ve gotten quite accustomed to the MSP430. It’s a nice little MCU, with a very low power drain, gcc port and is in general, quite easy to drive. At my workplace, I use a Windows XP machine to do development under MSYS, using a MSP FET-430UIF JTAG device for programming and debugging. This is not my preferred mode of development, I’d much rather be doing it on a Linux host (or at least something that properly understands POSIX)… but it’s tolerable.

For my home projects though… this isn’t an option. I do not own a Windows computer any more, and in any case, I dislike working with it at my workplace — to hell with using it in my recreation! (The reasons why are best saved for another rant at some other time. No, I’m not a free-software hippie, I have other reasons.)

There are a number of MCUs available that I’m aware of. The biggest hurdle with many of them is the requirement of some piece of hardware which is either proprietary, expensive and/or unavailable. I like the MCUs that provide a JTAG interface, since it’s a well defined protocol that allows real-time debugging of the device as well as programming. JTAG for what its worth is little more than an SPI bus at the hardware level, it’s what’s layered on top of this that differs between devices.

JTAG can be implemented via GPIO. Since a computer parallel port is merely a specialised form of GPIO port, this enables people to wire up a JTAG port to a parallel port, and bit-bang the signals. There’s a couple of issues with this approach:

  • Parallel ports (I mean real ones) are getting harder to come by, especially on portable computers (understandable on netbooks, but I don’t see why full-size laptops don’t have them…anyway)
  • Most USB Parallel cables only have the smarts to drive a printer, they don’t allow arbitrary bit-banging of data. (e.g. the PL2305. And try explaining the difference to a salesperson…)
  • USB introduces a 1~2msec latency… which stuffs up timing at high speed.

I’ve seen some programmers (for PIC and AVR chips) that use RS-232. Now these are usually specialised devices for a given range of MCUs… that’s fine… but they suffer the same problem as the parallel-port JTAG cables… that is, most modern computers don’t have RS-232 anymore for some silly reason (as I say, understandable on netbooks… but are they saying they can’t cram a mini-din8 somewhere on a 15″ laptop?!)… and the USB latency screws timing up (I suspect this is the issue with the PL2303-based adapters we have here).

That leaves me with native USB devices.

A lot of the ones used by ARM devs are based on a FTDI chip which offers UART (RS-232) and SPI… so you get a serial console and a JTAG in one unit. Nice… In addition, there’s a open framework for debugging with them, OpenOCD. I don’t have the knowledge necessary to port this across to other MCUs… I guess one hope is that a MSP430 guru might contribute an OpenOCD port, but in the short term this isn’t an option.

For many ARM devices, there’s the J-link developed by Segger.  I’ve mentioned this one in past posts.  For MSP430, TI provide their MSP FET430UIF.  Both of these devices are on the nose from a usability point of view.  Both require you to use proprietary software in order to access their device.  This is fine if you’re on a supported platform, and the tool is well maintained.

For the J-link… well, if you’re not on Windows… forget it, that’s all they support.  The advice from them is to just run a Windows computer purely to run their GDB proxy software (which costs too I might add).

TI’s tool is theoretically a little better for support… the userspace drivers are proprietary freeware… but again, if you’re not using Windows or Linux on an i386 PC, forget it.  More to the point, the Linux version doesn’t seem to get updated as often — so the only real option is Windows.  Bad luck for me and my Yeeloong.

For what it’s worth, I do not understand why these things need to be proprietary… it’s a flipping programming cable.  Just moves data from one end to the other.  If they need to load firmware into the RAM of the chip being programmed, fine… but why can’t this be an ELF binary or something that just gets picked up by OpenOCD (or equivalent) and stuffed down the wire?

Devices like the Rabbit Semiconductor series of microcontrollers drive me insane with their non-standard nonsense… they decided to chuck many years of C history down the gurgler and invent their own “wannabe C”. #include <foo.h>? Nah… don’t be silly, we’ll just stuff everything into .lib files and #use them. Urgh!

I’d love to know what low-end microcontrollers exist that don’t exhibit the proprietary nonsense that is outlined above. 8 or 16 bits wide… I like ARM, but I’m not needing something that flashy. I like the low current drain of MSP430, and the fact they use gcc… which I guess pushes me in the direction of AVR and maybe PIC, but I’d be interested in other options. Cheap is important too, I don’t have a lot of cash for expensive tools or chips.

The other thing in the favour of AVR/PIC MCUs, is that there’s a local shop that I can buy them from — no need to order on-line. Farnell and RS have a wide variety, but I have to purchase from their website, which is awkward for me.

The applications I’d have in mind? Well, one idea is a more modern version of my headlamp… some of these MCUs draw less power than the 74HC14 chip used in that project (a few mA in standby mode) and would offer more functionality. Other applications include small controllers for amateur radio projects (not SDR though).

I’m really interested to know what controllers are out there, which are open-source friendly. Once I have a clear picture of what’s on offer, I can look more closely at my applications.

2009/04/18 by Amateur Radio Public Syndication Rants Thinktank 2

Recovering a braindead DSL-504 router

This is mainly for my own reference… but may be useful to others, so I’ll publish it here.  We have two routers, one which we keep as a spare, is a D-Link DSL-504 (not a 504T… and not a Generation II) 4-port ethernet switch and router.

Recently, I noticed the unit was not firing up — the status LED remained off, and I could not remember what the IP address was for the life of me (I had changed it from its default, and had disabled the DHCP server).  As it turned out… it didn’t have one, the flash memory had become corrupt, and so it was not booting.

These routers have a RS-232 serial port on the back for a console, to which you plug in a plain 9-pin serial extension lead (not a null-modem) and hook up your favourite serial terminal program.  The unit spits out its messages at 9600 baud 8n1.  In the above scenario, you will notice the bootloader (PP boot) complain that there is “no ATMOS image present” or some such message, and it’ll drop you to a prompt.

Firstly, you’ll need the flash image to load back in.  You get that from the D-Link Australia website, just go to their support section and look up DSL-504.  You’ll find the firmware under the downloads, it comes in a 3MB ZIP file, when you decompress this, there’ll be a .bin file inside — this is your image.

There are two ways to stuff this image back into the device.  The most obvious is the way D-Link tell you to… that is… enter xmodem at the prompt, then upload it using the Xmodem protocol.  Slow… it takes about 30mins.  There is a faster way.

These routers are capable of booting off a network in much the same manner as a SGI workstation… that is… obtaining an IP address via BOOTP, then downloading the above image via TFTP.  The concept is exactly the same.  Set up your boot server as per the Gentoo/MIPS handbook — you won’t need the special kernel parameters… but the host setting will look identical.  Just place the .bin file you obtained earlier in your TFTP root directory, and point the filename parameter at it.  If you don’t know your router’s MAC address, type tftp and it’ll tell you, then reset the router.

Once all the settings are in, and the daemons are started… turn to your terminal emulator, and issue the tftp command. It’ll immediately download the image and boot it, should take a few seconds. It’ll tell you to type quit to boot, do this.

When it prompts for a password, just press ENTER… the password is blank (not “private” as D-Link will have you believe).

Upon booting, type config save to store the settings… Don’t make the mistake I made at this point — I tried mucking with the settings via serial console and had to start over (the webserver kept giving me a blank page). If you need to, isolate it from your network at this point, just plug in a machine with a web browser.

If you decide to muck around, and have to reset it… at the prompt, type flashfs wipe followed by restart, and you’ll be back to step 1.

From here, you should be able to visit the router’s homepage and configure it as if pulled straight out of the box.

2009/04/13 by Public Syndication 1

Lemote Yeeloong: First impressions

Well, after a few minor hiccups with delivery (basically I wasn’t home when the first delivery was made, the second delivery — apparently the driver knocks on the door with a very delicate touch), I have at last gotten hold of one of these devices.

Out of the box, they run Debian Linux/MIPS, with just about every app you could think of that would be useful on a desktop.  They feature nicely integrated power management… and… looking at the defconfig for these devices, there seems to be the hint of suspend-to-disk capability, although I’m not sure how well developed it is.  Lemote have pulled off a lot of voodoo at the kernel level to get this going.  There are not a lot of MIPS systems that have power management to worry about.

Performance, well subjectively, it seems about on par with my old laptop, a Toshiba TE2100 (Pentium 4M 1.7GHz)  for responsiveness.  It runs a 64-bit kernel out-of-the-box, although runs a 32-bit userland (O32).

Ergonomics, for the size of the machine, it is not bad to use.  I think I found my old PDA more painful… this thing once you get used to the positions of keys, is quite usable.  I’m still getting used to the right-hand shift key being small, the backtick being above the 1 key (consequently, those numbers being one position to the left of where I expect), and for a while, I kept hitting S instead of A.  I find myself constantly hitting the up-arrow when typing capital letters, hitting Fn instead of Ctrl, and sometimes bumping the touch pad… but this will of course settle down as I get used to the machine.  Given the space available, Lemote have done well with the design of the machine.

Video capability seems quite good for 2D, there seems to be little evidence of 3D acceleration, but I guess that will come before long.  It did struggle to play a DVD earlier, however this is not conclusive, since there are a number of factors at play needed to play video smoothly.  I shall know more as I experiment.

What about Gentoo?  Well, I’m preparing new stages… I’ve had a few hiccups there, mainly glibc being difficult.  In the short term, I’ll stick with Debian on this box while I find out what makes the device tick (Gentoo will lurk in a chroot), then I may move to a dual-boot or pure Gentoo environment.

Anyway, I’m off to play with my new toy. 🙂

2009/03/24 by Public Syndication Uncategorized 4

Gentoo/MIPS Stages

Hi All,

Well, I’ve just dusted off the second Lemote Fulong here, and I’m booting it up for another round of stagebuilds. (Yes… I haven’t gotten around to locating and implementing the auto stagebuild scripts that everyone else seems to be using.)

I’m also getting a newer piece of MIPS kit… a Lemote Yeeloong is currently sitting at Brisbane Airport in a box with my name on it… hopefully it’ll be in my hands by Wednesday evening. This will enable support of Gentoo/MIPS on this platform, and will also allow me to do some MIPS testing of packages while on my many hours of travelling between Brisbane and Laidley and hours spent at university. It’s based on the Loongson 2F CPU, which implements the MIPS64 ISA (the Loongson 2Es in the Fulongs implements MIPS3), and is little-endian.

Hopefully this will mean the bug count will start to decline once more for the MIPS team. 🙂

2009/03/23 by Gentoo Development Linux Development Public Syndication 5

Ultra-Low Bitrate Speex

I just stumbled across this article, discussing the issues behind digital voice encoding at low bitrates.  The use of AMBE in the D-Star protocol really does get up my nose, at best it’s distasteful, at worst, harmful.

I’ve been doing some experimentation with Speex… so far my experimentations have been with bitrates above 12Kbps.  Above this, it is quite intelligible.  This is helped with pre and post filtering with the following filter:

Filter for ultra-low quality Speex

It’s not ideal… it means things do sound rather flat, but it’s similar to existing filters employed on existing SSB and FM transmission systems. On SSB, around 2.2kHz is the maximum upper frequency… and it tends to drop out around 300Hz, give or take a little bit. That filter could do with some fine tuning, but I find for low-bitrate Speex, using it to filter the audio before encoding, and after decoding, helps to reduce the distortion of the codec. Some fine-tuning could allow for better fidelity.

It is interesting to hear though, that DVSI even cuts corners though in an effort to lift perceived clarity by trying to reproduce the bottom end.

A good low-bitrate encoder benefits everyone… VoIP becomes even cheaper when you can send the same quality audio in fewer bits, and the benefits for HF radio communications would be immeasurable.

I guess though, it comes back to the old saying:

The superior man understands what is right; the inferior man understands what will sell. — Confucius

2009/02/23 by Amateur Radio Public Syndication Thinktank 1

AWNOI

Australia-Wide Night-Owl and Insomnia Net

The AWNOI net is a weekly evening net that starts at 10:00PM UTC+10 (or 9:30PM UTC+10 when daylight savings time is in effect) and continues until the last station falls asleep. This recording is produced by myself using my HF set (Kenwood TS-120S), Yaesu FC-700 tuner and G5RV-like outdoor antenna. My QTH is at The Gap, Brisbane, QLD. Most of the stations participating, bar 3, are VK4 stations (two VK2s and one VK1).

If you’re a licensed amateur with equipment for 80m communications, feel free to join us at any time.

This recording was made 2009-01-30 and is available as Ogg/Speex, Ogg/Vorbis or MPEG4/AAC codecs.
A short highlights recording is also available, in MP3, Ogg/Vorbis or Speex.
Continue reading…

2009/01/31 by Amateur Radio AWNOI Net Public Syndication 0

The puzzle of handheld radio antennas

Well, lately I’ve been tinkering around with antennas again for use whilst mobile.  By mobile, I mean public transport mobile, and pedestrian mobile… I don’t own a car.

Most handheld radios come with rubber ducky antennas.  My Kenwood TH-F7E is no exception.  Rubber ducky “dummy loads” as I call them, are quite dismal performers against an efficient and resonant dipole — however they are usually much more convenient size-wise than a resonant antenna.  It’s a similar story for mobile HF antennas… they’re a negative gain antenna.

Naturally, the way I’ve improved it, is to construct my own.  So far, I’ve built a number of these antennas.  The first version was a bit of stainless steel fencing wire with a SMA connector soldered to the botto and a few turns of a coil.  It was about 50cm long… roughly cut, so possibly not that well tuned… but it performed quite well… allowing me to reach repeaters up to 80km away on 2m with minimal line-of-sight.  The SMA->antenna interface proved to be a fragile component however.

A later version attempted to be a half-wave 2m, and could extend (fold out) to become a full-wave 70cm antenna.  This again, had similar mechanical issues to its predicessor, but performed excellent otherwise.

It was pointed out to me that trying to match a full-wave antenna is asking a bit much of the power-amp in my radio, and that an odd multiple of 1/4 wavelength was better.

Thus, the third revision, I made using some surplus solid core electrical copper cable, and a BNC connector, was constructed at a length of 52cm.  52cm was calculated according to the rule v=f?… the frequencies I had in mind were 146.500MHz (2m FM calling frequency)  and 439MHz (near to the input frequency of most 70cm repeaters).  52cm was calculated approximately as being 1/4 wavelength on 2m, and 3/4 wavelength on 70cm.

This antenna performed exceptionally well, and with the BNC connector, showed less mechanical problems than its predicessors.  It did however, put a lot of strain on the BNC->SMA adaptors I was using, and I had to be extra careful with the antennas length.

Using MMANA-GAL, I tried modelling this antenna, just to see how well it infact should work in theory.  Well I was right… about 6dBi gain on 70cm… it wasn’t bad at all! However, SWR was through the roof, 1:several hundred thousand.

I’ve since found a long forgotten RC car remote that operated on 40MHz, which had a 40cm long antenna.  I’ve stretched the base coil out a bit to make it 42cm and added a SMA connector to the bottom of it… I may have to extend it a bit, but this seems like a closer match to what I’m looking for… but my modelling of it is just as dismal in terms of SWR.

Now, as far as improving SWR… the ways I know of to fix this problem are:

  • To make the antenna a dipole, effectively doubling its length
  • Adding a ground plane or counterpoise radial
  • Adding a matching section (like a J-pole)
  • Using some sort of matching network

The thing that has me curious, is the rubber ducky antenna.  Now granted, I know those things do not radiate well.  They must however be doing something to keep the finals from blowing.  My understanding is that they’re little more than a spring in a plastic jacket… I can’t see how that is meant to match to the 50? source impedance.

The antenna design I use is apparently very similar to one used by Motorola for some of their professional radio antennas, according to this post.  Now I’m not sure how 19.5″ is arrived at — it doesn’t fit with the maths I used above, there is something I’ve missed.  Surely though, an antenna of this type would have the same impedance matching issues as the ones I’ve designed.  Either there’s other magic involved, or the finals in many handheld radios are more hardy than I thought.

At some stage I might borrow a SWR meter or antenna analyser for VHF/UHF… it’d be interesting to see just how far off the mark I am.  I haven’t blown my finals…yet.  The radio seems to still have plenty of life in it.  I’d be interested to know however, some of the background on this topic.  There is something I am missing, and I can’t quite put my finger on it.

2009/01/05 by Amateur Radio Public Syndication 0

Gentoo/MIPS uClibc Stages

Hi all…

Well, after a long hiatus, I’m working on new stages for the Gentoo/MIPS port.  These new ones will be based on uClibc, and are a compliment to the existing glibc-based stages.  At the moment, the initial seed environment is still being cross-compiled from my i686 host, and for now I’m focussing on mipsel but will soon turn my attention to MIPS.

These stages initially will not operate with a page size of 16KB or more, so unfortunately aren’t much good for Lemote users (I’m working with the uClibc people on this) but Cobalt and SGI users will soon once again be able to use uClibc as their system libc.  The new stages will be based on uClibc 0.9.30… which is yet to be keyworded.

2008/12/27 by Gentoo Development Linux Development Public Syndication 0

Can we drop this silly filter nonsense and move on?

Open letter to Minister Stephen Conroy regarding the proposed internet filter.

Over the last year, we’ve heard a number of people step up, complaining about this proposal, and what it will mean in terms of freedom-of-speech, and internet speeds.  I also heard a rumour that mentioned the blocking of peer-to-peer traffic.

Now, it is very noble of the government to be that concirned with the issues involving pornography and other objectionable material, that they are pushing forward with developing and introducing this filter to the masses.  Others have already pointed out many of the ethical and technical issues with the proposal, which I note, to date, are still not addressed.

The latest proposal however, has been to block peer-to-peer traffic.  I strongly urge those in the government to carefully consider the consequences before taking on such a drastic action.  Ignoring the fact that Bit-Torrent and similar protocols can, and are, used for legal purposes (such as distribution of open source software) as well as for piracy… a lot of other peer-to-peer protocols exist, that many people expect to be able to use freely.

Consider the following applications/protocols:

  • Skype
  • MSN Messenger
  • Ekiga
  • Yahoo! Messenger
  • TeamSpeak
  • EchoLink
  • IRLP
  • IRC DCC
  • VNC
  • RDP
  • SIP (most VoIP systems)
  • Hamachi
  • … etc

All of these, rely on peer-to-peer traffic to operate, and are used lawfully.  Blocking SIP could be disasterous to our telecommunications, since many people rely on this protocol as their primary home phone service! Such a move could proove highly unpopular with the voting public, and deadly to businesses that rely on VoIP services.  In a time of global economic crisis, is this really what you want?!

It is true that many of us absolutely hate it, when a politician breaks an election promise.  However, we are more than too happy to forgive politicians for breaking such promises, when such promises are mearly implementing bad policy.  I urge this government to consider the above, in addition to the comments made by others on this topic, before going ahead with such disasterous propositions.

2008/12/26 by Public Syndication Rants 1
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

June 2026
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon