Jump to content

Paul Stoffregen

Active Members
  • Posts

    74
  • Joined

  • Last visited

Everything posted by Paul Stoffregen

  1. Hi, Paul here.... the guy who designed Teensy and wrote Teensyduino. Teensy is based on the Atmel AVR ATMEGA32U4 microcontroller, which has a fully generic (up to 7 endpoints) USB device controller built in. So in theory, you could program it to be virtually anything. In practice, writing the USB driver code is a LOT of work, starting with the 600 page USB spec and many other necessary USB documents (the 600 page spec is only the basic stuff, not how any particular device actually uses it...) Only about half a dozen people appear to have ever written such code for these AVR chips, and only 3 of these code bases in widespread use: Atmel's sample code written by some unrecognized author, my code, and Dean Camera's LUFA library. Atmel's code isn't worth considering (and Atmel has hired Dean recently). Dean and I have nearly opposite coding styles, where Dean uses lots of C structures and syntax and very modularized style, and attempts to craft interfaces that expose all possible options with maximum flexibility. That's ideal for large projects and experienced C programmers. My style involves minimal amount of code without lots of special syntax or abstractions, and simplified interfaces that expose only the most commonly needed functions. My style works well for Arduino, and I've gone to great lengths to give you the simplest, most Arduino-like experience possible, but without being limited to only serial COM ports as Arduino is. If you want access to a lot more features, Dean's code is the way to go. Or write you own! It could be said that Teensy is natively a HID device, because it appears as HID when you're programming it with the Teensy Loader program. However, it is not a HID keyboard or mouse, but rather a "vendor specific" HID device. The "documentation" is embedded within the open source code command line tools, which it at this page: http://www.pjrc.com/teensy/loader_cli.html But what matters is the type of device Teensy is when your code runs, and that's up to you. Most people program Teensy using Arduino, of course with the Teensyduino add-on package installed. The type of USB device Teensy will become depends on the setting you've selected in the Tools > USB Type menu. The current version of Teensyduino provides five choices: 1: Serial 2: Keyboard + Mouse + Joystick 3: Disk(Internal) + Keyboard 4: Disk(SD Card) + Keyboard 5: MIDI Really, it's 4 USB choices, since 3 and 4 are identical, except for which media is used to implement the disk. The menu defaults to Serial, because that's what Arduino is. The MIDI type, and Joystick in #2, are relatively new. If you're running an old version of Teensyduino, the latest gives you more options. :-) Over time, I'll probably add a few more choices to this menu. But that is a slow process. I've still got some unfinished business in the disk types, to facilitate sharing the media between the PC and your own code, which might want to read data the PC has stored, or write data for the PC to later see. If you use my C-based examples, there's also a Raw HID program, which is intended for building custom USB projects that work together with only your own custom written application. That too is on my to-do list to expand someday. But much of my coding time ends up going to porting various Arduino libraries. So much code to write... never enough time.... If you use Dean Camera's LUFA code, which is only C-based (doesn't work with Arduino), there are a few other choices, like a RNDIS-based network interface. So for the disk type, both Teensyduino and LUFA support USB disk types. To be perfectly honest, the disk type in Teensyduino is still under construction. 0.96(beta) adds an API for managing the PC's access to the media, but it isn't documented (other than the source code, which is in hardware/teensy/cores inside Arduino). It still has bugs, which is why I haven't documented it yet. I'll make it work well eventually. That API, and really everything about Teensyduino, is intended to facilitate building electronic projects. Examples might be a temperature logger, which records temperature data and the PC can later read it. Or perhaps a simple robotic machine controller, where the PC might write a file with instructions on how to move the motors. If you're building those sorts of things, I want to help you. If your aim is "security" related, especially techniques to analyze or compromise systems, I will neither help nor hinder. But I hope you'll carefully consider the legal and ethical ramifications of any such work, and always act responsibly. Hopefully this long-winded post at least helps clear up any questions about what type of USB device Teensy really is?
  2. Has anyone found a very compact off-the-shelf Mini-B to A adaptor? I get this question sometimes, and it'd be nice to know if are any readily available that are much smaller than the usual.
  3. Opps, yeah, I missed that one. I just added it and uploaded a new copy.
  4. Good to hear it's working. Thanks. It's really a huge help. It should also be able to type all those non-US characters which require AltGr or first pressing the deadkeys. Well, at least all of them on the German keyboard. Some keyboards like Finnish Multilingual have massive numbers of very special glyphs. So far, I've only coded unicode-to-keystroke for ASCII, Latin-1 and the Euro symbol.
  5. Thanks. I actually did quite a bit of experimentation and found code 100. Well, I hope anyway. If not, well, those characters normally from that key between the left shift and the Y key will be wrong. On keyboards made in the USA, they don't put a key there at all. The left shift is wider and the Z key is right next to it. Z and Y are swapped from US to German layouts, so imagine no key between your Y key and shift. That's how they are here, so that 1 extra key has been a real mystery. Well, also, every layout diagram shows a key directly above Enter on US layouts, but it's to the left of Enter on non-US keyboards. Hopefully it's the same code? If some characters from that key next to Enter are wrong, well, that's the one other place I had to do some guesswork. I configured a Windows XP test machine for German keyboard and got most characters correct typing into Notepad, so I think this code is pretty close. I created the entire layout mapping manually, so there's probably a key or two I might have done incorrectly....
  6. Here's an alpha test version with international keyboard support. It also has a MIDI USB type. Linux only so far. I'll port to Mac and Windows in a couple weeks. Of course, devices you create in Linux should work when plugged into PCs with Windows or Macs, but right now this alpha code only supports building them on Linux. http://www.pjrc.com/teensy/beta/teensyduino To change the keyboard type, look for the file hardware/teensy/cores/teensy/keylayouts.h. Just uncomment the one you want. So far, I've done US-English, US-Intl, German and Canadian French. More will be added soon. Eventually keyboard layout will be selected from a menu. edit: international keyboard only works on Keyboard+Mouse type. The Disk+Keyboard types still use the old code. This turned out to be not-so-simple, requiring a UTF8 parser and deadkey sequence layer, and so far I'm building the layout definitions manually which takes forever and probably has a few random errors. If you're in Germany or Quebec, please give this a try and let me know if it works or not.
  7. I am working on a keyboard layout layer, which will eventually be selected from a Tools > Keyboard Layout menu. I hope to make an alpha test release in about 1 week, which will not have the menu but you can change the layout by editing a file. So far, I've done US-English, US-International and German. None are tested yet. I could REALLY use your help now with one a little question. I need to know which codes are '<' and '#' when the German layout/locale is selected. For example, if you were to do: for (int i=4; i&lt;64; i++) { Keyboard.print(i); Keyboard.set_modifier(0); Keyboard.set_key1(i); Keyboard.send_now(); Keyboard.set_key1(0); Keyboard.send_now(); delay(2500); } My best guess is they might be 49 for '#' and 50 for '<', but I can't find any really solid documentation about these 2 keys. If you could run this test and report back for sure which 2 codes are those 2 keys, it would really help me now. In about a week I should have something new that might fix all this, and later it'll even be nicely selectable from a menu. I'm also working on some other new stuff... right now, adding USB MIDI type. :)
  8. I'd like to add a "Keyboard Layout" option in the next version of Teensyduino. It would appear in the Tools menu immediately below the "USB Type" and be enabled if you selected a USB type which includes Keyboard. I've found several pictures that show the various layouts, but nowhere have I been able to find solid specs on the actual key codes (in terms of HID usage tables, not legacy PC stuff) which different keyboard layouts actually send. Does anyone know where I might find these? Or is there somewhere (hopefully cheap) where I can buy various non-US keyboards from within the USA? Or does anyone have an extra USB keyboard they could send to me? Maybe I need to start a wish list for all the various layouts?
  9. I recently added a page about this. http://www.pjrc.com/teensy/external_power.html
  10. You can't use programs like Hyperterminal or Zterm that are designed to talk with serial ports, because it's not a serial device. In theory, you could write a terminal emulator that does HID communication, but that would be a LOT of work!!! The HID API is completely different on each operating system too. But I've already done the low-level part for you..... Inside your arduino directory (on a mac, use option-click and "show package contents"), there's a tiny program called teensy_gateway. It talks HID protocol to the teensy and makes that communication available on TCP port 28541. When you're using the Serial Monitor in Arduino with this mode, it runs the teensy_gateway and connects to port 28541. If that program is still running, you could just use: telnet 127.0.0.1 28541 If you can't connect, just open a command prompt and run teensy_gateway, and then telnet should be able to connect (as long as teensy_gateway remains running). Of course, the easiest thing to do is just click the "Serial Monitor" button inside Arduino. The new one in 0019 even has a button to turn scrolling on/off, but admittedly it's still feature-poor compared to most terminal emulators. If you have one that supports telnet in addition to serial connections, you can use that with teensy_gateway.
  11. Just click on the serial monitor button. Don't worry about selecting a serial port, because there isn't any in this mode. It will "just work" (because I implemented a communication channel with a custom HID interface and hacked the serial monitor to use it in this mode)
  12. Yes http://www.pjrc.com/teensy/td_libs_LiquidCrystal.html
  13. The main new features are USB Serial driver install in the main Teensyduino installer, and simulating the Arduino reset behavior when launching the serial monitor window. Some really broken stuff in 0016 was fixed.... since nobody's complained, maybe it's a good bet nobody's actually using 0016. http://www.pjrc.com/teensy/experimental.html
  14. Try compiling for a regular Arduino. Just select it from the Tools > Boards menu, and click verify. If that compiles, please let me know. In fact, if you can, just zip up your entire arduino directory and send it to me. That might be too big of a file? If you get the same error when compiling for Arduino, then it's probably a bug in the library or something messed up with your arduino install. You could download a fresh copy of the arduino software and try that.
  15. That's what it should do, exactly the same as a USB card reader when there's no media present.
  16. Very likely a loose or unconnected wire. First, only 6 pins are needed: +5, gnd, miso, mosi, sclk, ss. So rip out those other 4 wires that do nothing, assuming you're working on that breadboard. Grab a voltmeter. Set it to a range that can measure 5 volts DC (eg, if there's 2, 20, 200, you'd use 20). Use a clip lead to attach the black wire to the USB metal shell, which is ground. First, measure the voltage on +5 and gnd at the SD adaptor. Try to touch the side of the solder joint close to the actual pad on the PCB, not the pin in the center. +5 should measure about +5 volts. A little lower is fine, many PCs run about 4.8, and if you're using a hub it can be as low as 4.4. Anything over 4 volts is probably fine, but do also measure over on the Teensy and make sure they are the same. Measure the ground pin too. This probably sounds redundant, but if ground isn't connected nothing will work. Observe how your meter responds with the red wire in your hand. You can touch it if necessary to get something to happen. When you touch the ground pin, you are looking for a "solid zero", which should look distinctly different from the zero that fluctuates a bit on its own or when you touch the wire. Repeat for the signals. For MISO, you should see 3.3 volts when there's no activity to the card, or no card inserted. For the other 3, use the blink example, but change the pin number to the signal you want to test. Adjust the times if your meter responds slowly. Measure the voltage on the actual pin and watch for it to "blink". Measure the other voltages and make sure they do not "blink". Again, it's helpful to measure on the Teensy side and on the SD side. Since they're connected by a wire, they should be identical. You'll probably find one that isn't.
  17. I wrote the Teensyduino code to (hopefully) work with any SD card. If you find one that does not work, but others do (eg, your hardware is confirmed working with other cards), please contact me directly at paul at pjrc dot com and I will swap a known-to-work card of similar or better specs for yours... and of course I'll (eventually) use your card for testing compatibility of future releases. My current collection spans 16 megs to 4 gigs, both version 1 and 2 cards, and both SD and SDHC in version 2. Teensyduino has been tested with all those cards.
  18. Here's the list of changes in 0019: ARDUINO 0019 [core / libraries] * Added aliases for the analog input pins: A0, A1, etc. http://code.google.com/p/arduino/issues/detail?id=244 * Added a String class. * Added an SPI library (by Christian Maglie). http://code.google.com/p/arduino/issues/detail?id=240 * Revised Ethernet library (by Christian Maglie). * Added a shiftIn() function (from Wiring). http://code.google.com/p/arduino/issues/detail?id=280 * Updated version of Firmata supports Mega and capability querying. * More accurate delay() function from BenF. http://code.google.com/p/arduino/issues/detail?id=237 * Re-enabling PWM after tone() ends. http://code.google.com/p/arduino/issues/detail?id=228 * Added Serial.peek() method. http://code.google.com/p/arduino/issues/detail?id=270 * Added Stream base class to Serial object (w/ available(), read() and the write(), print(), and println() functions from the Print class). http://code.google.com/p/arduino/issues/detail?id=60 * Disabling interrupts while digitalWrite() and pinMode() write to pins. http://code.google.com/p/arduino/issues/detail?id=146 * Replacing INTERNAL analog reference with INTERNAL1V1 AND INTERNAL2V56 on the Arduino Mega. http://code.google.com/p/arduino/issues/detail?id=194 [environment] * Added Arduino Fio to the boards menu. * Added Arduino Pro and Pro Mini (5V / 16 MHz) to the boards menu. http://code.google.com/p/arduino/issues/detail?id=81 * Synchronized with the Processing 1.1 code base, bringing various changes. * Modified the parsing of avr-gcc / avr-g++ output and error messages. * Toggling RTS on upload for auto-reset with FTDI cables on Linux. http://code.google.com/p/arduino/issues/detail?id=309 * Adding control over scrolling in serial monitor. http://code.google.com/p/arduino/issues/detail?id=97 * Added drop-down for selecting line endings to the serial monitor. http://code.google.com/p/arduino/issues/detail?id=119 * Fixed problem with tabs of the same name but different extensions. http://code.google.com/p/arduino/issues/detail?id=191 * Allowing third-party hardware platforms to reference programmers defined in other platforms. http://code.google.com/p/arduino/issues/detail?id=283 [examples] * Re-organized and numbered for easier access and better progression.
  19. Arduino 0019 is getting very close. A first release candidate recently appeared. Here's the files: Mac OS X: http://arduino.googlecode.com/files/arduino-0019-rc1.dmg Windows: http://arduino.googlecode.com/files/arduino-0019-rc1.zip Linux (32-bit): http://arduino.googlecode.com/files/arduino-0019-rc1.tgz Here's an updated Teensyduino to support 0019-rc1: Teensyduino: http://www.pjrc.com/teensy/experimental.html I've done some quick testing on Linux, Mac and Windows XP and everything seems to work. Haven't tried Win 7 yet... A long-standing and annoying but harmless bug has been occasional false warnings that Teensy Loader was busy, when in fact it programmed the board perfectly. I made some changes to the way the reboot request is sent which might finally fix this. If you give this latest code a try, especially on any version of Windows, please be on the watch for that false warning and let me know if it's still coming up.
  20. I'm looking for a few good Keyboard and Mouse examples to include in the upcoming Teensyduino ...to be released soon after Arduino 0019 comes out, which ought to be "real soon now". Of course, any examples contributed will give full credit to their authors. They will appear under in the menus, File > Examples > Teensy > (sub-category)
  21. Soldering irons come in 3 fundamentally different types, depending on how they regulate temperature. The cheapest irons don't regulate at all, other than having limited power that's always on. Often they are specified by their heater's power level, like 20 watts. They heat up slowly and the eventual temperature is only whatever equilibrium is reached with the room's temperature and air flow. Usually they get too hot, and as you solder they get too cold, until they slowly heat back up again. Better irons switch the heater on and off using a sensor mounted in the iron, usually close to where the tip attaches. Many are electronic and there's an dial or buttons to adjust the temperature. Some have a magnetic switch, where the tip usually has a 6, 7 or 8 stamped on the bottom (for 600, 700 or 800 degrees F) based on how its magnetic properties change. That may seem primitive compared to an electronic sensor, but it actually works quite well since the metal of the tip is more directly involved in the sensing, causing the heater to turn back on sooner as it cools when you apply room temperature solder. Regulated irons usually have powerful heaters, like 40 to 60 watts or more, so they heat up faster and recover faster as you're soldering, but never overheat. The best and most expensive irons have complex tips with a thermocouple right inside the tip (making the tips also quite expensive). Unless you have the most expensive type, it's advantageous to use the largest tip that will work for your job. The larger tips simply hold more heat because they physically have more metal, so as you apply the solder the temperature stays more stable. A tiny tip might seem to enable you to work with more precision, but it's a net loss because you won't have a stable temperature. The key to soldering tiny parts is magnification and bright lighting! When soldering, the MOST IMPORTANT point is to fully heat both surfaces and the solder to a uniform temperature. The ABSOLUTE WORST MISTAKE, which is very common with hobbyists, is quickly touching both the iron and solder to the joint and then withdrawing them both at the same instant. Always withdraw the solder first. You should always leave the iron in contact for another 1/2 to 1 second. That extra second is critical. When the solder is still being applied, part of what will become the final joint is too cold. It has solid, not-melted solder in contact, so it can't possibly be at the correct temperature. That extra second allows all the solder and both surfaces to fully heat to whatever temperature the iron achieves, which hopefully is still hot enough after losing so much just to melt the solder. If you use the largest tip (lowest temperature loss while soldering) that can do the job and you make sure to spend that extra second after withdrawing the solder, you'll usually see very good solder joints. If you're using a low power, under $10 cheap Radio Shack iron, allow a little time for it to heat back up between each soldering. It's a painfully slow process, but still a lot less painful than trying to debug electronics with flakey solder joints. The other thing that matters greatly, if you have enough heat and get all the metals up to the same uniform temperature, is clean solderable metals. Pretty much all electronic parts are tin plated for best soldering, but bare copper (eg, many wires) will corrode rapidly. The flux is a chemical that's inside the solder. Afterwards, you'll notice the residue on the board. It cleans the corrosion from the metal while you're soldering. If your metals aren't perfectly (and we live on a planet with lots of oxygen which pretty much assures there will be some corrosion), you absolutely must have flux... and there isn't much inside the solder. To make best use of the flux, you must apply the iron to the area, and then apply the solder. As the solder melts, the flux will spill all over the nearby area. The smoke you see is the flux burning, which is BAD. You don't want to waste the flux into smoke. The WORST thing you can do is apply the solder to the iron and watch the smoke roll off while all the flux burns away, and then try to touch the metal surfaces with the melted solder. There won't be any flux left. The solder will barely "stick", because even if the metal looked clean there's a microscopic layer of corrosion between the metal and your solder. You want to make best use of the flux to clean away that corrosion, which means touching the solder to that area so as it melts the flux will spill all over and clean the 2 metal surfaces you're trying to join. You can get flux separately, usually in liquid form. Often it's sold in a "pen" which dispenses a tiny amount. More flux will help greatly on difficult soldering. It's best to get the same type of flux as is in your solder, if you can. Beware of water soluble flux, like the Kester 300 series. It works extremely well, but you MUST wash the finished product with water to remove it. It's highly corrosive and will destroy your work it left on long term. An hour is no big deal, so there no urgent rush to get to the sink. After washing, for many types of soldering it's necessary to bake the entire product to remove water than lingers in tiny crevices. 10 minutes in an oven at 150 to 170 F works pretty well. Rosin fluxes can be left on the board. Kester 44 (60-40 lead based solder) is generally the easiest and best for prototyping. One last thing I should mention is the concern about too much heat. Certainly there is a point where too much will cause damage. However, it's a LOT more than you might think. Long ago, like in the 60s and 70s, when some transistors and diodes were made from germanium instead of silicon, heat from soldering could destroy the parts. It was common to clip a heatsink on component leads, and there's still lingering lore about this ancient practice which hasn't been necessary for decades! How much heat is too much can be hard to judge. The biggest concern with manual soldering is physical damage, especially if the parts can move while you're working. The heat can weaken the bond between copper and fiberglass on a circuit board, or melt the plastic insulation on wire (unless you're using the spendy Teflon insulated wire, which is awesome stuff for prototyping). Taking measures to prevent movement of either surface really helps. Pretty much all modern parts can withstand 30 seconds of soldering, though the temperatures guaranteed are pretty low. You can't work as such low temperatures with cheap soldering irons, even with a giant tip, because the temperature just isn't stable when you apply solid solder and drain way heat to melt it. Most manufacturing processes bake the entire circuit board for several minutes at a temperature slightly below the melting point of the solder, and then heat the entire board above melting for 20 to 30 seconds. The key point to remember is they subject everything to elevated temperature, not quite enough to melt the solder, for a VERY LONG TIME, at least a few minutes. All modern parts are designed for this. If you have a regulated iron, it's best to set for 600 degrees F and use the largest tip you can. Get everything heated to a uniform temperature, allowing an extra second, and make best use of the flux, and focus any concern about overheating to keeping the parts still while you're working. If you follow this advise above, you'll get very good results.
  22. Arduino 0019 looks like it's about to release, and when it does I'll need to make a new Teensyduino release within a few days. My question is if 0.9 is ready to be called stable and replace 0.8. About half my planned features moved to the new feature, thought the list approximately doubled since I started 0.9.... software!!! If you've used 0.9, was it stable for you? I'm seriously leaning towards just discontinuing 0.8.
  23. Ok, it looks like you've completed adding Teensyduino to Arduino. That means you now have software that is capable of producing programs for Teensy, so your next step is to actually load the code for a tiny program and try compiling and getting it into your Teensy. Something to keep in mind is Teensy is just a tiny little computer. Computers do exactly what you tell them to do, which isn't necessarily what you want them to do. So far, you've loaded software on your computer, and that software is capable of making software for Teensy. As far as the Teensy is concerned, you haven't told it to do ANYTHING. Pushing the button puts it into programming mode, and the Teensy Loader lets you download a HEX file. Now it's time to actually make your own HEX file. THAT is what you're trying to do with Arduino. You'll probably load the blink example (eg, menu: File > Examples > Digitial > Blink). Chance the LED number to 11 (refer to the card that came with Teensy to see the LED is connected to pin 11). When you click the verify button in Arduino (the first one on the blue toolbar), after Arduino has produced the HEX file, you should see the Teensy Loader shows the new filename automatically (on the button line of its tiny window... Teensyduino sets up communication between the two programs, so you don't have to manually use File > Open in Teensy Loader, it just automatically opens the new HEX file). Only when you have created your own HEX file, then you should press the pushbutton on Teensy. That communication channel also clicks the "Auto" mode button for you, so when you press the pushbutton your freshly made HEX file will be programmed and run on your Teensy. Ultimately, Teensy will do exactly what you tell it to do. Ultimately, you must take control and command it to do your bidding (and I do hope you deploy any application than controls a PC in a responsible way, but ultimately that's your business). There are certainly libraries and bits of code people have published than can help, much like how a nice clip art or icon library can help you compose a pretty document or web page. But all the examples and tutorials (and lengthy forum posts like this one) and helpful code to copy-n-paste there doesn't replace the need for YOU to take control of things!
  24. Sounds you've completing step #2 of the getting started section? You could go on to steps #3 and #4, which admittedly were written before Teensyduino existed and are in need of some updates (to mention Arduino as an alternate path). Or you could download Arduino and Teensyduino, install them, and try the Teensyduino tutorial. Those tutorials will walk you though some of the more conventional ways to use Teensy. As for controlling a PC, with Arduino you'd probably want to look at the info on this page (perhaps after completing tutorial #1): http://www.pjrc.com/teensy/td_keyboard.html To be honest, when I created Teensy I imaged people would use HID to do things like entering sensor measurements into web forms or spreadsheets. Of course, it's completely up to you what you do with Teensy, but if you pursue "hacking" style control of PCs, please I hope you will do so responsibly.
×
×
  • Create New...