I2C Intelligent Peripherals for Prop using cheap ATtiny85/84 (8/14pin) micros
Cluso99
Posts: 18,069
A few of us have advocated using a cheap micro such as a PIC, Freescale or AVR for simple expansions for the prop.
Jazzed has now done this using an ATTiny85 - see the I2C Keyboard/Mouse thread http://forums.parallax.com/showthread.php?t=124704.
The ATTiny is more like programming a prop than either the PIC or MC9RS08. It has 4x10b ADC ports.
Using an I2C interface has the advantage of sharing the EEPROM pins and most likely code providing timing is not a primary issue. Bill's designs are already using a number of I2C chips.
I had just settled on using the cheaper MC9(R)S08 to interface 2 NES controllers to a single serial pin. It is not too late for me to change to an ATTiny instead.
So, my question is... Should we try and standardise and use a slightly more expensive ATTiny85 (8 pin version) or the ATtiny84 (14 pin version). Both have 8KB, 10b ADC, and are available in SOIC and DIP format?
Jazzed has now done this using an ATTiny85 - see the I2C Keyboard/Mouse thread http://forums.parallax.com/showthread.php?t=124704.
The ATTiny is more like programming a prop than either the PIC or MC9RS08. It has 4x10b ADC ports.
Using an I2C interface has the advantage of sharing the EEPROM pins and most likely code providing timing is not a primary issue. Bill's designs are already using a number of I2C chips.
I had just settled on using the cheaper MC9(R)S08 to interface 2 NES controllers to a single serial pin. It is not too late for me to change to an ATTiny instead.
So, my question is... Should we try and standardise and use a slightly more expensive ATTiny85 (8 pin version) or the ATtiny84 (14 pin version). Both have 8KB, 10b ADC, and are available in SOIC and DIP format?
Comments
Personally, I will be making multiple I2C modules, using whichever microcontroller is most suitable - however I suggest the following pinout standards that I use:
EDIT: I am *NOT* trying to hijack your thread, but I thought this would be a great place to post suggested standardized I/O pinouts.
For my boards, I have standardized on the following:
I2C 4 pin header, male on processor boards, .1" spacing
pin 1: +3.3V
pin 2: SDA
pin 3: SCL
pin 4: GND
Currently on PropCade, soon on more
H-COMM 5 pin header, male on processor boards, .1" spacing, pins 1-4 same as PropPlug
pin 1: GND
pin 2: /RESET
pin 3: <TX
pin 4: >RX
pin 5: +3.3V
Currently available modules: SerPlug and 485Plug, already on all my processor boards
While I have not tested it, I think Ybox2 uses the same pinout for its programming port!
EXP/ALT 10 pin header, female on processor boards, male on modules, .1" spacing
pin 1: +3.3V
pin 2: GND
pin 3: Px+0
pin 4: Px+1
pin 5: Px+2
pin 6: Px+3
pin 7: Px+4
pin 8: Px+5
pin 9: Px+6
pin 10: Px+7
Where Px is the starting propeller pin, one of P0, P8, P16, P24
Some of my boards support an optional "pin 11: +5V" suggested by Sapieha
Currently on Morpheus, Propteus, Proteus, more soon
"EXP" sockets go directly to propeller pins
"ALT" sockets go to expanded I/O pins
I will soon have approx. 10 modules available for EXP sockets, and about half will also work in ALT sockets.
I encourage everyone to adopt the I2C/H-COMM/EXP pinouts, as then you can use any of my H-COMM, I2C and EXP/ALT modules - and if you make modules with the same pinouts, I (and my customers) can use them too!
I considered using the PMOD pinout, but ended up with the above for EXP/ALT as it is compatible with ProtoBoard (serial/usb) and uController's boards.
For some of the stuff I'm working on I have been running out of cogs and am moving to a multi-prop architecture. Some stuff warrants cogs (eg 24 channel dac) but some stuff really doesn't (like monitoring for some button presses). I would like little slave processors to hand off dinky tasks to.
(typically the only sort of ATxxxxx chips I do not seem to have already is the tiny85, just 45s)
I think the atTiny24/44/84 in 14 pin PDIP/SOIC (QFN20) would be better to use though. Note that the first number (2 in atTiny24) indicates the KBytes of flash available. Thus atTiny85 has 8KB of flash, and atTiny24 has 2KB of flash. So, the parts will be referred to here as atTinyX4 and atTinyX5.
Here are some considerations for using atTinyX4 instead of atTinyX5.
Disadvantages of atTinyX5:
provides 4 pins besides SCL/SDA, but only 3 pins can be used without blowing the RESET fuse pin which makes the device unusable again without using a high voltage programmer - atTiny24 does not have this problem.
shares I2C and SPI interface pins which can make in-circuit programming difficult - atTinyX4 does not have this problem.
shares the AREF (ADC analog voltage reference) with an I2C pin - atTinyX4 does not have this problem.
Using atTinyX4:
The atTinyX4 costs marginally more than the atTinyX5 and has a bigger package for DIP, but has more pins available and fewer shortcomings.
Mouser quotes atTiny24 at $2.03 each and $1.53 for 10 units. Prices go higher for atTiny44/84. It is amazing to me how much code can be packed into a 2KB AVR flash.
Also, since the atTinyX4 can be more easily re-programmed in-circuit the SOIC chip can be used which is about the same size as a DIP8. The debugWire interface on the RESET pin can not be used for programming.
Some things not mentioned regarding the ADC in these parts is the ability to use ADC differential input mode measurements and the ability to set an analog voltage reference
The only problem with I2C is device addressing. On the PS2I2C controller, I'm using a promiscuous protocol to set the device IDs. If the controller is the only device on the bus not using $A0..$AF, it works fine. If there is more than one device that wants to use the protocol, there's a problem. The official solution is to pay Phillips 1500 euro for an address (probably a difficult 10 bit address). A pseudo-solution would be to dedicate some input pins on the controller to set the address range that would allow the promiscuous protocol to work for a device. Of course having source code allows the developer to specify any device ID they want to use for their own consumption.
One rarely mentioned advantage of using I2C is that if done right, is that it doesn't matter if the part is powered by 3.3VDC or 5VDC as long as the I2C pull ups on both SDA/SCL are connected to 3.3VDC.
Cheers.
--Steve
Ultimately several options are needed (9s08 for production cost), but it does make sense to focus around one device first to really get things moving. Attiny makes sense to me.
The voltage should be selectable by the user some way. If I2C is done right, you can use a 5VDC powered part with a 3.3V Propeller. It would be very nice for any connector to have a reset pin, thus I think having an extended H COMM 5 connector would be best:
6 PIN COMM Connector allowing more flexibility:
pin 1: GND
pin 2: /RESET (required pin; optional TTL level connection 0.7-2.4)
pin 3: <TX (or SCL: output from master)
pin 4: >RX (or SDA: bidirectional)
pin 5: +3.3VDC (required pin; optional connection)
pin 6: +5.0VDC (required pin; optional connection)
I will be using the TI430 value line for cheap ($0.45) interface chips. They have an internal calibrated clock, and draw no power to speak of. I have an application where I need hundreds on a distributed bus (not I2C in that case), so will be placing an order for 1000 pieces soon.
Looks like a great chip to me, others may also find it interesting. Keyboard/mouse etc. should be real easy for it.
Cheers,
Peter (pjv)
Great suggestion, I will add an optional 6th +5V pin on future generation boards.
I have used both SerPlug and 485Plug with 5V microcontrollers, I just replaced the SP3232 with a standard MAX232, and the MAX3485 with the SP485, and fed 5V to the 3.3V pin
Another way to do this would be to add a 3 pin select header which selects 3.3V or 5V for pin 5.
The nice thing is that the 6 pin is downward compatible with the 5 pin, which in turn is downward compatible with the 4 pin PropPlug.
Re the I2C connector - for externally powered I2C modules really only the two signals and ground are required, and for 5V links 1k resistors in-line with SDA and SCL should keep things safe.
I2C requires two pins. That's a lot, when you're using an 8-pin micro as the peripheral. Half-duplex asynchronous serial I/O requires only one pin with a pullup. By designing a peripheral command set having commands beginning with odd-numbered ASCII, a non-crystal-regulated micro can easily time the start bit to synchronize to the incoming baudrate. Such a peripheral can also coexist on an I2C bus using SCL (with a pullup) as the serial I/O line, as long as SDA remains pulled high to avoid a start condition.
As an alternative, it's also very easy to implement a One-Wire-like protocol in small micros like the ATTiny series.
Moreover, three-pin servo-type headers are nearly universal, and it's easy to obtain servo extension cables to connect to them. Pre-made four-pin cables are not nearly so ubiquitous.
'Just a thought...
-Phil
However I will still support the interfaces I outlined above, as there are many nice I2C chips out there
I just wish the 20 pin parts would show up!
Is there a standard you have followed when implementing your 'Pals'? There is 1-wire, and Uni-IO for memory chips that I am aware of. Having a standard might make this form easier to adopt
I believe Bill's point about using the part that makes sense is really what drives decisions about the part to use. Having a cheap Propeller that can do specialized analog would be great for example because most people who come here already know it and may not know the alternatives. Parallax sells a board with an AVR on it, so I guess we're safe talking about that
Regarding a half-duplex serial connection: I would be more open to a non I2C solution for intelligent peripheral interconnect if Propeller didn't waste 2 pins on it. Still, one could force one of the I2C pins high always and use the other pin for 1 wire communications.
I mentioned device IDs in another post above. I forgot that all the micros mentioned so far have EEPROM on board. One approach that would allow any ID that the user chooses without exception (beyond I2C spec limits) on a device that ships with closed source is to use a pin for the ID program enable.
The way ID programming works would be to use a pull-up for disable and jumper short to ground to enable ID programming. With ID programming enabled, the first address the device receives would be stored in memory EEPROM, then at normal reset the ID will be read and used. I have code for this already, but decided to use the simpler but non-universal method I outlined before.
The SoundPAL and ColorPAL both use asynchronous half-duplex serial I/O. The ColorPALs are networkable and can be parallelled. Here's how the networking works:
as a “network” address. Multiple ColorPALs can be paralleled and addressed individually in Direct mode.
Each ColorPAL can be assigned an eight-bit unit number, which is saved at EEPROM location 3F and
loaded when the ColorPAL resets. When a non-zero network address is received in Direct mode via the +
command, it is ANDed with the ColorPAL’s unit number. If the result is zero, the ColorPAL will ignore
further direct commands until either a 00 address or one which, when ANDed to its unit number, yields a
non-zero value. The 00 address can thus be thought of as a broadcast address, to which all ColorPALs
will respond. A new, unprogrammed ColorPAL comes with a unit number of 00, which means it will
respond only to address 00.
To change a ColorPAL’s unit number, simply create a one-instruction program, with the instruction being
one that takes a number (i.e. p or t), and save it to EEPROM location 3E. That will place the number in
location 3F and will be effective after the next and subsequent resets. Here’s an example:
This programs the ColorPAL to have unit number 03 (%00000011), which means it will respond to any
address with one or both of its least-significant bits set.
IMPORTANT: Network addressing works only in Direct mode. It cannot be used to select which of two
or more ColorPALs already running programs gets to output color data, for example. It can be used,
however, to select which of several units can begin code execution.
When a ColorPAL comes out of reset, any commands sent without prepending an address are assumed to
be broadcast and won’t be blocked. That way, it’s easy simply to ignore the networking feature if you
don’t want to use it.
The SoundPAL is not networkable.
-Phil
Small micro choices
I will look at the TI430.
I had decided on the MC9RS08KA1 (1Kx8 memory)$0.42/100 in tubes from DigiKey. Also, the MC9S08QD4 (4Kx8) with 4x10b ADC $0.73/100 and is pin compatible. The MC9S08QG4 (4Kx8) is $0.82/100 in SOIC8 and 4x10b ADC and $0.91/100 in TSSOP16 (same size as the SOIC8) with 8x10b ADC.
The MC9 series has 4 I/O and 1 I/P and 1 O/P for SOIC8/DIP8. Unfortunately the power and gnd pins are not the same as the ATTiny :mad:
It would be really nice if we could mostly use the same micro or micro family for obvious reasons such as partial code re-use.
For my apps I had thought I would use a single pin in output only mode to send serial data only when something changes - take the NES controller as an example - only transmit when the buttons change as this makes the software simpler on the prop end. I had a spare pin on the TV/Stereo/Keyboard pcb because the fourth pin for TV is rarely used.
Phil is correct in that we can still use the SDA pin while the SCL pin is held or pulled high.
Expansion Connector
I targetted the PMOD style connector because it is a common connector and there are plenty of cheap pcbs available. I had previously layed a pcb using the alternative single row (which comes from the ProtoBoard) 10pin connector with +5V option as an 11th pin. It is not a big deal to change my pcb as I have not sent it to manufacturing yet.
Bill, convince me some more please... I really like the PMOD connection. However, I also like the single row as well, but it must have 5V too. Other comments please...
Cable Connectors
I have sourced some cheap connector shells and pins for 2,3,4 & 6 way pin stakes with the insert pins (terminals) for both male and female. AWG#22-#28 wire can be used to make cables. I will be offering these parts quite cheaply as I had to buy a large qty. They should make excellent cheap cables for what we want. I can get the 10/11/12 shells too if need be.
-Phil
-Phil
Thanks for explaining your scheme. Halving the pins required is certainly attractive, given we're always pushing up against pin count barriers. And being able to re-use SCL is a bonus.
I'm just trying to get my head around the pullup thing. The servo headers usually use a 5v supply, correct? So the Attiny would presumably run from 5v. The SCL normally pulls up to 3v3 (if pullup is present at all), so if you have an SCL bus with I2C devices on it, each 'PAL presumably needs its own series resistor so it can't apply 5V directly.
Another question is does the value of the pullup matter? I've seen 2k -> 10k used for I2C pullups.
BTW, when pulled up to 5V on a Prop circuit, the "high" level will be more like 3.9V, due to the Prop's protection diodes. The ATTiny13's input high voltage minimum is 0.6 * Vdd, or 3.0V with a 5V supply, which provides an ample margin for the 3.9V high.
Finally, it should be possible to program the AVR to determine whether an external pull-up is being used and to assert its internal pull-up if not. Just pull the pin down and let it go. If it doesn't immediately settle high, the program will know to assert the on-chip pull-up.
-Phil
For a lot of my original tasks I used the Silabs parts as they are fast 8051 based micros and very easy to program from the Prop although they aren't the cheapest part around. Bear in mind that with the different micros considered that even ones with a single wire debug/programming pin still need a separate Prop pin to control the reset line which is also part of the interface. On the MC9S parts it's needed to startup the chip in application or debug mode. With the Silabs parts it is used to also clock the debug data.
For the current round of projects I am looking at using the LPC11xx family such as the LPC1111FHN33/101,5 which costs less than a $1 in 100 quantities from Mouser and only $1.30 in 1 offs. Why? because it's a fast 32-bit micro packed with peripherals and the minimum configuration still has 8K Flash and 2K RAM. There is also a bonus, how much would you pay for a device that supplied a factory assigned unique serial number? Well, it's included on the device.
As well these devices include UART, fast I2C, SPI, and 8x10-bit ADC channels. Sure it's a HVQFN33 pack which measures 7x7mm and that's smaller than an 8-pin DIP too and some might find it daunting to solder but in fact they are very easy to work with using only basic stuff. If while you are practicing how to solder you end up wrecking a couple well then you know that it's only the cost of a beer that you could cry over.
As to the interface to these PPCs I don't have a problem using I2C obviously but I can understand why some would want a single wire interface especially when you are working with a restricted 8-pin micro. Of course I use the same two I2C lines as the EEPROM so it only costs me a Prop pin per PPC to control the in-circuit programming.
There is no need to hold an image of the PPC's firmware in the Prop in normal operation. What I do is load a Spin object into RAM that has the image file embedded using the "file" directive in BST. That way you can "program" the PPC the same way you program the Prop without disturbing the Prop's firmware.
Those are great prices on the Freescale parts, but I don't really want to install another toolchain right now... and I don't think my old 6801 toolchain is up to date enough!
You asked me to convince you on the 10 pin in-line (optional 11th pin for +5) connector...
It natively fits the Parallax serial/usb protoboard, SpinStudio, and all Mikronauts boards
Need more convincing?
- I have approx. 10 different I/O modules coming in the next couple of months for it.
- when using an SMT prop, it makes for a neat small square module
I do like PMOD's, but I think for me at least the 10/11 pin in-line connectors work best.
(My Coolrunner-II CPLD design kit takes PMOD's)
Programming
Programming the micro (any micro) could be done by a header from another set of prop pins because I don't see this changing often. The biggest advantage of any micro is standard voltages (i.e. no high voltage required).
I must say that the ATTiny24/44/84 with SOIC14 and DIP14 packages make an attractive choice. Apart from the fact I have the MC9RS08 parts (and Pic12F2xx too) and I have done a huge amount of code using 68705s I am totally open.
As I said to Steve (jazzed) on his I2C keyboard/mouse thread, the ATTiny24/44/84 would make a great device for I2C to Keyboard, Mouse and 2x NES connectors combined in 1 micro.
1-pin interfaces are only necessary if it is using more prop pins. Using the existing EEPROM I2C pins covers this situation.
Would you like it better if it were supplied already soldered to a thin substrate (30mil) with castellations so you could solder it to the host pcb with any old iron??? In about the size of an 8-pin DIP you could have easily have 12 "pins" available.
-Phil
Now where did I put those LPC1114 QFN samples...
Ideally it would be nice if the propeller could load the co-pro, because it eliminates the need for others to have the tool chain and programming hardware. The binary would just be encapsulated as data inside the prop program.
As I understand it, the Atmel debugwire protocol is closed source. Does anyone know of an open implementation of debugwire? Otherwise we're all going to need Atmel programming adapters. Some of these are quite cheap.
The freescale option starts to look good, for DIP availability and because of their one pin programming and debug interface, and there is also an open source BDM implementation here:-
http://forums.freescale.com/t5/OSBDM-JM60-Open-Source-BDM-for/bd-p/OSBDM08
I've thought about this many times, and I tend to agree. The AVR debugWIRE is supposed to be only for debugging - maybe someone has figured out how to program over it. I've planned to use a Propeller in the TBD "Peripheral Playground" board. I'll look at the Freescale solution.
If it does work out that 4-pins are required then a good choice would be the CDROM/DVD internal audio cables. Many of those use all 4-pins and are pretty inexpensive these days.
Robert
It would be nice, but not mandatory, to be able to reprogram the micro at will by the prop. I expect that most code will be almost permanent after it is debugged and we could (with parallax approval) post the object in the OBEX. Someone may even sepp the dip chips pre-programed.
So, the ATTiny does NOT require expensive programming.
IIRC the MC9(R)S08 requires a high voltage Vpp on Reset to program it. This is quite simple to achieve with a battery and regulator but is just another "thing" required.
Peter: Yes thanks for the soldering tip for QFN. I have to use them in some instances but avoid them where possible.
Now, what I would really like is a SOT23-8 (the 8pin sot version) micro. Very small and the 0.65mm pin spacing.