×

SparkFun Electronics will be closed on July 3rd, 2015 in observance of Independence Day. Any orders placed after 2:00pm MT on July 2nd will be shipped out after the weekend. Thanks!

Sembazuru

Member Since: October 17, 2012

Country: United States

  • Ok… Not finding the free time to do this quickly. I think I’ve finally finalized on a schematic (figuring out how to hook up regulators and provide jumpers for the 5V and 3.3V lines to make this board usable with both 5V and 3.3V Pro Minis was the hurdle there).

    Now I need to make sure I have the footprints that I want and layout the board. It’s still a work in progress. I thought I updated the github repo, but checking it from work I don’t see that it is updated. Something to look into tonight…

  • For the timing, I wonder how well either:

    A) Use the Q and /Q (not Q) outputs of a JK flip flop with the J and K inputs held high and a clock ( a single µC I/O pin, a 555 circuit, a UJT oscillator, a fixed oscillator chip, etc.) to create your two phases. Are the two outputs of a JK flip flop coincident enough with their changing state to drive this type of ladder? Or are there weird propagation delays to worry about? (Does the /Q switch after the Q? Is the propagation of Q from 0 to 1 different than the propagation of Q from 1 to 0? etc?)

    B) If you really want to use a µC like an Arduino, instead of using digitalWrite(), resort to direct port writing. To get the fastest frequency output you might need to resort to assembler (either directly or as embedded in C) to write 0b00000001 then 0b00000010 to an I/O port and then loop forever. Make sure to put enough NOPs between the port writes to equal the number of clock cycles the loop will take, and you should have very close to 50% duty cycle. Granted, you won’t be able to use the µC for anything else…

    I’d probably first try A because simply driving two clocks 180-degrees out of phase from each other is a bit of a waste of the power and flexibility of a µC… But, B would probably be faster to prototype.

  • Nice. My brother (who incidentally works for NI) got me the Arduino+Labview bundle (Retired SKU DEV-11225) for Christmas, but I haven’t played with it much. I like what I see with the tutorials, so now I just need to check my parts against the components in this SIK and order the missing ones.

  • That doesn’t help when viewing the pdf schematic on a computer that doesn’t (and won’t) have Eagle installed. I.e. my work computer…

  • If VRAW connects to the input of the 5V regulator, please show it.

    Unless I’m misunderstanding the purpose of the IOREF pin, I thought is was a reference pin for shields to see what the I/O restrictions of the µC is (i.e. to be the bias voltage on the µC side of level shifters). While, yes, the Teensy3.1 is 5V tolerant, it only provides 3.3V on it’s I/O pins as a logic “High”, and most of the older Teensy boards are 3.3V only.

    Granted, I haven’t seen any Arduino shield that puts level shifters on all the I/O pins that it uses with the µC side power connected to the IOREF pin. And, I guess that makes this discussion academic, possibly even pedantic. ;-)

    I understand not connecting HV_AREF to the Teensy for fear of blowing it out. If it isn’t connected to anything else, why use the signal name on the schematic? (If the answer is “why not” then why didn’t you use a signal name on the IOREF pin. Consistency, please.)

  • I’ve gotten started on something like this. See https://github.com/Sembazuru/Pro-Mini-to-UNO for my KiCAD files as they stand. It isn’t complete, and only gets occasional work. I’ll see if I can get it pushed through to Gerbers this weekend.

  • I’m studying the schematic and have two questions… What do the Vin and ARef pins of the Arduino pinouts connect to? I can’t find the other end of the “HV_AREF” and “VRAW” signals.

    Also, the Arduino IOREF pin should probably be connected to “3.3V” just in case someone makes a shield that uses the IOREF pin as it is intended by the Arduino design.

  • The Teensy Arduino adapter is similar to something that I’ve been playing with in my spare time. Basically Arduino shield adapters for the various small arduino-compatible boards. I was starting with the various ‘328 based boards and providing options to either install inefficient (but cheap) linear regulators or Pololu buck/boost modules.

    I just keep getting stuck in over engineering morasses and combating feature creep.

    I’m keeping at it (not really expecting to make any products), mostly to have something to keep practicing at (and playing with new features on daily builds of) KiCAD.

  • I haven’t looked at the SD spec since right around when SDXC was introduced, but IMHO the most important thing to pay attention to is the classification (i.e. SD Spec version). There is the original v1.x just called SD, then there was v2.x called SDHC (SD High Capacity), and finally v3.x called SDXC (SD eXtreme Capacity?). There is actually more difference between SD and SDHC (as the addressing is completely different) than between SDHC and SDXC. This is true at least from the SPI interface (which is how Arduinos communicate to the SD cards).

    I was (at the time) writing assembler code to access SD cards at the byte/block level, similar to how EEPROMs are accessed. The application collected data into a 1Mb (megabit) FIFO and when the half-full interrupt was triggered I would dump 512bytes to the SD card. I had to have two different routines selectable by a flag that I would set when initializing the card. If SD the addressing was by byte number so I would have to increment my write counter by the size of the block (block sizes were variable, but I used 512bytes in my implementation). But for SDHC and higher I would only need to increment my write counter by one for the block number (blocks were fixed at 512bytes). My initialization routine was able to take note of an SDXC card, but I didn’t have to handle them differently than an SDHC. Another part of the initialization determined the card size based on data encoded in one of the card’s registers. (It’s been several years so I don’t remember which one.)

    Almost forgot to mention. The SD cards that I was using didn’t have integral clocks. So if I wasn’t toggling the SCLK line of the SPI interface, no time passed for the SD card. And the only time the SCLK line was toggled was during an actual SPI data transfer, which even for multi-byte transfer occured at short bursts of 8 cycles. At that time I didn’t run across an SD card that was adversely affected by trying to run it too slow. That may have changed with modern high-specification cards. But why would you pay the extra money for an SD card that can run 10 times the speed of the SPI bus on your target microcontroller? The max speed of the SPI bus (or even target speed) is the limiting factor in how fast you can access it.

  • The Arduino Leonardo, Mini, or Due can be used very similarly to those I-PACs, but the I-PACs have the advantage of having all the low-level coding already done for you. Though, I suppose if one is looking forward to the challenge of the low-level coding, that advantage is actually a disadvantage. ;-)

    Though, with some cleverness, by using avrdude directly you could reprogram an Arduino directly from the r-pi with cusomized key-mappings for each different game launched.

    As with skinning cats, there are several ways to do this. :-D