Mark 4.2.3 – More grunt needed. As always.

While everyone’s off to Kiwiburn, we’re off to Rainbow Serpent in Oz. It just worked out that way. Anyway, for the Mark 4.2.3 I’ve fixed lots of bugs, mended a couple of screws, implemented a couple of more structured modes, 24 modes in total, and doubled the speed – 10 ms per refresh.

I’ve also nearly run out of program memory (28 kB out of 30 kB) and RAM, so fitting in the code for the audio, BlueTooth, and motion-responsive patterns is going to be tricky.

More grunt needed. As always.

I must go now, to rejoin my people:

13 Responses to 'Mark 4.2.3 – More grunt needed. As always.'

  1. randomdreams says:

    Looking fantastic, as usual.

  2. Anonymous says:

    Have you looked into using an SSD card to store data for the modes and patterns?

    Another option: http://playground.arduino.cc/code/I2CEEPROM

  3. Anonymous says:

    Have you looked into using an SSD card to store data for the modes and patterns?

    Another option: http://playground.arduino.cc/code/I2CEEPROM

  4. grist says:

    Have you looked into using an SSD card to store data for the modes and patterns?

    Another option: http://playground.arduino.cc/code/I2CEEPROM

    • admin says:

      There’s a 128 kB EEPROM sitting on the I2C bus, but I’ve been too busy getting the motion sensors to play nicely with the I2C libraries to get that up and running. Plan is for a bunch of images and textures to sit in the EEPROM, the microcontroller to grab one and to display that.

      When I last played with it, I could get 1 byte per millisecond transfer rates, which isn’t right, but buggered if I could find a problem with it. I’m trying to push a new pattern out the door ever 10 milliseconds, so loading up a 8×8 pixel image with three bytes per pixel for RGB… that’s not quite right. I’ve a plan for more messing about trying to get libraries that work with all of the sensors and the EEPROM and are fast enough, but not this month.

      An SSD card could be the way to go, I’ve seen some people use them with Arduinos. Do you know about the code overhead, memory footprint, and transfer rate? And if the Arduino’s connecting to the SSD over SPI and it’s also driving the LED strip via SPI, then is that an issue?

      • grist says:

        That does seem slow. I don’t know which mode the Arduino code uses, but even the original 1970s I2C spec is 100kbit/sec, or around 12 bytes per millisecond give or take parity and other overheads. I might do some testing with my ATtiny2313 slave this weekend and see what I can get.

        The questions about SSD usage are excellent and I have no idea. 😀

        Do you use Reddit? The /r/Arduino forum can be quite helpful for getting other people’s experiences.

        I’ve also started writing stuff in AVR-GCC which might be another avenue. There is reasonable library and community support for most common technologies. I have a PIR triggered SSR, the Arduino code for which resulted in 918 bytes. Whereas the AVR-GCC version is only 336 bytes. It’s a bit of a jump and there are some really nice convenience features in the Arduino code that I miss (delay, for one, is far more complicated than it first appears if you want much longer than 250ms), but ultimately should be worth it.

        • admin says:

          One other thing to note, the Arduino’s standard I2C library is Wire.h and it’s a dog. It can lock up the whole thing and regularly does. I’ve been using Wayne Truchsess’s I2C library, which is far better built.

          Am keen to see how fast it goes for reading multiple bytes at a time.

        • admin says:

          One other thing to note, the Arduino’s standard I2C library is Wire.h and it’s a dog. It can lock up the whole thing and regularly does. I’ve been using Wayne Truchsess’s I2C library, which is far better built.

          Am keen to see how fast it goes for reading multiple bytes at a time.

        • admin says:

          One other thing to note, the Arduino’s standard I2C library is Wire.h and it’s a dog. It can lock up the whole thing and regularly does. I’ve been using Wayne Truchsess’s I2C library, which is far better built.

          Am keen to see how fast it goes for reading multiple bytes at a time.

      • grist says:

        That does seem slow. I don’t know which mode the Arduino code uses, but even the original 1970s I2C spec is 100kbit/sec, or around 12 bytes per millisecond give or take parity and other overheads. I might do some testing with my ATtiny2313 slave this weekend and see what I can get.

        The questions about SSD usage are excellent and I have no idea. 😀

        Do you use Reddit? The /r/Arduino forum can be quite helpful for getting other people’s experiences.

        I’ve also started writing stuff in AVR-GCC which might be another avenue. There is reasonable library and community support for most common technologies. I have a PIR triggered SSR, the Arduino code for which resulted in 918 bytes. Whereas the AVR-GCC version is only 336 bytes. It’s a bit of a jump and there are some really nice convenience features in the Arduino code that I miss (delay, for one, is far more complicated than it first appears if you want much longer than 250ms), but ultimately should be worth it.

      • grist says:

        That does seem slow. I don’t know which mode the Arduino code uses, but even the original 1970s I2C spec is 100kbit/sec, or around 12 bytes per millisecond give or take parity and other overheads. I might do some testing with my ATtiny2313 slave this weekend and see what I can get.

        The questions about SSD usage are excellent and I have no idea. 😀

        Do you use Reddit? The /r/Arduino forum can be quite helpful for getting other people’s experiences.

        I’ve also started writing stuff in AVR-GCC which might be another avenue. There is reasonable library and community support for most common technologies. I have a PIR triggered SSR, the Arduino code for which resulted in 918 bytes. Whereas the AVR-GCC version is only 336 bytes. It’s a bit of a jump and there are some really nice convenience features in the Arduino code that I miss (delay, for one, is far more complicated than it first appears if you want much longer than 250ms), but ultimately should be worth it.

    • admin says:

      There’s a 128 kB EEPROM sitting on the I2C bus, but I’ve been too busy getting the motion sensors to play nicely with the I2C libraries to get that up and running. Plan is for a bunch of images and textures to sit in the EEPROM, the microcontroller to grab one and to display that.

      When I last played with it, I could get 1 byte per millisecond transfer rates, which isn’t right, but buggered if I could find a problem with it. I’m trying to push a new pattern out the door ever 10 milliseconds, so loading up a 8×8 pixel image with three bytes per pixel for RGB… that’s not quite right. I’ve a plan for more messing about trying to get libraries that work with all of the sensors and the EEPROM and are fast enough, but not this month.

      An SSD card could be the way to go, I’ve seen some people use them with Arduinos. Do you know about the code overhead, memory footprint, and transfer rate? And if the Arduino’s connecting to the SSD over SPI and it’s also driving the LED strip via SPI, then is that an issue?

    • admin says:

      There’s a 128 kB EEPROM sitting on the I2C bus, but I’ve been too busy getting the motion sensors to play nicely with the I2C libraries to get that up and running. Plan is for a bunch of images and textures to sit in the EEPROM, the microcontroller to grab one and to display that.

      When I last played with it, I could get 1 byte per millisecond transfer rates, which isn’t right, but buggered if I could find a problem with it. I’m trying to push a new pattern out the door ever 10 milliseconds, so loading up a 8×8 pixel image with three bytes per pixel for RGB… that’s not quite right. I’ve a plan for more messing about trying to get libraries that work with all of the sensors and the EEPROM and are fast enough, but not this month.

      An SSD card could be the way to go, I’ve seen some people use them with Arduinos. Do you know about the code overhead, memory footprint, and transfer rate? And if the Arduino’s connecting to the SSD over SPI and it’s also driving the LED strip via SPI, then is that an issue?

Leave a Reply

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

*