Page 2 of 42 FirstFirst 123412 ... LastLast
Results 11 to 20 of 411

Thread: DNA Development Blog

  1. #11
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Checked and double-checked, then checked again. And tomorrow morning I am going to check AGAIN. The quote package has been put together and I am asking for bids.

    Note that flipped the board upside-down as the bottom became the top, the red side is not properly the top of the board.



    Now comes the even more fun part, the software. The Tiny84 does not have a separate boot loader section or way to repoint the interrupt vector table (required to run the usb firmware) which means I have to play some nasty tricks, I already have the approach...

    ..damnit.. my hand is KILLING me.. hurts to type.. I jammed a screwdriver into it trying to pry a battery cover off a multimeter impaled it pretty good too. its too sore to go on for now, I'll catch up in a day or so.

    Suffice to say the software is going to be open source, and anyone can install/write their own, but you had better put my little "boot watch" code section at the very top of main or it won't be possible to reflash the board. As long as it exectues my code first then whatever you screw up should be recoverable from.

  2. #12
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Okay so in order to get the "soft" bootloader working, I need to get the code to execute from the top 2k of memory, that means relocating the code in link-space, but having to deal with an interrupt vector table at 0x0000

    Okay luckily I only need one interrupt, INT0 (vector #2)

    So when the bootloader starts, before it can engage the USB code it has to first replace the vector at 0x0002 with the one at 0x0C02. Easy.. read the page, then modify the two bytes and write it, remembering what the old value was.

    This is where it gets dicey, because the boot code needs to replace the old vector with the new one or its toast.. OR the new code needs to inspect its own vector and if its too large (in 0x0C00 space) ASSUME the bootloader borked and just immediately jump into it, thus saving the chip.

    Yeah I'll do that.

    Okay first things first, locate that vector and replace it.. can I do that? Need some proof-of-concept code...

    well... F()#.

    the interrupt vector table uses rjmp, thats 'r' for relative. Means I need to relocate it by ~7k and I bet there aren't enough bits for that.. lets see...

    "Relative jump to an address within PC - 2K +1 and PC + 2K (words). For AVR microcontrollers with Program memory not exceeding 4K words (8K bytes) this instruction can address the entire memory from every address location. See also JMP"

    okay damnit. can't point the bootloader high enough. well.. wait a minute.. how do regular interrupts handle this? what if I put an ISR really high into memory? simple jump table? (ie-- rjmp to a location in range then ijmp to the actual ISR.. ?)

    Okay top of my head I can't think of an easy way to get around this. I could put the boot loader at the TOP of ram, relocating the application below it, but then I have the same problem with the APPLICATION just not immediately

    The code can't overwrite itself unless it is entirely contained outside the write region.. how about I FAKE a jump table.. page 0 is 32 bytes, I bet I can fit a single jump into it, then instead of writing the vector, write the entire code page.. oh thats slimy.. I like it.. lets see..

    okay I think this will work, I don't have time to fully flesh it out before I fallasleep on my keyboard though.. will have to explore it more later. essentially it involves writing 8 bytes to the interrupt vector table, consisting of the rjmp and some actual code.

    01 c0 rjmp .+2
    e4 e3 ldi r30, 0x34
    f2 e1 ldi r31, 0x12
    09 94 ijmp
    except substituting the address of the ISR once I have fully linked and relocated the bootloader.. at least.. I THINK that will work.. so long as the address on the stack will still bring the MCU back to the point of interrupt with the iret.. I give that a 90% chance of working.

    duh.. I don't need the rjmp, if the MCU just sets the PC to he vector location then this should do the trick

    e4 e3 ldi r30, 0x34
    f2 e1 ldi r31, 0x12
    09 94 ijmp
    yes it is late.. okay beddie bye is calling me.. until we meet again..

  3. #13
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Okay I think that was a bust. I got the vector installed correctly, even had some fun palying with a custom linking file to save some space, learned a bit there, but it didn't work.

    Current theory.. messing with r30 and r31 to do the indirect jump are not handled by the interrupt. I am used to big-system interrupts that preserve the state of the whole machine, of course they need to be pushed. which means they need to be popped, which all of a sudden gets 'complicated' because the interrupt will exit with an iret, can I call and then return from a subroutine? should work.. will try that next..

    HA! SUCCESS!!

    ef 93 push r30
    ff 93 push r31
    ec e9 ldi r30, 0x9C ; 156
    fd e0 ldi r31, 0x0D ; 13
    09 95 icall
    ff 91 pop r31
    ef 91 pop r30
    08 95 ret
    its a bit wordy for an ISR jump table but it WORKS and it only has to work for the bootloader. okay so now I can run the bootloader out of high memory, time to massage it and shrink it as much as possible.. right now the installation routine is a bit.. bloated..

    going to turn on the afterburners and really shrink the bootloader as small as I can, it can be located as high in memory as small I can make it. of course I can always update it if I need to, by uploading an app that writes to high memory love this self-programming schtick.

  4. #14
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Okay ran into an interesting problem, I detailed it in a post on the AVR forum http://forums.obdev.at/viewtopic.php?f=8&t=8538 which ate basically... 6 hours of my time... I still don't know the exact underlying cause but evidently the workaround is to ignore error 31 from windows. I have a feeling if I delay the write by a few milliseconds (enough time for the windows box to get talkback) I can bypass whatever is going wrong, but then again *shrug* who knows.

    Upshot is I can now upload code, shrinking the bootloader as much as possible now, then I will be developing some more SDK-ish stuff

  5. #15
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Oh, right.. the blog..

    been forgetting to update it.

    Big strides in the software. I now have a USB SDK that makes it very easy to send and recieve data and commands to the DNA board, right now this is only for Windows but I will be porting it to linux as well.

    Now that I have an API I will be using it to write some really.. interesting.. software to control this board. hehe..

    Yes I will make it all public as part of the DNA dev package, everything I am writing will be usable with free utilities, right now I am aiming at Visual Studio Express 2010 and win-avr. for the windows platform, and for Linux just gcc and the defaul avr-gcc will be all you need to write your own apps and extend the DNA in any direction you want, painlessly using the USB port

    Which was a friggin' PAIN IN THE #*&S let me tell you. I had to climb one hell of a cliff learning curve to get this particular USB implementation to be simple and seamless. Sure it seems kind of easy and obvious NOW, but geez if you don't know about enumerating a HID and moving data to/from it in a generic/arbitrary way through a maze of API calls, be glad I did that work for you

    Oh quotes came back and they are within the realm of believability. I don't want to announce prices yet because as everyone knows you can't un-say anything on the 'net, but it will defintly be under $100, probably in the realm of $140 with the OLED/IO module, and yes all the software you need to play with it any way you want, if you have the itch.

    I will say this, I don't have the capital to do a run on these right now, I will be needing pre-orders to convince me it is worth doing. Not asking for anything yet, let me get the dev package closer to complete and get a good feel for the value I can offer.

    skibbo at Simonized has done a fantastawsome job of drawing up the DNA board, and I haven't even made one yet! My favorite has got to be the one next to a quarter, which I used as an example of the size I was aiming for.

    That is a 4-40 screw, and yes, this is exactly how it is going to look, it's like he plucked it out of my head






  6. #16
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Good news on the fab front, I think my ducks are in a row for having the first run done.

    Work continues on the software, so much more to write for this board than any other I've ever done, since I'm releasing it all, heck I'd release snapshots now but some stuff I'm REALLY not proud of and I KNOW need fixing, nothing more annoying than someone telling you to fix something you know is broken. pet peeve.

    Did the initial work on the OLED board, this board will be bonded to the back of a 128x32 OLED display with the ribbon wrapping around the back to the ZIF on the front. It can be mounted to a PCB with the 4-pin header or remotely through the three-ping connector to a DNA board.


  7. #17
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    So I threw down a design for a 3-button interface module. It will have a small (ATTiny25 most likely) onboard chip for RNA bus communication and three buttons. It will also have a soft power on/ power off capability (when enabled, you plug the battery into it). so it will eliminate the need for an external power switch.

    I see it operating in at least two modes, w/OLED and without/OLED mode, so you don't have to have a display to run one.



    Speaking of the RNA bus, I am working on the software and it seems I can do a ~1.5us pulse width, I am planning to use a cross between Manchester encoding and I2C protocols, will see how it ends up working out but currently my thumbnail says around ~100megabit bi-directional bandwidth, should be plenty.

  8. #18
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    So I can't send the final gerbers out until I get the Axe in and make SURE this board will drive one (although I'm quite certain it will) but as a helpful way of reviewing the design I am going to go through the board component by component and describe why I chose each one and what it does. I normally do this myself but hey, if its open source why not do it 'out loud'

    U3 - ATTiny84p This chip has 8k of program space, the most I could find in this chip, Atmel has a rich supply of hobbyist-level tools, this chip has an A2D, I2C support, ran at a wide range of voltages, and what I thought at first was enough I/O to do any job, turns out it had just enough.

    XTL - In order to use the bit-banger usb implementation both D- and D+ must be on the same bus, and D+ must be hooked up to INT0. Which means, since the /reset line is on the B bus, that only leaves one pin left for clock, so I have to use an actual clock (single input) rather than a crystal or ceramic resonator (two wires). Downside is power consumption, it can't be shut down when the processor sleeps.

    C2 - datasheet on the XTL reccomends a .01uf decoupling cap, this helps control the ringing at high and low, which is pretty bad for a high slew-rate chip like this. Its okay without it, I ran the math and took a look at the 'scope and the clock is good enough, but it does ring like ma bell. If I have the space (and I do) its best to do what the datasheet recommends. Could go with an 0402 cap here, but ended up using an 0603 so I could compfortably run a trace between the pads.

    C3 - a nice honkin' 10uf cap for power stability. a value this large (relatively) is good for controlling ground bounce and general VR stability. 0402 works here but is a big value for a small 0402 part, found one that is only rated to 4v but thats okay, the bus runs at 3.6v

    LED - I brought blue lights to paintball (why do you think I called my first board the 'Glacier' it's my trademark, even if that has been forgotten as everyone else uses them. Wanted an 0803 LED, picked one that fit the pattern and had a reasonable cost. Sourced it, specced it out, and am runing it at around 6ma. That makes R13 around 100ohm. It's plenty bright. I also decided to face it to the bottom so it can shine through what it's bolted to.

    R11 and R12 are a voltage divider that share a pin with the LED The reason for this is actually routing, not lack of I/O. I couldn't figure out a way to run SCA and SDL direct out of the 10-pin header, finnaly my solution was to dual-purpose the LED pin. Its main job is driving the LED, it can easily drive low, and when it comes time to digitize the battery voltage, it just switches to input and the LED no longer figures into the equation, the voltage at A7 becomes a ratio of R11 and R12. The datasheet reccomends 10k impedence so I set R12 to that, then the internal voltage reference is 1.1v, and the max input for the DNA is 20v, so that means the top-side resistor needs to be around 180ohm.

    R10 and R8 are 68 ohm resistors that are rquired for the differential lines (D+/D-) on a USB connection

    R9 is a 1.5k pullup on the USB bus which is required by the spec

    R10 is a 1M resistor to ground to prevent spurious interrups on the D- line

    C1 is a 10uf capacitor on the INPUT, so it needs to be rated for 20+ volts, This cap may or may not be required, but I'm leaving the place for it to be hand-soldered if necessary, depending on how it affects the quote.

    C2 is a decoupling cap across the CPU, .1uf is pretty universal here, also smooths out the voltage regulator.

    D1 and D2 are wonder-components. If I told you what they do and are in an 0603 package you would say I was crazy because no other component is even close. They are acting as flyback shottky diodes, and I swear, been over the data sheets backward and forward.. they can handle 2A continuous current (28amp surge!), and have a 30v breakdown. I sourced them and they are like micro-monoliths. all metal with two ridiculously impossible soldering patches.

    D3 is more typical, this shottky is used to isloate the USB power bus from the Vin of the board. This way if the battery is connected it won't feedback power, but if there is no battery, the USB power takes over. Upshot is you plug it in to USB and it "just works".

    The USB plug does not have holes for mounting as many do, it is solder-only. This means it is not as mechanically well attached as it might be, so I left LOADS of copper all around it to act as a solid base. its also there to provide a good ground plane, and heat sink fot he voltage regulator.

    Which does bring us to U1 This little champ can handle 24 volts in, and has an absurdly low dropout at 3.6v, and can feed the board 150ma... theoretically. More realistically with heat dissipation at 20v its ~35mah, but the board only uses 15 or so with it's hair on fire, so plenty of safety. It does heat up quite a bit when dropping 20v, but with enough copper as heatsink (and I think I have enough) it should be okay, especially since the USB plug will be it's heatsink.

    H2 is the .1" space 3-pin connector that will be the 'RNA' bus, a Manchester-encoded single-wire protocol. At least that is the plan. I may end up trying for a fixed clock with occasional sync pulses or something.

    U2 is the MOSFET driving the power channels. Two of them in one package, and they are doosies. 20volts a 9.4 amps CONTINUOUS?! can handle a 38amp pulse? You will blow up the copper trace before you blow up this chip I guarantee it, and I ran the thickest traces I could to this monster.

    R1 and R2 are 10k resistors to hold the gates down during powerup/powerdown to make sure the MOSFET doesn't just start conducting with a direct command from the MCU

    Spaking of which, R3 and R5 are series resistors to current-limit the gate drive, 22ohm is plenty without affecting slew rate by anything a solenoid will care about.

    R6 (if I haven't mentioned already) is used to drive an LED, at 475 ohms it will be perfect for a low-level drive for an emitter. In case that value is not good, the pin can be driven directly via the SDA pin from the processor.

    Speaking of that, I ran the SCL and SDA pins directly out the top header, so the DNA board can communicate with any I2C hardware directly. This includes every peripheral I've seen for Arduino and Card/Blade/Tray whatever thingy

    R4 is a pulldown for use with a detector, 3.6k is a good value at this voltage. I made sure to wire the detector to an A2D port if that is necessary, same as all the other pins I ran out of the chip (excepting the RNA bus)

    I think that's everything. One more review in the morning and the gold-plated gerbers get shipped out, here she is:


  9. #19
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Just finished porting the USB implementation to Linux, so now there is a simple, generic way to talk to the DNA board through the USB port without needing to know any of the gory details, data comes in one side, popps out the other.

    I used hidapi which seemed like a real time-saver, and I guess in the end it was, but boy what a state that code is in. It crashed (had to fix some wide-char bugs) and hung (had to remove the improper pthread use) and didn't even really work, but it managed to implement the only two things I needed: report send and report recieve, even if I had to bang on it with a hammer a little.

    Next up will be porting the morlock code to AVR, shouldn't be too much trouble.

    Oh something else that is kind of nice, out of convenience (not because I thought it would work) I tried firing up linux on VirtualBox on the PC I have at my bench to see if I could use the USB implementation, and it worked! I'll be damned.

  10. #20
    Insider Curt's Avatar
    Join Date
    Jun 2013
    Location
    Atlanta, GA
    Posts
    295
    Supports Inception Designs
    Supports Inception Designs
    Got i2c sorted out on the Atmega88, the chip I hooked it up to, and it works! problem is, and I wish I had know this at the time, the ATTiny has a completely different set of registers controlling its i2c.

    SIGH.

    I am generally put off by the quality/composition of the example code I've found for i2c and, well, microcontrollers in general. Well that's not entirely true, most 'sample' code I read on the internet is dicey. Even distributions and code the programmers are clearly proud of. I see a huge amount of "it was hard to write, it should be hard to read"

    Anyways I have another problem. The OLED screen I am using works great, awesome contrast, it's fast enough (I can load 20fps thorugh the I2C bus) and fairly straightforward to address..

    problem is this, in the documentation:

    To read data from the GDDRAM, select HIGH for both the R/W# (WR#) pin and the D/C# pin for 6800-
    series parallel mode and select LOW for the E (RD#) pin and HIGH for the D/C# pin for 8080-series parallel
    mode. No data read is provided in serial mode operation.


    Seriously? Okay that means I can't read the frame buffer to AND bits onto it while constructing an image. Which means I need t know an entire row's contents ahead of time before blitting.. so I need a frame buffer.

    No problem! 128x32 bits is, 512 bytes. right. the exact size of the entire RAM in an AVR chip.

    So I need external RAM. alrighty, well how about THIS http://www.digikey.com/product-detai...FSN-ND/2001116 serial access, small package, not too expensive.

    So I have one on order, and now I have to redesign the board a bit to make room.

    In other news I rowbarred one of my old font-drawing libraries into this, will be really cool to see fonts.

    OH if anyone has any 128x32 images they would like to see on this thing send them to me and I'll preload them onto the EEPROM (which I'm using as a character buffer)

Posting Permissions

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