Page 4 of 42 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 411

Thread: DNA Development Blog

  1. #31
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    That workhorse is vintage 1983. Solid, dependable, accurate.. It's all I've ever needed

  2. #32
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    added mounting tabs to the OELD board, and kept the traces well clear of them so they can be filed/cut off if necessary, the holes are 2.9mm for 4-40 but can be drilled out a little if need be.


  3. #33
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Damn pisser... the ATTiny84, despite having clearly labeled SDA and SCL pins has a poor excuse for TWI support. it gives you a single shift register and leaves it to software to generate a clock. that is BS. looks like I'm bit-banging for the I2C out of this thing, how annoying. Means refreshes on the OLED screen are going to be a bit slower than 33fps, maybe down to 20 or so, still respectable but starting to get into the danger-range of being able to see a vblank.

    Still pretty upset about this. Might consider finding a different chip for the OLED board.

  4. #34
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    hmmm.. I kinda take it back.. seems like they took away some of the fire-and-forgetness, will be more work and hair-pulling (without a logic-analyzer this can be annoying) but I guess it'll be fun bashing it together.

  5. #35
    Insider
    Join Date
    Jun 2012
    Location
    Auckland, NZ
    Posts
    284
    To my shame I've never actually worked with EEPROMs before, and only briefly with I2C. Would it be programmable in-circuit via the ATtiny (or an external TTL hookup)?

    Liking how simple the back plane is getting. It makes it possible to do a single-sided board by hand, replacing the back and vias with hookup wire. Of course I hope you'll put out some unpopulated boards
    Last edited by neftaly; 08-04-2013 at 07:49 PM.

  6. #36
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    The EEPROM will be in-circuit programmable of course, I plan to load it through the (yet to be invented) RNA bus, I also intend to be able to bootload the ATTiny and reflash it through that same bus.

    I do not plan to come out with unpopulated boards, but if you want to have a go of it I will order a few with the regular batch. That ZIF is a royal PITA to solder, .5mm spacing? I have to use my finest soldering tip and a magnifying glass. I left the rest of the components 0805 though in case I DID have to assemble these myself.

  7. #37
    Insider
    Join Date
    Jun 2012
    Location
    Auckland, NZ
    Posts
    284
    Awesome, I certainly would. I'm set up for hot air SMD work (though I've hand-soldered that fine before with paste) so it shouldn't be a problem.

  8. #38
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Sometimes its the little things.

    So I spent the better half of the last 4 hours bomb-proofing the bootloader, in the production chip the /RESET pin will be disabled, meaning even if you could easily get to the 6 programming pins on the chip, you would need a high-voltage programmer to program it, not crazy-expensive, but not cheap.

    So the bootloader better be able to recover from anything. So here are the precautions it takes:

    1- the loader will refuse to load any code that would overwrite the bootloader itself
    2- the loader will refuse to load any code that does not have its reset (interrupt 0) vector pointed at the programming-dongle checker, this will be a short across the bottom header that, if detected, jumps to the bootloader instead of the user app, this code is executed immediately out of reset before C has even initted itself. ie- As long as you include dna.h/c you cannot, CAN NOT write code that the DNA will not recover from, without deliberate effort, like, well, reprogramming the Flash. don't do that.
    3- once the bootloader loads itself, it rewrites page 0 so it will always be entered, you must load new code, this is necessary since it completely butchers INT0 to become a trampoline
    4- the 0th page is committed LAST, and must be validated by checksum from the loader
    5- (convenience) when the DNA USB library detects an "enter bootloader" command, it does so with a watchdog timer timout, thus insuring that the chip is basically in a cold-boot state (no interrupts will be triggering, I/O pin state can be inferred, etc..), while this could also be achieved by actually cold-booting the board, its nice to have everything reset without unplugging wires.

    The one thing I wanted to add that I just couldn't fit in was a check on the bootloader size to prevent it from overwriting itself, but I managed to squeeze the code into the upper 0x18E0 location, and I just don't want to give up 64 more bytes of user space, since only the loader even knows HOW to communicate with the board, and it has safeguards built in.

    If you really REALLY want to defeat them, well you can, but sheesh why?

    Took me quite a bit of SQUEEZING to get it that small, short of changing the clock rate, I don't see how I can get another 64 bytes out of it, but I am open to suggestions. (has to be at least that much to be worthwhile, since the Flash is written in pages only)

    git push reflects everything I just talked about.

  9. #39
    What happens if you need to update the bootloader?

  10. #40
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Quote Originally Posted by Curt View Post
    The one thing I wanted to add that I just couldn't fit in was a check on the bootloader size to prevent it from overwriting itself
    didn't need those 3 hours anyway.

    managed to squeeze in a check where the bootloader will refuse to erase/commit a page on top of itself never worked so hard to get a

    if ( address >= 0x18C0 ) return;

    into a program before, but I am literally on the edge, the bootloader is exactly 28 pages (28 * 64 = 1792 bytes) long.

    Why the emphasis on size? Becuase this is the resident program on the DNA that takes away from user-space programming, every byte taken up here is one the user program can't use and I want it to be as teeny as possible. The entire device has 8192 bytes, the bootloader eats 22% of that, that is significant! This takes me back to the KM2 days where I was packing way more features than I ever intended onto boards that already had their hardware set in stone.

    I think I have a way to make the code even smaller, but it will require a hardware change that is too late to make, perhaps in the future I will.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •