I have used a lot of the 8051 parts, especially the Silabs parts but unless you are talking volume >1k then there is no point in picking the cheapest suitable part. Sometimes it pays just to spend $1 instead of 50c. I have Spin code that can burn the Flash of a Silabs part using just the Prop's I2C bus plus one extra select pin which is actually the clock/reset for programming. That way you solder the part in and use I2C plus one extra I/O to not only communicate with the keypad chip but also to Flash the part.
Alternatively I leave 5 spaced vias for PIC chips so that I can press a PicKit programmer into the holes for ICP which is usually only ever once. I hate the small PIC instruction set but hardware is cheap and works whereas the 8051 parts are much nicer.
I have also used a small XMC1100 in a tiny package running Forth so I don't even need to program any assembler code at all or use ICP, just paste a high-level Forth source code into it over the serial link and it is "programmed". In quantity they only cost around $1. This chip is now my preferred goto chip for small devices plus I have my one-wire high speed multidrop network built into Tachyon so I can have scores of different slave devices on the "network" which I can interact with at the Forth level and debug or reprogram them over the network. Dead simple.
I have used a lot of the 8051 parts, especially the Silabs parts but unless you are talking volume >1k then there is no point in picking the cheapest suitable part. Sometimes it pays just to spend $1 instead of 50c. I have Spin code that can burn the Flash of a Silabs part using just the Prop's I2C bus plus one extra select pin which is actually the clock/reset for programming. That way you solder the part in and use I2C plus one extra I/O to not only communicate with the keypad chip but also to Flash the part.
Alternatively I leave 5 spaced vias for PIC chips so that I can press a PicKit programmer into the holes for ICP which is usually only ever once. I hate the small PIC instruction set but hardware is cheap and works whereas the 8051 parts are much nicer.
I have also used a small XMC1100 in a tiny package running Forth so I don't even need to program any assembler code at all or use ICP, just paste a high-level Forth source code into it over the serial link and it is "programmed". In quantity they only cost around $1. This chip is now my preferred goto chip for small devices plus I have my one-wire high speed multidrop network built into Tachyon so I can have scores of different slave devices on the "network" which I can interact with at the Forth level and debug or reprogram them over the network. Dead simple.
I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.
I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.
Hmmm, lots and lots of reasons including the fact that things just work, it has a lot of device drivers built into it for RTC, EEPROM, keypads, LCDs, Shift regs, PING, DHT22, very fast SPI, 1-wire, I2C, WS2812, F32, 32-channel PWM, FAT32 on SD cards, Ethernet, my own one wire or RS485 networking etc etc. You won't get any faster SPI even in ASM plus Spin/C which is the bottleneck since the SPI interface in Tachyon is essentially a set of instructions that access PASM subroutines in the Tachyon cog. The same with SD cards as the interface communicates at 10MHz and the high level keeps up with it very well too.
It is very fast and compact so it all squeezes into a standard Prop and of course you don't need a compiler and debugger as the resident Tachyon is the compiler, debugger, and application. This is at lease one of the reasons we are building a version of this to fit in the upcoming P2 boot mask ROM.
Besides all that it is a lot of fun, it brings back the "hands on" interaction with the hardware and the software that you lose when using a PC based compiler and download the binary. The original Tachyon thread is huge but the V4 thread is a lot easier to trawl through. Click on my sig pic for a link page.
I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.
Hmmm, lots and lots of reasons including the fact that things just work, it has a lot of device drivers built into it for RTC, EEPROM, keypads, LCDs, Shift regs, PING, DHT22, very fast SPI, 1-wire, I2C, WS2812, F32, 32-channel PWM, FAT32 on SD cards, Ethernet, my own one wire or RS485 networking etc etc. You won't get any faster SPI even in ASM plus Spin/C which is the bottleneck since the SPI interface in Tachyon is essentially a set of instructions that access PASM subroutines in the Tachyon cog. The same with SD cards as the interface communicates at 10MHz and the high level keeps up with it very well too.
It is very fast and compact so it all squeezes into a standard Prop and of course you don't need a compiler and debugger as the resident Tachyon is the compiler, debugger, and application. This is at lease one of the reasons we are building a version of this to fit in the upcoming P2 boot mask ROM.
Besides all that it is a lot of fun, it brings back the "hands on" interaction with the hardware and the software that you lose when using a PC based compiler and download the binary. The original Tachyon thread is huge but the V4 thread is a lot easier to trawl through. Click on my sig pic for a link page.
That is impressively fast. I'm taking a different approach for my current project, but I will dig into 4th soon.
Thanks for the info.
Well, it works!
I have learned that this is not the best method of achieving my goals, but I did complete my original goal of a multiplexing a large keypad onto 5 wires reading 4 bits in parallel. (Though, the parallel part is still not really parallel yet)
It has no cross chatter and bounce does not effect the circuit, even at full speed.
As predicted by others, the 40xx ICs are plenty fast for what the propeller can do. So there is no need to make the 74xx version.
I still have a lot of optimization to do but here is the functioning code in Prop C:
#include "simpletools.h" // Include simple tools
int main() // main function
{
int buttons[] = {0,0,0,0}; // row buffer
while(1) // Endless loop
{
int index;
for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced
high(0); // Raise P0, Clock the multiplexer
buttons[0] = input(1); // P1 input -> button variable
buttons[1] = input(2); // P2 input -> button variable
buttons[2] = input(3); // P3 input -> button variable
buttons[3] = input(4); // P4 input -> button variable
print("%d%d%d%d\n", buttons[0], buttons[1], buttons[2], buttons[3]);
low(0); // Lower P0
}
pause(125); //125ms to time-slice other cog functions
}
}
My next step after this is to build a controller out of an N76E003. It will pole the keys and buffer the decoded characters until my cog calls for them, and the best part is it will only need one wire to my Prop. It took some convincing but I see how this is vastly superior compared to my current design.
I will continue this thread with that project as well.
I may not have listened right away but everyone who commented here was a big help.
Thank You
int Mask = 0x1e; // pins 4, 3, 2, 1
int I = INA & Mask; // read all input pins and remove excess
I = I >> 1; // normalize value to 4 bits
print("%d \n", I); //keyboard value
int Mask = 0x1e; // pins 4, 3, 2, 1
int I = INA & Mask; // read all input pins and remove excess
I = I >> 1; // normalize value to 4 bits
print("%d \n", I); //keyboard value
Mike
Thanks a bunch
#include "simpletools.h" // Include simple tools
int main() // main function
{
int row_bf;
int index;
while(1) // Endless loop
{
for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced
high(4); // Raise P4, Clock the multiplexer
row_bf = INA & 0xf; // Read pins 0, 1, 2, 3
print("%d \n", row_bf);
low(4); // Lower P4
}
pause(100); // 100ms to time-slice other cog functions
}
}
Comments
Alternatively I leave 5 spaced vias for PIC chips so that I can press a PicKit programmer into the holes for ICP which is usually only ever once. I hate the small PIC instruction set but hardware is cheap and works whereas the 8051 parts are much nicer.
I have also used a small XMC1100 in a tiny package running Forth so I don't even need to program any assembler code at all or use ICP, just paste a high-level Forth source code into it over the serial link and it is "programmed". In quantity they only cost around $1. This chip is now my preferred goto chip for small devices plus I have my one-wire high speed multidrop network built into Tachyon so I can have scores of different slave devices on the "network" which I can interact with at the Forth level and debug or reprogram them over the network. Dead simple.
I keep seeing Tachyon 4th. Assuming I don't need an OS is there a distinct advantage to programming in 4th over Prop C and ASM? I'm willing to take the pill if there's a reason.
Hmmm, lots and lots of reasons including the fact that things just work, it has a lot of device drivers built into it for RTC, EEPROM, keypads, LCDs, Shift regs, PING, DHT22, very fast SPI, 1-wire, I2C, WS2812, F32, 32-channel PWM, FAT32 on SD cards, Ethernet, my own one wire or RS485 networking etc etc. You won't get any faster SPI even in ASM plus Spin/C which is the bottleneck since the SPI interface in Tachyon is essentially a set of instructions that access PASM subroutines in the Tachyon cog. The same with SD cards as the interface communicates at 10MHz and the high level keeps up with it very well too.
It is very fast and compact so it all squeezes into a standard Prop and of course you don't need a compiler and debugger as the resident Tachyon is the compiler, debugger, and application. This is at lease one of the reasons we are building a version of this to fit in the upcoming P2 boot mask ROM.
Besides all that it is a lot of fun, it brings back the "hands on" interaction with the hardware and the software that you lose when using a PC based compiler and download the binary. The original Tachyon thread is huge but the V4 thread is a lot easier to trawl through. Click on my sig pic for a link page.
That is impressively fast. I'm taking a different approach for my current project, but I will dig into 4th soon.
Thanks for the info.
-Phil
Thank you, Phil
I will do just that.
I'm using the 4027 as an SR latch. What SR latch would you recommend for use with the 74HCT4017, please?
Sweet. After I finish the 40xx I'll get those.
Thank you
I posted more info with the schematic linked on imgur at the bottom of the video description.
I will be hooking it up to a Prop in the next video :-D
I have learned that this is not the best method of achieving my goals, but I did complete my original goal of a multiplexing a large keypad onto 5 wires reading 4 bits in parallel. (Though, the parallel part is still not really parallel yet)
It has no cross chatter and bounce does not effect the circuit, even at full speed.
As predicted by others, the 40xx ICs are plenty fast for what the propeller can do. So there is no need to make the 74xx version.
I still have a lot of optimization to do but here is the functioning code in Prop C:
#include "simpletools.h" // Include simple tools int main() // main function { int buttons[] = {0,0,0,0}; // row buffer while(1) // Endless loop { int index; for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced high(0); // Raise P0, Clock the multiplexer buttons[0] = input(1); // P1 input -> button variable buttons[1] = input(2); // P2 input -> button variable buttons[2] = input(3); // P3 input -> button variable buttons[3] = input(4); // P4 input -> button variable print("%d%d%d%d\n", buttons[0], buttons[1], buttons[2], buttons[3]); low(0); // Lower P0 } pause(125); //125ms to time-slice other cog functions } }My next step after this is to build a controller out of an N76E003. It will pole the keys and buffer the decoded characters until my cog calls for them, and the best part is it will only need one wire to my Prop. It took some convincing but I see how this is vastly superior compared to my current design.
I will continue this thread with that project as well.
I may not have listened right away but everyone who commented here was a big help.
Thank You
int Mask = 0x1e; // pins 4, 3, 2, 1 int I = INA & Mask; // read all input pins and remove excess I = I >> 1; // normalize value to 4 bits print("%d \n", I); //keyboard valueMike
Thanks a bunch
#include "simpletools.h" // Include simple tools int main() // main function { int row_bf; int index; while(1) // Endless loop { for(index = 0; index < 13; index++) { // Scan loop, to be time-sliced high(4); // Raise P4, Clock the multiplexer row_bf = INA & 0xf; // Read pins 0, 1, 2, 3 print("%d \n", row_bf); low(4); // Lower P4 } pause(100); // 100ms to time-slice other cog functions } }This works very well, thanks @iseries :-)
-Phil
Thanks
I need the practice