@cluso:
The PS/2 keyboards I use are at least 12 years old as SGI stopped shipping them a couple years before Y2K. They are quite sturdy, and heavy, and have a good feel.
My favorite, however are at least 16 years ago, as they worked on the SGI Onyx and Indigo. These use a proprietary SGI protocol, so I don't use them often, but the mouse plugs into the keyboard, and the keyboard into the Indigo/Onyx via PS/2 style connector. They are very sturdy,and have a feel to them that is not matched(in my opinion) in a non-clicky(IBM) keyboard. They have a flat base, so there is plenty of room for battery and a few props eventually, and even connectors out the back C64 style. The real cool thing is that I have over 2 dozen of them new in the box.
After some thinking, there is plenty of bandwidth in BeauNet, so one could just ping pong it back and forth for full duplex on a single pin if you're really short on pins (ie. RamBlade).
Yeah, in my favorite keyboards, you could probably put 12 RamBlades, but even together, you wouldn't have enough pins to get the keyboard read.
@jazzed, I2C ain't a bad idea for 2 pins since you can chain a lot of stuff on the buss IIRC. It is quite a bit lower on the bandwidth though just fine for keyboard and mouse.
I've made some progress on the I2C mouse. I had to take a 2 week+ break for personal reasons. I'm back home now churning on projects.
Below is a dump from my mouse test program. The data shows packets received on a mouse move or a button click. Next up is creating a Mouse.spin compatible driver and testing with some TV terminal program. Then I'll work on the I2C keyboard after the mouse code is done. Both devices share the same serial communications interface.
As mentioned before, the controller is an atTiny85. It will be operating in I2C slave mode and I believe it can be used without wasting a COG - we'll see.
Looks like the first PC board to use the interface will be a Gadget Gangster SDRAM board since that design appears to be fully functional at revision 1. Other boards will be available, and I'll offer the device pre-programmed via Gadget Gangster - details TBD.
--Steve
I2C Mouse Test Startup
I2C Mouse init Ok. Now wait for BAT ... done.
Mouse type 03 detected.
08010000
2800FF00
08010000
08010000
08010000
08010000
09000000
08000000
09000000
08000000
0A000000
1AFF0000
08000000
280000FF
18FF0000
I now have a functional PS2I2C keyboard/mouse controller.
I'm looking for testers to help ensure broad hardware compatibility.
Please respond to this thread if you want to help test.
Advantages of using the PS2I2C:
Save 4 Propeller pins.
Shares common I2C bus required for Propeller standalone bootup.
Save at least 1 COG (and maybe 2 for EEPROM access).
Cheap microcontroller hardware design.
You specify the device ID at power up.
I'll provide one of the following at retail cost+shipping/handling for testers.
1) Hacked Propeller Protoboard with VGA or TV video.
2) Hacked GadgetGangster Propeller Platform A/V board.
3) Propeller Platform 32MB SDRAM TV/SDCARD Keyboard/Mouse.
4) A binary image via email for atTiny85 or other AVR having USI.
Please choose one of the solutions if you want to be a tester.
Longer term I can provide a Propeller based "Peripheral Playground"
board for the GadgetGangster platform or other boards like C3.
It is a bit more expensive than the MC9RS08 but is more like programming a prop than the MC part. It's a shame it cannot be programmed from the I2C port rather than the SPI port.
I note that it also can do 4x10b ADC too.
I could use an ATTiny instead of the MC9(R)S08 for the NES driver. Perhaps you would be interested to do the Dual NES to I2C?
I could certainly see a range of I2C peripherals with this chip :smilewinkgrin:
@Cluso99, I might have time for the NES controller later. So many projects, so little time.
Actually, I'm thinking about using the 14 pin atTiny24 for tester prototypes since that makes the RESET line available and offers much more flexibility. Pricing of from Mouser is $2.03 per unit and $1.56 @ 10 each.
Of course Propeller is so much easier in many ways
It is a bit more expensive than the MC9RS08 but is more like programming a prop than the MC part. It's a shame it cannot be programmed from the I2C port rather than the SPI port.
I note that it also can do 4x10b ADC too.
I could use an ATTiny instead of the MC9(R)S08 for the NES driver. Perhaps you would be interested to do the Dual NES to I2C?
I could certainly see a range of I2C peripherals with this chip :smilewinkgrin:
I now have a functional PS2I2C keyboard/mouse controller.
I'm looking for testers to help ensure broad hardware compatibility.
Please respond to this thread if you want to help test.
Advantages of using the PS2I2C:
Save 4 Propeller pins.
Shares common I2C bus required for Propeller standalone bootup.
Save at least 1 COG (and maybe 2 for EEPROM access).
Cheap microcontroller hardware design.
You specify the device ID at power up.
I'll provide one of the following at retail cost+shipping/handling for testers.
1) Hacked Propeller Protoboard with VGA or TV video.
2) Hacked GadgetGangster Propeller Platform A/V board.
3) Propeller Platform 32MB SDRAM TV/SDCARD Keyboard/Mouse.
4) A binary image via email for atTiny85 or other AVR having USI.
Please choose one of the solutions if you want to be a tester.
Longer term I can provide a Propeller based "Peripheral Playground"
board for the GadgetGangster platform or other boards like C3.
jazzed: How much code space did you use for the keyboard/mouse?
I presume in a ATTiny44/84 device (SOIC14) you could also fit the code & 4 pins required to do the interface to 2xNES controllers. The interface is extremely simple... a load pin, clock pin and 2 data pins (1 to each controller). The controller uses a parallel to serial shift register (4051??) to read the buttons.
This would be an awesome expansion pcb and make up for the extra cost of the ATTiny.
@Cluso99, I'm using less than 1KB of flash now. A third of it is I2C code. Registers are getting scarce, but I could swap them if necessary. Might do it all in an atTiny24, but the input queues might be too small.
My main concern is holding the keyboard/mouse transmitters off while getting other bytes. The clock lines are used back-pressure the devices. The keyboard buffers bytes, but the mouse does not. This makes operation a little tough to get right.
jazzed: How much code space did you use for the keyboard/mouse?
I presume in a ATTiny44/84 device (SOIC14) you could also fit the code & 4 pins required to do the interface to 2xNES controllers. The interface is extremely simple... a load pin, clock pin and 2 data pins (1 to each controller). The controller uses a parallel to serial shift register (4051??) to read the buttons.
This would be an awesome expansion pcb and make up for the extra cost of the ATTiny.
The mouse works fine. The keyboard works fine.
Unfortunately, the keyboard interferes with the mouse.
So, they don't work fine at the same time. Ugh.
The few ideas I had on fixing the issue have not worked out. I'll continue working on this, but I can not guarantee success. Meanwhile I have some other things I need to finish.
I will most likely be posting source code in a several days for the AVR and Propeller side for what I do have working for anyone who wants to try their hand on a solution.
Posting the sources would allow anyone to use what does work on the current combined SDRAM and PS2I2C board design, but the feature will not be "officially supported" on that board.
jazzed: When you get time to fix it will be fine. Your work here has enlightened me and others. I have no doubts it can be resolved and that the ATTiny (or other micro) can be used to de even more. As you know, it is usally the simplest bugs that take the most time to fix, and a fresh look a little later often makes things clearer. :smilewinkgrin:
Thanks for your encouragement! You're probably right about finding a solution later.
Meanwhile, I've started thinking about how to include an I2C boot manager in the atTiny - when I have time to develop it more fully, I'll post some framework code in the other thread.
Might I suggest that my muti-threading scheduler could be a solution??
It all depends on expectations as well as "feeds and speeds", but to prove a point, presently I have Serial Tx, Serial Rx at 9600, and I2C at 700 Khz co-existing and operating simultaneously (non-blocking) and happily in a single cog, with yet tons of room, and time to spare.
It would not surprise me if a keyboard/mouse could be merged in as well.
Might I suggest that my muti-threading scheduler could be a solution??
Peter, the problem is on the AVR side. Maybe your scheduler could be ported.
The hard part for AVR is managing the devices, collecting the data, and forwarding it all at the same time as an I2C slave which of course must be polled. Propeller offers the perfect software solution for this problem of course, and I'll be designing the Propeller based I2C Peripheral Playground module which will allow using AVR as ADC and/or other device's functions in a hobby friendly way.
Sorry; how could I even have thought that you were not able to get the Prop side working !!!! (Slaps himself).
As for porting the scheduler to AVR, I suspect not, but surely a new one could be written. Remember this scheduler concept originated in the SX, where it only consumed 25 bytes and ran like stink.... as fast as 200 nano second tix if I recall correctly. (AND THAT WAS BECAUSE IT HAD A PROPER INTERRUPT). In the Prop it is quite a bit slower.... 1.5 uSec tix at best, but does allow for some additional features.
As I indicated in another of your threads, I expect to pursue the TI430 because it really fits my low power draw needs well, has a virtually instant wakeup from sleep, and I fully expect to write one for that chip. Then I will implement I2C peripherals on that puppy.
I don't know the AVR processor, and don't expect to get into that one.
Issues:
1) The 10K pull-ups were not strong enough.
2) Forgot to disable reset for the working version
To get over the reset pin problem, I'm working on an I2C bootloader.
I'm not sure if a bootloader will actually be workable, but I've seen
C code loaders on *freaks* - which is of course too big for atTiny.
@Cluso99, If you're reading, I've described a framework for a bootloader.
Please review, and offer suggestions. Input also welcome from others
;
;
;
; I2C Bootloader Interface definition (rough draft)
;
; This device connects to a host via an I2C interface.
; It allows a user to load and boot a program on AVR via I2C.
; The device is an I2C slave. A master can write or read it.
;
; The device identifier for the program is user specified.
;
; The user will provide the device ID via a Permiscuous
; Configuration Protocol "PCP" exchange. Since it is common
; for the device to reside on the same bus as an I2C EEPROM
; having DEVID $A0-$AF, the device will respond to any
; access not including address $A0-$AF until configured
; to the address selected by the user with PCP.
;
; Once the PCP address is set, the user can change the address
; via an EEPROM write.
;
; A PCP user address must not be $10-$1F, $A0-$AF, or $F0-$FF.
; If the address is not in the valid range configuration will
; fail. The user must specify an address.
;
;
;
; Bootloader Command Summary:
;
;
; =================
; Load Page
; =================
;
; Arguments: Flash page (8 bits), page length (8 bits),
; and page data up to 256 bytes.
;
; Flash page is the page to write. The address is page * 256.
; A flash page that would over-write the bootloader is not valid.
;
; Page length is how much of the page is to be written.
; Page length 0 indicates write an entire page.
; Page length any other value N means write N bytes.
;
; Returns: non-zero if page programming succeeded
;
; =================
; Start Program
; =================
;
; Arguments: program length (16 bits), and CRC (16 bits)
; Returns: non-zero if program started
;
; =================
; Is Valid Program
; =================
;
; Arguments: none
; Returns: non-zero if program is valid
;
; =================
; Write EEPROM
; =================
;
; Arguments: address (8 bits), length (8 bits), data buffer
; Returns: non-zero if operation succeeded
;
; =================
; Read EEPROM
; =================
;
; Arguments: address
; Returns: byte read from EEPROM
;
;
;
; Basic operations:
;
;
; The USI Start Interrupt is used to manage loading and
; running programs. All interrupt vectors should jump through
; the bootloader monitor vectors before the user ISR is called.
; If program flow gets to user ISR, it is up to the user to
; handle the end of interrupt state, but the bootloader should
; execute the return from interrupt RETI.
;
; Only two interrupt vectors are intercepted by the bootloader
; manager: 1) Reset and 2) USI start.
;
; 1) The reset vector start address in the bootloader is
; $1FF0. This must be the jump address from the user's
; interrupt vector table. The function of bootloader reset
; is described briefly here.
;
; At reset, the bootloader manager will check for a valid
; user image in flash. The bootloader will calculate a
; checksum (variation of CRC16) and compare it against the
; CRC location in EEPROM. If the image is not valid, the
; bootloader will remain idle waiting for bootloader commands
; from the user. The user can check if a valid program is
; loaded with a command.
;
; 2) To allow variations on USI Start, a vector is used.
; User programs must always include a jump to the bootloader's
; USI Start interrupt service routine at location $1FF2.
; This allows the bootloader program manager to skip jumping
; to the user's ISR when a program load is incomplete.
;
; The bootloader loads and stores one program buffer at a
; time from I2C to Flash and can use X/Y index for storage.
; The load packet command contains load command, save
; address offset, and buffer length. The user's I2C master
; must arrange for all data to be written. At the end of
; the loader procedure, the I2C master must send a start
; program command with the expected program length and CRC.
; On receiving the command, the bootloader will check the
; CRC against a calculated value and store it EEPROM if the
; CRC matches. If the match CRC fails, 0 will be written
; to the EEPROM program length and CRC fields.
;
; Start program command allows the user to restart the program
; by forcing a jump to the reset vector. This is a warm
; start that will not attempt to set an initial state
; (unless the watchdog reset can be used ???). When started
; the normal bootloader procedure outlined above is followed.
;
; Program buffer lives in SRAM address $100 - $1ff.
; Buffers can not start at 0 since registers live there.
;
; Commands will allow user to access the atTiny EEPROM.
; The EEPROM is very small but still useful. Mainly, the
; boot-up device id will be kept in EEPROM to give the user
; flexibility in choosing the DEVICE ID for their own system.
;
; User's should be aware that I2C DEVICE IDs are owned
; and sold by the inventor (originally Philips). It's probably
; best to not sell a device that contains a fixed DEVICE ID.
; I2C is no longer protected by patent, but people still use
; the TWI acronym instead hoping to avoid paying royalties.
;
; Use at your own risk.
;
;
;
I am not yet familiar with the ATTiny but I have been reading. The ATTiny84 from DigiKey seems like an excellent choice. ATTiny84-20PU $1.68/100 (DIP14), ATTiny84-20SSU $1.62/100 (SOIC14), ATTiny84V-10SSU $1.62/100 (SOIC14). All have 8KBx8 and 10b ADC. The SOIC14 is 1.27mm pitch and 6x8.7mm which means quite easy to solder.
re your spec, it sounds great so far. The only proviso may be that when initially programming the device, an ID could be programmed at that time. This is really only a an extra programming step as the code when operational would see that the EEPROM holds a device ID.
Although I have done I2C before, it is so long ago I cannot remember much. The runtime I2C commands and enquiry when running needs much more care because a single command/enquiry needs to return status plus optionally outstanding keystrokes, mouse movements, etc. The I2C programming interface is not so important as long as it is secure and works.
I am presuming that there is no general device ID that can be used for testing that we could use?
Couldn't we choose the address of some existing chip that will "never get used" (as long as there are warnings for anybody that might get tempted to use that combination in the future). I was thinking about the A/V controller group.
This would be ok for our internal use, but would be a protential problem for any commercial spin offs. Most of my MACs are just ascii A:P:F: xxxxxx which is ok as long as it says here.
I think the concern is not to breach anything legal so the user will have to insert the address. But we could probably say "$xx" is a nice default to use???
I think the concern is not to breach anything legal so the user will have to insert the address.
This is my main concern. Of course using a fixed address would be much easier. And you can use any address you like except as outlined above.
On the bootloader, the device IDs will be read from the on-board EEPROM so you have the option of programming the device ID if you like from the AVR programmer over the SPI interface. Normal EEPROM content $FF is not a valid device ID. I envision the device having more than one ID - each device must have a bootloader ID of course.
The method I'm using for assigning an address today at startup is working fine for one device on the bus using the promiscuous protocol. In future versions of the protocol for coexisting with a device ID saved in EEPROM, a low pin state (< VIL) for a second after power up or reset would indicate promiscuous mode - the pin could be free for normal operation after reset with a 10K pull-up for example.
I was looking at the *freaks* ASM bootloader. It uses a dedicated boot block for the loader and programs the rest of the flash with a .hex file. It is a hands-off approach. What I'm planning is more hands-on.
The bootloader design I'm considering would always be available via the USI start interrupt vector at the device's "bootloader ID" address, so even if the user program is completely gone, you could still talk to the bootloader. The bootloader will not allow over-writing itself.
The only real dangers that I'm aware of for bootloader reprogramming lay in 1) overwriting the interrupt jump vector page 0 without the RESET and USI Start jumps, 2) programming flash when VCC is too low, and 3) bootloader bugs.
1) As for inadvertently overwriting the jump vectors, the bootloader could reject programming a buffer that does not have good interrupt jump addresses as defined in the spec above.
2) I'm not sure what can be done about power problems except for guaranteeing power to the device or holding the RESET line while programming via SPI. The SPI can be connected with suitcase jumpers if necessary for programming mode.
3) As for bugs, well the bootloader must be validated. Algorithms can be tested with the simulator. However, nothing replaces good planning to cover all possibilities and heeding the voices of experience. Finally, broad testing builds confidence.
Regarding I2C communications for mouse/keyboard, I'll answer that in detail later.
That will be why Atmel call their version TWI then. Are there any spare TWI addresses going? Or is that just as bad?
I2C is off patent, so no one can sue you for using it. TWI is probably a better acronym to use in product literature. TWI is I2C compatible, so to inter-operate on an I2C compatible bus, you have to follow the rules. If you like, you can buy an I2C address for about 1500 Euros, but the address will most likely be 10 bits.
Here is another installment of specification for consideration.
Some of the details may change but it is an idea of where I'm
heading in case my course needs some correction.
A .gen file is one of a few outputs from AVR Studio. I'm assuming
a .hex file can be used for the program download as long as
certain rules are followed.
The bootloader source is a template where the user application
can live and makes the details below easier to follow.
Some of the details given need to be set in stone such as the
interrupt vector jumps. The most worrying part of fixing addresses
is whether or not a page of bytes is enough for the loader.
We'll see ....
;---------------------------------------------------------
;
; Here is an example of a .gen file created by AVR Studio.
;
; The first word at $0000 is rjmp to RESET which must be $CF00.
; The second word at $000D is rjmp to USI Start and must be $CEF2.
; Other words in the range 0 to $1F can be any value.
;
; The word at $20 (byte address $40) is the main user USI start vector.
; This is the entry point for user USI Start interrupt and must contain
; an rjmp to the user's USI Start routine.
;
; The word at $21 (byte address $42) is the main user program.
; In this case the user program is an LED blinker.
;
; Any code from $000 to $EFF (byte address $0000 to $1FDE) is user
; code and if it has correct vectors it can be programmed using
; the bootloader. This provides 7680 bytes for the user program.
;
; The word at $F00 (byte address $1E00) is the loader rjmp USI start.
; The word at $F01 (byte address $1E02) is the loader RESET code.
;
; Words from $F04 (byte address $1E04) to end are the bootloader.
; Hopefully one page will be big enough, but this is not certain.
;
;---------------------------------------------------------
/*
000000:cf00
00000d:cef2
000020:c006
000021:9ab9
000022:e001
000023:b328
000024:2720
000025:bb28
000026:cffc
000027:9508
000f00:c04b
000f01:e002
000f02:bf0e
000f03:e50f
000f04:bf0d
000f05:e000
*/
;---------------------------------------------------------
;---------------------------------------------------------
Steve, if 1 page is not big enough, then it can take the top 2 pages as long as the vectors remain the same the code can ultimately jump from the $F00 page to the $E00 page. Then, as long as it prevents programming the bootloader 'used' pages (without a special sequence which we must ultimately allow for bugfixes of the bootloader) the code will be fine.
First thing would be to get the bootloader doing I2C and downloading/programming another (fixed page) and executing it (say blinking an LED).
Steve, if 1 page is not big enough, then it can take the top 2 pages as long as the vectors remain the same the code can ultimately jump from the $F00 page to the $E00 page. Then, as long as it prevents programming the bootloader 'used' pages (without a special sequence which we must ultimately allow for bugfixes of the bootloader) the code will be fine.
Makes sense. I originally had the loader vectors at $1FF8 (byte address) and moved them to conserve space. Being able to move the bootloader down makes a convincing argument for putting the vectors back on top - guess they'll go to $1FFC/$1FFE.
I believe the user program can become a temporary bootloader for loading a new permanent bootloader assuming a cookie is set to allow over-writes.
All CRCs, Cookies, and user non-volatile data can live in EEPROM but write access should be wrapped in explicit commands such as enable bootloader write rather than allowing a generic write. Generic reads would be ok of course.
I'm working on getting the bootloader to talk and download, but it's getting late on the "left coast" as they say here. I have other obligations tomorrow and other days this week, so I may slow down on this for a little while. Once I get more framework done, I'll send you a copy.
Steve, I think that the bootloader will be the same for both the ATtiny84 & 85. Of course the 24/25 and 44/45 will be different because of different Flash size.
Yes the vectors at the top make the most sense as the bootloader can move down to whatever is required.
Comments
The PS/2 keyboards I use are at least 12 years old as SGI stopped shipping them a couple years before Y2K. They are quite sturdy, and heavy, and have a good feel.
My favorite, however are at least 16 years ago, as they worked on the SGI Onyx and Indigo. These use a proprietary SGI protocol, so I don't use them often, but the mouse plugs into the keyboard, and the keyboard into the Indigo/Onyx via PS/2 style connector. They are very sturdy,and have a feel to them that is not matched(in my opinion) in a non-clicky(IBM) keyboard. They have a flat base, so there is plenty of room for battery and a few props eventually, and even connectors out the back C64 style. The real cool thing is that I have over 2 dozen of them new in the box.
After some thinking, there is plenty of bandwidth in BeauNet, so one could just ping pong it back and forth for full duplex on a single pin if you're really short on pins (ie. RamBlade).
Yeah, in my favorite keyboards, you could probably put 12 RamBlades, but even together, you wouldn't have enough pins to get the keyboard read.
@jazzed, I2C ain't a bad idea for 2 pins since you can chain a lot of stuff on the buss IIRC. It is quite a bit lower on the bandwidth though just fine for keyboard and mouse.
Below is a dump from my mouse test program. The data shows packets received on a mouse move or a button click. Next up is creating a Mouse.spin compatible driver and testing with some TV terminal program. Then I'll work on the I2C keyboard after the mouse code is done. Both devices share the same serial communications interface.
As mentioned before, the controller is an atTiny85. It will be operating in I2C slave mode and I believe it can be used without wasting a COG - we'll see.
Looks like the first PC board to use the interface will be a Gadget Gangster SDRAM board since that design appears to be fully functional at revision 1. Other boards will be available, and I'll offer the device pre-programmed via Gadget Gangster - details TBD.
--Steve
It works best by starting the driver in a COG.
I replaced 2 lines in Graphics_Demo.spin (- removes, + adds)
Simple
Now to test the Keyboard.
I'm looking for testers to help ensure broad hardware compatibility.
Please respond to this thread if you want to help test.
Advantages of using the PS2I2C:
Save 4 Propeller pins.
Shares common I2C bus required for Propeller standalone bootup.
Save at least 1 COG (and maybe 2 for EEPROM access).
Cheap microcontroller hardware design.
You specify the device ID at power up.
I'll provide one of the following at retail cost+shipping/handling for testers.1) Hacked Propeller Protoboard with VGA or TV video.
2) Hacked GadgetGangster Propeller Platform A/V board.
3) Propeller Platform 32MB SDRAM TV/SDCARD Keyboard/Mouse.
4) A binary image via email for atTiny85 or other AVR having USI.
Please choose one of the solutions if you want to be a tester.
Longer term I can provide a Propeller based "Peripheral Playground"
board for the GadgetGangster platform or other boards like C3.
It is a bit more expensive than the MC9RS08 but is more like programming a prop than the MC part. It's a shame it cannot be programmed from the I2C port rather than the SPI port.
I note that it also can do 4x10b ADC too.
I could use an ATTiny instead of the MC9(R)S08 for the NES driver. Perhaps you would be interested to do the Dual NES to I2C?
I could certainly see a range of I2C peripherals with this chip :smilewinkgrin:
Actually, I'm thinking about using the 14 pin atTiny24 for tester prototypes since that makes the RESET line available and offers much more flexibility. Pricing of from Mouser is $2.03 per unit and $1.56 @ 10 each.
Of course Propeller is so much easier in many ways
Thanks.
I presume in a ATTiny44/84 device (SOIC14) you could also fit the code & 4 pins required to do the interface to 2xNES controllers. The interface is extremely simple... a load pin, clock pin and 2 data pins (1 to each controller). The controller uses a parallel to serial shift register (4051??) to read the buttons.
This would be an awesome expansion pcb and make up for the extra cost of the ATTiny.
This discussion makes me think of reviving my 68K/Prop project...
My main concern is holding the keyboard/mouse transmitters off while getting other bytes. The clock lines are used back-pressure the devices. The keyboard buffers bytes, but the mouse does not. This makes operation a little tough to get right.
The mouse works fine. The keyboard works fine.
Unfortunately, the keyboard interferes with the mouse.
So, they don't work fine at the same time. Ugh.
The few ideas I had on fixing the issue have not worked out. I'll continue working on this, but I can not guarantee success. Meanwhile I have some other things I need to finish.
I will most likely be posting source code in a several days for the AVR and Propeller side for what I do have working for anyone who wants to try their hand on a solution.
Posting the sources would allow anyone to use what does work on the current combined SDRAM and PS2I2C board design, but the feature will not be "officially supported" on that board.
--Steve
Thanks for your encouragement! You're probably right about finding a solution later.
Meanwhile, I've started thinking about how to include an I2C boot manager in the atTiny - when I have time to develop it more fully, I'll post some framework code in the other thread.
Cheers.
Might I suggest that my muti-threading scheduler could be a solution??
It all depends on expectations as well as "feeds and speeds", but to prove a point, presently I have Serial Tx, Serial Rx at 9600, and I2C at 700 Khz co-existing and operating simultaneously (non-blocking) and happily in a single cog, with yet tons of room, and time to spare.
It would not surprise me if a keyboard/mouse could be merged in as well.
Let me know if I can contribute to this effort.
Cheers,
Peter (pjv)
The hard part for AVR is managing the devices, collecting the data, and forwarding it all at the same time as an I2C slave which of course must be polled. Propeller offers the perfect software solution for this problem of course, and I'll be designing the Propeller based I2C Peripheral Playground module which will allow using AVR as ADC and/or other device's functions in a hobby friendly way.
Cheers.
--Steve
Sorry; how could I even have thought that you were not able to get the Prop side working !!!! (Slaps himself).
As for porting the scheduler to AVR, I suspect not, but surely a new one could be written. Remember this scheduler concept originated in the SX, where it only consumed 25 bytes and ran like stink.... as fast as 200 nano second tix if I recall correctly. (AND THAT WAS BECAUSE IT HAD A PROPER INTERRUPT). In the Prop it is quite a bit slower.... 1.5 uSec tix at best, but does allow for some additional features.
As I indicated in another of your threads, I expect to pursue the TI430 because it really fits my low power draw needs well, has a virtually instant wakeup from sleep, and I fully expect to write one for that chip. Then I will implement I2C peripherals on that puppy.
I don't know the AVR processor, and don't expect to get into that one.
Cheers,
Peter (pjv)
Issues:
1) The 10K pull-ups were not strong enough.
2) Forgot to disable reset for the working version
To get over the reset pin problem, I'm working on an I2C bootloader.
I'm not sure if a bootloader will actually be workable, but I've seen
C code loaders on *freaks* - which is of course too big for atTiny.
@Cluso99, If you're reading, I've described a framework for a bootloader.
Please review, and offer suggestions. Input also welcome from others
;============================================
;
; atTiny I2C Bootloader
;
;============================================
;
;
;
; I2C Bootloader Interface definition (rough draft)
;
; This device connects to a host via an I2C interface.
; It allows a user to load and boot a program on AVR via I2C.
; The device is an I2C slave. A master can write or read it.
;
; The device identifier for the program is user specified.
;
; The user will provide the device ID via a Permiscuous
; Configuration Protocol "PCP" exchange. Since it is common
; for the device to reside on the same bus as an I2C EEPROM
; having DEVID $A0-$AF, the device will respond to any
; access not including address $A0-$AF until configured
; to the address selected by the user with PCP.
;
; Once the PCP address is set, the user can change the address
; via an EEPROM write.
;
; A PCP user address must not be $10-$1F, $A0-$AF, or $F0-$FF.
; If the address is not in the valid range configuration will
; fail. The user must specify an address.
;
;
;
; Bootloader Command Summary:
;
;
; =================
; Load Page
; =================
;
; Arguments: Flash page (8 bits), page length (8 bits),
; and page data up to 256 bytes.
;
; Flash page is the page to write. The address is page * 256.
; A flash page that would over-write the bootloader is not valid.
;
; Page length is how much of the page is to be written.
; Page length 0 indicates write an entire page.
; Page length any other value N means write N bytes.
;
; Returns: non-zero if page programming succeeded
;
; =================
; Start Program
; =================
;
; Arguments: program length (16 bits), and CRC (16 bits)
; Returns: non-zero if program started
;
; =================
; Is Valid Program
; =================
;
; Arguments: none
; Returns: non-zero if program is valid
;
; =================
; Write EEPROM
; =================
;
; Arguments: address (8 bits), length (8 bits), data buffer
; Returns: non-zero if operation succeeded
;
; =================
; Read EEPROM
; =================
;
; Arguments: address
; Returns: byte read from EEPROM
;
;
;
; Basic operations:
;
;
; The USI Start Interrupt is used to manage loading and
; running programs. All interrupt vectors should jump through
; the bootloader monitor vectors before the user ISR is called.
; If program flow gets to user ISR, it is up to the user to
; handle the end of interrupt state, but the bootloader should
; execute the return from interrupt RETI.
;
; Only two interrupt vectors are intercepted by the bootloader
; manager: 1) Reset and 2) USI start.
;
; 1) The reset vector start address in the bootloader is
; $1FF0. This must be the jump address from the user's
; interrupt vector table. The function of bootloader reset
; is described briefly here.
;
; At reset, the bootloader manager will check for a valid
; user image in flash. The bootloader will calculate a
; checksum (variation of CRC16) and compare it against the
; CRC location in EEPROM. If the image is not valid, the
; bootloader will remain idle waiting for bootloader commands
; from the user. The user can check if a valid program is
; loaded with a command.
;
; 2) To allow variations on USI Start, a vector is used.
; User programs must always include a jump to the bootloader's
; USI Start interrupt service routine at location $1FF2.
; This allows the bootloader program manager to skip jumping
; to the user's ISR when a program load is incomplete.
;
; The bootloader loads and stores one program buffer at a
; time from I2C to Flash and can use X/Y index for storage.
; The load packet command contains load command, save
; address offset, and buffer length. The user's I2C master
; must arrange for all data to be written. At the end of
; the loader procedure, the I2C master must send a start
; program command with the expected program length and CRC.
; On receiving the command, the bootloader will check the
; CRC against a calculated value and store it EEPROM if the
; CRC matches. If the match CRC fails, 0 will be written
; to the EEPROM program length and CRC fields.
;
; Start program command allows the user to restart the program
; by forcing a jump to the reset vector. This is a warm
; start that will not attempt to set an initial state
; (unless the watchdog reset can be used ???). When started
; the normal bootloader procedure outlined above is followed.
;
; Program buffer lives in SRAM address $100 - $1ff.
; Buffers can not start at 0 since registers live there.
;
; Commands will allow user to access the atTiny EEPROM.
; The EEPROM is very small but still useful. Mainly, the
; boot-up device id will be kept in EEPROM to give the user
; flexibility in choosing the DEVICE ID for their own system.
;
; User's should be aware that I2C DEVICE IDs are owned
; and sold by the inventor (originally Philips). It's probably
; best to not sell a device that contains a fixed DEVICE ID.
; I2C is no longer protected by patent, but people still use
; the TWI acronym instead hoping to avoid paying royalties.
;
; Use at your own risk.
;
;
;
I am not yet familiar with the ATTiny but I have been reading. The ATTiny84 from DigiKey seems like an excellent choice. ATTiny84-20PU $1.68/100 (DIP14), ATTiny84-20SSU $1.62/100 (SOIC14), ATTiny84V-10SSU $1.62/100 (SOIC14). All have 8KBx8 and 10b ADC. The SOIC14 is 1.27mm pitch and 6x8.7mm which means quite easy to solder.
re your spec, it sounds great so far. The only proviso may be that when initially programming the device, an ID could be programmed at that time. This is really only a an extra programming step as the code when operational would see that the EEPROM holds a device ID.
Although I have done I2C before, it is so long ago I cannot remember much. The runtime I2C commands and enquiry when running needs much more care because a single command/enquiry needs to return status plus optionally outstanding keystrokes, mouse movements, etc. The I2C programming interface is not so important as long as it is secure and works.
I am presuming that there is no general device ID that can be used for testing that we could use?
This would be ok for our internal use, but would be a protential problem for any commercial spin offs. Most of my MACs are just ascii A:P:F: xxxxxx which is ok as long as it says here.
On the bootloader, the device IDs will be read from the on-board EEPROM so you have the option of programming the device ID if you like from the AVR programmer over the SPI interface. Normal EEPROM content $FF is not a valid device ID. I envision the device having more than one ID - each device must have a bootloader ID of course.
The method I'm using for assigning an address today at startup is working fine for one device on the bus using the promiscuous protocol. In future versions of the protocol for coexisting with a device ID saved in EEPROM, a low pin state (< VIL) for a second after power up or reset would indicate promiscuous mode - the pin could be free for normal operation after reset with a 10K pull-up for example.
I was looking at the *freaks* ASM bootloader. It uses a dedicated boot block for the loader and programs the rest of the flash with a .hex file. It is a hands-off approach. What I'm planning is more hands-on.
The bootloader design I'm considering would always be available via the USI start interrupt vector at the device's "bootloader ID" address, so even if the user program is completely gone, you could still talk to the bootloader. The bootloader will not allow over-writing itself.
The only real dangers that I'm aware of for bootloader reprogramming lay in 1) overwriting the interrupt jump vector page 0 without the RESET and USI Start jumps, 2) programming flash when VCC is too low, and 3) bootloader bugs.
1) As for inadvertently overwriting the jump vectors, the bootloader could reject programming a buffer that does not have good interrupt jump addresses as defined in the spec above.
2) I'm not sure what can be done about power problems except for guaranteeing power to the device or holding the RESET line while programming via SPI. The SPI can be connected with suitcase jumpers if necessary for programming mode.
3) As for bugs, well the bootloader must be validated. Algorithms can be tested with the simulator. However, nothing replaces good planning to cover all possibilities and heeding the voices of experience. Finally, broad testing builds confidence.
Regarding I2C communications for mouse/keyboard, I'll answer that in detail later.
That will be why Atmel call their version TWI then. Are there any spare TWI addresses going? Or is that just as bad?
Some of the details may change but it is an idea of where I'm
heading in case my course needs some correction.
A .gen file is one of a few outputs from AVR Studio. I'm assuming
a .hex file can be used for the program download as long as
certain rules are followed.
The bootloader source is a template where the user application
can live and makes the details below easier to follow.
Some of the details given need to be set in stone such as the
interrupt vector jumps. The most worrying part of fixing addresses
is whether or not a page of bytes is enough for the loader.
We'll see ....
First thing would be to get the bootloader doing I2C and downloading/programming another (fixed page) and executing it (say blinking an LED).
I believe the user program can become a temporary bootloader for loading a new permanent bootloader assuming a cookie is set to allow over-writes.
All CRCs, Cookies, and user non-volatile data can live in EEPROM but write access should be wrapped in explicit commands such as enable bootloader write rather than allowing a generic write. Generic reads would be ok of course.
I'm working on getting the bootloader to talk and download, but it's getting late on the "left coast" as they say here. I have other obligations tomorrow and other days this week, so I may slow down on this for a little while. Once I get more framework done, I'll send you a copy.
Yes the vectors at the top make the most sense as the bootloader can move down to whatever is required.