Curse you, unstated chain of dependencies

Back on the Mitochondrion head-banging trek. It was doing weird stuff, as usual, but when it’s doing really weird stuff then there’s probably a problem deep, deep down in the code. Spend the day looking, and trying to sort out other things.

Power regulator still exploding. NFI but I have a backup plan.

Can’t reproduce the Canaan Downs bug, grr…

Yup, pointer bug in the lowest level of the code. Took till 9 pm to find it, but find it I did, and then a whole bunch of pretty lights just started doing what they should. I’m getting really fed up of having to deal with BASIC, it’s like giving a fire-spinner nothing but petrol – it might be okay, but it’s just so easy for everything to go horribly wrong. Next project will be an Arduino, coz then I can use C (sort of), and have such delights as:

  • functions
  • passable function arguments
  • local variables
  • libraries so I don’t have to write my own linked lists
  • header files
  • and other programming advances from the 1970s

In other news, “Coal firm pays for emissions report”. Well, what do you expect? A company’s entitled to defend its business position. What disappoints me is that the report (“The impact of the proposed Emissions Trading Scheme on New Zealand’s economy”, briefer summary) was given so much credibility when it first came out, given that’s it’s a transparent and egregious attempt at producing the numbers that the client wanted, rather than numbers that anyone might believe. At least the Minister of Climate Change at the time called it just plain wrong.

Anyway, as mentioned, speed gospel:
http://www.youtube.com/watch?v=TQdIiEUFtqk

And gabbatubbies:

http://www.youtube.com/watch?v=a_F5Jjr7vaY
Includes Rotterdam Terror Corps, all good gabba should.

15 thoughts on “Curse you, unstated chain of dependencies”

  1. other programming advances from the 1970s

    So you don’t want to write tight efficient code, then?

    Mind you I agree with you about Basic – it’s fine for simple jobs, but if you want to write Real Code for the Real World, then it will as often shoot you in the foot as not…

    Congrats on finding the bug, BTW…

    1. Structured coding hit a fairly hit point in the 1970s with C and, frankly, all this code, in the end, comes down to simply chucking 8 bytes at each of 8 drivers. I don’t mean device drivers, I mean actual lumps of fairly dumb hardware that look like this:

      So for that, C is pretty ideal.

      (I want to write it in Python, but that’s coz I’m distracted by the conceptual shinyness.)

      1. I kinda doubt that Python is ever going to be suitable for a small Havard architecture CPU. Aside from anything else, duck typing means that the environment must have the code linked to handle all possible types? Also the stack/heap model is not a good way to manage small amounts of RAM.

        C has the advantage of having been developed when all computers had limited resource (like a 256k PDP11/34 running Unix v6) and so it has a fairly determinate mapping to the underlying machine.

        However, maybe the ARM architecture will be practical for microcontroller applications before too long?

        1. Doesn’t stop people from trying though:
          PyMite

          But yup, I’m all for clear mapping to the underlying hardware, especially when I’m building the underlying hardware. Mark 4 will have one LED per one byte register, not 5 LEDs across 4 registers.

          1. In 2007, PyMite reached the 4 KiB RAM limit and development hit a wall. In 2008, the lead developer took time off from PyMite. In 2009, there is growing interest in raising the RAM limits to allow PyMite development to continue. This would mean that unless your AVR has external RAM, it won’t be able to run PyMite.

            Yes, I could have forecast that.

          2. And for their next trick, they’ll get a one inch tube and try to fit inside it forty-two LEDs, eight batteries, six circuit boards, twelve chips, 150 resistors, 256k RAM, two accelerometers, a microphone, three sockets, two op-amps, twenty-four bolts and a partridge in a pear tree.

            No wait, I already did that.

            Bastard partridge. Everything’s his fault.

  2. I’m still thinking about the power supply question.

    I’ve been making mini-arduinos: DIP package smaller than a standard 40 pin dip. They seem to work. If you want, I’d be glad to send one.

    1. At this stage, I’d need to rewrite all the code and fit it into a very small space already occupied by the audio amps, accelerometers, and memory. I’m not quite that desperate yet.

      But I’ll be keen for a play when I start on the Mark 4, coz that’s going to involve a blank sheet for processor, development environment and packaging.

      1. Your other option might be to get a PIC programmer and use bare PICs rather than PicAxe.

        If you do want to go down the Atmel route, I have the USB programmer for those. Also I need to write a serial bootstrap loader at some stage so I can provide updated firmware to customers.

        1. Right now, I’m not going to think too hard about the processor for the Mark 4, need to get the Mark 3 to behave better for Kiwiburn (in *gulp* 27 days).

          But yes, lots to consider before deciding which route to go amongst arduino/PIC/atmel/whatever else, power reqs, ease of programming, community support, raw speed, an OO language, simple interfacing with bits and bobs, short development cycle, enough program memory for everything, form factor, all the rest.

          Still, it’d be nice if it had the grunt to do video over a wireless link…

  3. I’ve been working with the AVR 8-bit microcontrollers recently, and i’ve got to say, so far i like them. Using the GCC toolchain, and straight-wire PC parallel port to ISP connector (5 wires) interface to program them. Someone lent me an STK500 dev board, but i haven’t yet bothered to use it; making a dev board for the AVRs is ridiculously simple.

    1. And therein lies the problem, there’s lots of different product families that will do the job, I’ll need to find one that’ll fit best with my own personal foibles, but testing each one would take a while.

      Or I could use the rocket scientist approach – just write a ludicrous specification and see what comes closest. 32-bit and wireless programming?

      (There’s always the reverse side of the rocket scientist approach – spend a zillion years getting it to work.)

      ((Actually, the 32-bit idea isn’t too silly, the drivers I’m using have four bytes for the output registers and being able to rapidly bang around with those four bytes as one long int really appeals. Ok, so C will let me chuck a while bunch of bytes together in an array and dirty things to them, but having the underlying implementation as 32 bits seems like the right way to go. Then again, anything that’s not a Picaxe should be fast enough to make no difference. On the third hand, if I’ve got a decent setup, say 100+ PCA9635 driver chips, then the bandwidth is potentially silly. I’m not sure what the limiting factor would be, possibly the i2c bus, but I’d like to have a processor that could hit the limit of that. See? I shouldn’t start thinking about all this yet, when I’ve the Mark 3 to finish.))

  4. I’ve also been working on the AVR family, using avr-gcc toolchain.

    Managed to get a decent whack into my $SECRET_PROJECT and am at the point of ordering real hardware to take it out of simulation and into .. real hardware. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *