Page 1 of 13 12311 ... LastLast
Results 1 to 10 of 130

Thread: GCode Angel project

  1. #1

    GCode Angel project

    Thought I would share something I have been working on. With the great GCode, and ALOT of help from Dirty Engineer, among others, I have started my own OLED angel (LCD-G7FLY) board project.

    Items so far:
    1. Schematic
    2. Design board
    3. modify GCode for OLED support

    To Do:
    1. Verify electricals
    2. Verify battery monitor circuit
    3. Silkscreen layer
    4. Prototype

    Compromises:
    1. Gave up forcing code onto 328p and went with the 644p. Even if i did get it to fit on the 328p, it would be almost un ungradeable. With the 644p, plenty of room to add firemodes later on




    Attached Images Attached Images
    Last edited by jptheripper; 02-20-2015 at 02:47 PM.

  2. #2
    You have really learned a lot in a short amount of time, It's impressive. Keep up the great work!

    It's great to see the Gcode project finally moving forward again. I'm excited to see where this goes.

  3. #3
    v6 of board


  4. #4
    Insider new ion?'s Avatar
    Join Date
    Feb 2013
    Location
    Victoria, BC
    Posts
    1,296
    What traces do you have running under the MCU? Admittedly, I don't know what controller you're using.

  5. #5
    its an atmega 644p. The only traces that go under the mcu are directly to a pin, or VCC/GND connecting pins on the mcu

  6. #6
    Insider new ion?'s Avatar
    Join Date
    Feb 2013
    Location
    Victoria, BC
    Posts
    1,296
    I figured you'd use an atmel device.

    I wonder how much noise you'll end up seeing on some of those lines due to running them under the chip.

    What screen are you using?

  7. #7
    It's actually fairly common practice to route under the MC. Generally, if the signals are logic, there is little or no problem. For some ICs, you can even route traces between pin pads. Most ICs that are susceptible to noise are spec'd with a ground plane under the chip. The oscillator on the DNA board should of had a ground plan under it.

  8. #8
    Insider new ion?'s Avatar
    Join Date
    Feb 2013
    Location
    Victoria, BC
    Posts
    1,296
    What do ya know, I'm learning something.

  9. #9
    Quote Originally Posted by new ion? View Post
    What do ya know, I'm learning something.
    me too, i cant believe how much there is to learn.

  10. #10
    Junior Member
    Join Date
    Mar 2015
    Posts
    18
    Great work, looks fine!

    Maybe some questions/suggestions:
    - RESET is active low. R7 seems to be wrong or should be a capacitor.
    - Decoupling caps (or the lack of it . Use at least one close to ever supply pin of the Atmega. Don't make the same mistage than me... It will probably work without any caps, but there is a risk that it could be unstable.
    - The Atmega has internal switchable pullups for inputs. You don't need R5/6/10/11/12. Just connect the switches/buttons between GND and a input pin of the Atmega.
    - Consider a re-design of the crystal section. See http://www.atmel.com/Images/doc8128.pdf for hints. Again, it probably willl work fine but with the risk of instability.
    - I assume R14/R13 are for voltage measurement of the 9V battery. They draw I=9/(51e3+39e3)=0.0001A=0.1mA. This will empty your battery in less than 3 months. Consider using higher values if the input impedance of the ADC matches.
    - If battery life is an optimisation criteria (aka you don't want to remove the battery after every game), check
    - the quiescent current of the vreg. If too high, consider using another type and an enable logic.
    - the standby/sleep current of the display. If too high, switch it's power with a p-channel mosfet.

Posting Permissions

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