Page 5 of 42 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 411

Thread: DNA Development Blog

  1. #41
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Quote Originally Posted by sumorai View Post
    What happens if you need to update the bootloader?
    two things

    1- It should never need to happen, since a bootloader's job is very well defined, single-purpose, and easy to debug.
    2- If it DOES need to happen, for whatever reason, it's easy. Upload a program who's sole job it is to overwrite the bootloader with a new bootloader. As I indicated, you can write and upload code that will clobber the bootloader Flash, just don't. Not like you will accidentally do that, self-programming program Flash is very purposeful, complicated, and dark-magic that is never be necessary for a user app, its only ever done by, well bootloaders. Remember I'm talking about the Flash here, not the on-board EEPROM, use that for whatever you want.

  2. #42
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    And have now added the final touch to the loader, it decompiles the code image and makes sure the emergency bootloader-shunt will always be honored in any code to be uploaded.

    It is extremely finicky, whatever image is compiled must be opcode-for-opcode identical with what it is expecting. This shouldn't be a problem as long as the code is compiled with exactly the same compiler, already checked that Win32 and linux versions of the compiler produce identical code, I have been asked to do an OSX port of this code but who knows if that is going to happen.

    In any case I am still mulling an override button, "really really really don't press yes" and I am currently coming down on the side of no, you may NOT load code the loader does not like, with an on-the-spot explanation as to why you have been dissed, and what steps can be taken to fix the problem. Its just too terrible a thing if unrecoverable code gets pushed onto this board.

  3. #43
    Ah, yeah. I was just thinking if you had to add something to the bootloader in the future, it sounded like it wasn't going to be able to be updated unless you physically reprogrammed the chip.

    Well, I'm on OSX, so that's what I'd need to be using for this. Although, I could just run it in Windows under Parallels if need be.

  4. #44
    I'm on osx as well

  5. #45
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    well I will definitely write an OSX compatible DNA command-line tool, unless there is some crazy driver problem that prevents it, but I strongly doubt there is. The main reason is I will likely be teaching a local robotics class with the DNA board (intro course to younger kids- http://www.startcode.net/ ) and they will be bringing their own laptops, which tend to the Mac. This will have zero to do with paintball by the way, just learning about embedded systems.

    However for morlock-dialog adjusting, that will only be working on Windows, sorry. Good news is it should work fine on an emulator, I don't do anything non-standard.

  6. #46
    Would the command line tool be capable of uploading settings to the board like the windows GUI tool will be? If so, maybe I could take a shot at whipping up a GUI front-end for it.

  7. #47
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    heh, hadn't thought of that and it's so obvious, and easy to code. sure of course.

  8. #48
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Spent all morning on this, getting an OSX version.

    Damn Apple kinda hates developers now, doesn't it? Documentation is spotty, have to register with THE MACHINE to be a developer rather than just get a compiler and go.

    Anyways started out easily enough, code compiled, showed me a bunch of devices... none of which were the DNA board.

    well WTF? I was able to see it with "system_profiler SPUSBDataType" but it wasn't showing up as a HID. Much hair-pulling and documentation-reading and sample-code bashing later I was no closer to figuring out why it wasn't showing me what I was expecting so I started looking for zebras*

    One of the last things I tried was enabling interrupt-driven endpoints even though I am not using them, and they are not required (strictly) by the HID spec and 'alakazammo' it showed up. great. Except that feature requires 100+ bytes more of space in the flash so instead of basing at 0x18E0 it's not at 0x18C0. After I spent so much effort packing it into a smaller space, too.

    Well I have two versions of the bootloader now, one 'mac' that has the bloat and the regular one that works on linux and windows without it. I'll let the user decide which one he wants to load, guess its a good thing I thought through an ability to update the bootloader

    More as I know it, halfway to having an OSX port of the loader/command-line morlock config app

    *one of my favorite sayings "When you hear hoofbeats, think horses, not zebras" except every so often it turns out to be one

  9. #49
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Okay was a royal pain in the butt however the OSX port is now up on git. Next up JSON readable format. Then tonight I finish up the design for button and OLED boards.

  10. #50
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    HA! HAHAH! did it! after 4 attempts and multiple round-trips to Digi-Key, I finally have it, a circuit that can:

    1- consume zero power when off, none, not even a little bit.
    2- turn on with the push of a button with no moving parts
    3- sample that same button to use it as input
    4- turn off at the command of the MCU
    5- be able to switch 9-ish amps
    6- minimal component count, with nothing too expensive (no space-age solid-state relays made out of gold-pressed-latinum)
    7- be able to handle ~5-~20volts and operate correctly over that range

    Done! I'll post a schematic soon if you really want to see it, I'm sure its nothing a decent EE couldn't knock out in an afternoon, but I am proud of it

    -Curt
    Last edited by Curt; 08-10-2013 at 06:49 PM.

Posting Permissions

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