avatar

tetsujin

Member Since: July 23, 2008

Country: United States

Profile

Interests

Model-making, programming, electronics

Websites

http://scope-eye.net

  • You could still possibly come out ahead since the architecture doesn’t natively support integer division. For instance: you don’t need to actually sum the digits repeatedly. You can sum them once, mod 3:

    unsigned long x = some_value;
    unsigned char mod_result = 0;
    while (x) {
        hex_digit = (x & 0x0f);
        x = x >> 4;
        switch (hex_digit) {
            case 1:
            case 4:
            case 7:
            case 0xa:
            case 0xd:
                // ((hex_digit * 16^d) % 3 = 1) for any positive integer (d)
                // Because (hex_digit % 3 =1), and
                // (hex_digit * 16 % 3) = ((hex_digit * 15) + hex_digit) % 3
                // which equals (hex_digit % 3) (since (x * 15 % 3) = 0 for any x)
                mod_result += 1;
                break;
            case 2:
            case 5:
            case 8:
            case 0xb:
            case 0xe:
                mod_result += 2;
                break;
        }
        if (mod_result >= 3) mod_result -= 3;
    }
    

    This probably gives you a faster “x % 3” than you’d get from the compiler (it depends on how heavily it optimizes cases where the divisor is known at compile time), but the trade-off is that you are using more code space to do it. Like many optimizations, it becomes a question of how badly you need this one specific operation to be fast. (The above method could also be used for mod 7, by taking three bits at a time, or mod 15, by taking four bits at a time, and adjusting the switch statement accordingly)

    On an architecture with integer division implemented in hardware, it’s less likely the above method would be worth using. But on AVR it should be faster than an actual division algorithm - the switch statement could be implemented as a jump table, so the whole thing would take roughly 35 instruction cycles per hex digit, and probably a couple hundred bytes of instruction storage.

  • Really you’d just need 3 accessible pads, as the other 3 (power, ground, reset) are already broken out as pins… I already repaired my Microview, and added a pin header to the left side to make it easier to reprogram the bootloader. It really is packed in there, though. Microview is a very space-efficient design. To put a pin header in I had to thin down a section of the plastic’s bottom wall and seat the header in there. In retrospect it wasn’t really worth it. How often am I going to reprogram the bootloader? How often am I going to use the Microview’s SPI for something other than the display? The Microview design could have been made more space-efficient by using a smaller version of the ATMega328 - QFN maybe instead of TQFP. But even then, it’d be hard to add a pin header anywhere but the bottom due to the way injection-molding works. (To mold a hole in the side of the case, you either need a three-part mold, or the hole has to be open to the top or bottom of the unit as well) My efforts at altering the Microview have given me a real appreciation for the elegance of the stock design.

  • When you plug in a USB-to-serial adapter, it gets enumerated by the system and gets some kind of designation. On Windows it gets a numbered COM port (COM1, COM2, etc.) as if it were an old RS-232 port. On Linux and Mac, the designation is more flexible. The main requirement is that the designation for a newly-plugged-in device can’t be the same as the designation for another device that’s already plugged in. On the Mac with the FTDI driver I think those last four hex digits at the end of the designation are the device’s serial number. It’s ugly to look at but the upshot is that any time you use the same device, it should have the same designation… Unlike Windows or Linux (my system anyway) where it’ll be given some arbitrary number…

  • Well, I think you’d be hard-pressed to fit a Bluetooth module in there. I just added a header to break out the ISP lines - so I can tell you, there really isn’t a lot of unused space inside the casing of this thing. Putting a couple pushbuttons on some of the non-exposed I/O pins would require changes to the plastics (to incorporate holes and caps for the buttons - possibly necessitating a slide-mold to put the buttons on the side of the unit) and probably a more compact layout for the PCB (replacing the TQFP ‘328 with a QFN, for starters) to make space for the switches themselves. It’s an expensive proposition unfortunately but otherwise well within the realm of possiblity.

  • Given that there’s only $5 difference between the FTDI version and the TTL-only version, the TTL-only version seems a bit extraneous. Perhaps in the next revision you should add a footprint for a TTL pin header so this board can serve both roles.

  • Unfortunately they can’t do that. To reprogram the AVR without the bootloader installed, you need access to the SPI port. Because the SPI port on the Microview is used to operate the display, it’s not broken out on the device’s pin headers. So you can’t burn a bootloader to the Microview without taking it out of its case. Fortunately, it’s not too difficult to remove the unit from its case. (Pretty much just pop the lens off)

  • It’s actually not that bad. The clear lens is trapped by the black plastic casing. Wedge a small tool between the two on the left or right side and the clear lens pops off pretty easily - then just push the pins from below to remove the Microview from the casing. I’m planning to install an ISP header and maybe a couple pushbuttons in mine while I’ve got it open…

  • Alternately - leave the FTDI adapter plugged in and just switch different Microviews into it.

  • Can’t view it.

  • There are much cheaper 3D printers out there, if you’re willing to sacrifice build volume and (possibly) overall quality of the machine.

No public wish lists :(