-
Content Count
223 -
Joined
-
Last visited
-
Days Won
1
Reputation Activity
-
timotet reacted to petertux in USB to gameport project
If you appreciate late 90s vintage PCs you might be interested in this one.
I decided to build a Pentium II machine on which I can play my favourite games from those times. Magic Carpet (Bullfrog Productions) is one of them, but it needs a joystick. I had good quality USB joysticks, but those games need old analog gameport-based controllers that are serviced by the sound cards of the time.
This new project acts as a USB Host and provides the analog output that emulates a 4 axis + 4 button game controller.
the prototype works absolutely great, it takes about 0.6ms to read data from the attached USB joystick and to send it to the sound card. data is retrieved every 10ms as per the HID polling interval, absolutely no input command is lost and there is over-current protection built in in order to protect the PC from misuse.
what do you guys think? I'm open to ideas regarding this project before I commit revision 2 of the board - which might end up being a 4 layer design.
prototype pictures: https://photos.app.goo.gl/fXdDBng4dvEepq8V7
repo: https://cadlab.io/projects/lemidi
cheers,
peter
-
timotet reacted to terjeio in PCB Laser Exposer/Printer
A new design is now up on my Github account, cheaper laser cut acrylic case and 3D printed "laser head". Some info on Hackaday as well.
-
timotet reacted to terjeio in RFC: CNC BoosterPack
Driver code for a few boards is available from my github account. A PCB design with reduced size allows two boards to be mounted to the EK-TM4C1294XL LaunchPad providing up to 6 axes of control (needs to be verified). I have also added TCP streaming to the EK-TM4C1294XL LaunchPad but usure if I can publish the code due to the "viral" clause in many of TIs files - even the startup code 🙁. Grbl is released under GPL and I have a hard time understanding the legalese related to that...
I am currently working on a DRO/MPG for my lathe with Grbl running on a MSP432, and the DRO/MPG code on a Tiva C/MSP430 combo. Threading support is a part of that work and hopefully I'll be able to get it working reliably - looks promising this far.
-
timotet reacted to zeke in One Wire Controller booster
IT'S ALIVE!!!!
I have 104 ds18b20 sensors wired into my board and it is reading them all.
I am celebrating! WOO HOO!
Now it's time to crush an mqtt server!
-
timotet reacted to terjeio in RFC: CNC BoosterPack
Design is now published on Github, driver code to follow when completed - some new features needs to be verified first.
A Youtube video showing off the PCB and some additional parts is here: GRBL DRO & MPG
Terje
-
timotet reacted to terjeio in RFC: CNC BoosterPack
I have recently been working on a CNC BoosterPack that I will make available on Github when completed later in the spring.
Current specifications:
Support for my HALified version of GRBL (based on 1.1), currently drivers has been made for MSP432 (black version), Tiva C and MSP430F2955.
NOTE: firmware is built with CCS 6.1, MSP432 driver is 100% CMSIS based.
Opto-coupled inputs, NC switches recommended.
Opto-coupled outputs with 200mA open drain drive for spindle on, spindle direction, flood and mist.
Can drive most relays and solenoids directly.
Output section can be powered from internal 3V3 or 5V source, or from external source.
If powered from external source outputs can be made opto-isolated via jumper setting.
PWM-output for spindle speed currently directly connected to MCU pin (could be changed to open drain).
I2C (IIC) interface with selectable voltage level (3V3 or 5V) via level shifter, dedicated interrupt input.
I2C pinout compatible with my 4x4 keyboard project, supports jogging etc.
Optional EEPROM for configuration settings for MCUs with no internal EEPROM.
Polulu 8825 motor driver breakout board compatible. Fault signal routed to GPIO input.
Considered for later revision:
Break out SPI interface and add full support for Trinamic motor drivers.
Optional (SPI) DAC for motor speed (laser power) control.
This might require a 4-layer PCB and also solving the pinout cabal...
---
Anything you want changed?
Terje
-
timotet reacted to greeeg in GPS logger for a local Beagle club
Finally got around to coding a bootloader for this project.
I'm posting version 0.1 here for reference. Lots of times people seem to have trouble with bootloaders (I put off writing one for ages) But this should show you can start simple, and optimise later.
The code right now is very rough. But is written in a way that could allow updating of itself it the help of a bootstrap Application. ie: Load new application which when run loads a new bootloader. This bootloader isn't 100% fool proof, if a bad app is loaded that fails to perform as a USB MSC then the user cannot use the USB port to load a new firmware file. but the SD can always be removed and a file copied from a PC if required. Worst case a debugger is required (Which is how they run right now)
Memory Map
Here is the memory map I've adopted. The bootloader fits at the top of FLASH, the default reset vector always runs the bootloader.
The bootloader uses petiet FatFS to read "firmware.bin" off an SD card. It checks the file integrity with a CRC16 integrated into the firmware.bin file on a PC after it was compiled (last word of file). If the file is valid it check the current apps CRC, if they match then app runs. (Application already loaded). If they do not match the Application flash is erased and the new app loaded.
Running the Application
When launching the app it's CRC is checked to ensure it has loaded correctly. (This shouldn't happen, but you never know...) The App's Interrupt vectors are copied to top of RAM, and SYSCTL.SYSRIVECT is set. The address at the apps reset vector (0xDFFC) is called.
Application changes
Due to the construction of this bootloader the app needs to have a few changes made, specifically to the linker script.
Reduce FLASH boundaries to remove bootloader area Shift Interrupt Vectors to alternate location in flash. (the app doesn't need to know its vectors will be moved to RAM, they just need to be in a fixed location so the bootloader can do that) Remove top 128 bytes of RAM (This is where the new interrupt vectors go. but default this is where the stack is initialised. which will damage the interrupt vectors) Create .crc section (Ensure a fixed WORD is placed to hold our CRC value.)
I set up a build setting to output a Binary file format which I run through a simple C program to compute and fill the CRC value. These are all run automatically when the app is built.
Improvements
Reduce code size (I have a feeling an SD bootloader could squeeze under 4kb, right now it's at ~6kb) Improve speed, I'm not using the DMA, which could be used to improve speed (Update takes ~10s) Utilise High memory (Right now I'm not enabling the use of high memory, the MSP430F5514 has 17kb in >0x10000 address range.) High memory could be utilised to hold the bootloader this would free up (~7.5kb ) that the Main app could use. gpsLoggerBootloader_0.1.zip
-
timotet reacted to greeeg in GPS logger for a local Beagle club
This project was put on hold over the holidays. It's always a busy time, plus the club doesn't hold meets over summer.
But I have just completed another 10 units. More of the same, but thought you guys might enjoy some more photos.
I couldn't get the same batteries as the last batch, which were 650mAh, these have much smaller 220mAh. But this still provides about 4 hours of run time.
The uBlox GPS modules are a huge improvement. Even without the SAW filter in the RF path and the sub-optimal PCB size compared to the antenna. These find more GPS satellites faster than the G.top modules, plus they also use glonass which doubles the visible satellites.
-
timotet reacted to bluehash in FourThreeOh wins TI Community Highlight of the Year Award for 2016
Thanks @Rei Vilo.
To all, the award goes to you too. Thanks for being wonderful members.
-
timotet reacted to Rei Vilo in FourThreeOh wins TI Community Highlight of the Year Award for 2016
Well deserved, congratulations Gerard!
-
timotet reacted to maelli01 in micropower microvoltmeter with MSP430FR4133 and MCP3422 ADC
Weekend-project:
Autoranging microvoltmeter based on the MSP430FR4133 launchpad.
ADC used: MIcrochip MCP3422, an 18bit, 3.75 sample/second Sigma Delta with 2 differential inputs. I2C interface
This nice little chip contains a programmable amplifier (x2,x4,x8) and a not-too-bad internal reference of 2.048V.
Max input range is +/-2.048V, resolution (8x amplified) is 2uV.
Hand-etched a single layer PCB which goes on top of Launchpad.
Type K cable in hot water: 2.93mV, 73Kelvin temp difference to ambient
compare with my Fluke 289, 0.06% (datasheet says 0.05% typical, 0.35% max)
Not too shabby for a chip that costs 3 bucks.
Current consumption: on average <40uA, the whole setup would run 5000hours from a CR2032
The ADC does 1 sample/second and sleeps the rest of the time, the MSP430 does what it likes the most: sleep in LPM3
Code is not a big deal, quick hack based on the FR4133 examples, for the LCD and for the I2C interface
//microvolt meter with MCP3422 and MSP430FR413 //****************************************************************************** #include <msp430.h> #define LCDMEMW ((int*)LCDMEM) #define pos1 4 // Digit A1 - L4 #define pos2 6 // Digit A2 - L6 #define pos3 8 // Digit A3 - L8 #define pos4 10 // Digit A4 - L10 #define pos5 2 // Digit A5 - L2 #define pos6 18 // Digit A6 - L18 const char digit[10] ={ 0xFC, // "0" 0x60, // "1" 0xDB, // "2" 0xF3, // "3" 0x67, // "4" 0xB7, // "5" 0xBF, // "6" 0xE0, // "7" 0xFF, // "8" 0xF7 // "9" }; volatile long voltage; unsigned long dvoltage; unsigned char TXByteCtr; unsigned char TXData; unsigned char newgain,gain; void Clear_LCD(){ int i; for(i=5;i;i--) LCDMEMW[i]=0; LCDMEMW[9]=0; } int main( void ) { WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer P1OUT = 0x00;P2OUT = 0x00;P3OUT = 0x00;P4OUT = 0x00; P5OUT = 0x00;P6OUT = 0x00;P7OUT = 0x00;P8OUT = 0x00; P1DIR = 0xFF;P2DIR = 0xFF;P3DIR = 0xFF;P4DIR = 0xFF; P5DIR = 0xFF;P6DIR = 0xFF;P7DIR = 0xFF;P8DIR = 0xFF; P5SEL0 |= BIT2 | BIT3; // I2C pins // Configure XT1 oscillator P4SEL0 |= BIT1 | BIT2; // P4.2~P4.1: crystal pins do { CSCTL7 &= ~(XT1OFFG | DCOFFG); // Clear XT1 and DCO fault flag SFRIFG1 &= ~OFIFG; } while (SFRIFG1 & OFIFG); // Test oscillator fault flag // Disable the GPIO power-on default high-impedance mode // to activate previously configured port settings PM5CTL0 &= ~LOCKLPM5; CSCTL4 = SELMS__DCOCLKDIV + SELA__XT1CLK; // MCLK=SMCLK=DCO; ACLK=XT1 // Configure RTC RTCCTL |= RTCSS__XT1CLK | RTCIE; // Initialize RTC to use XT1 and enable RTC interrupt RTCMOD = 16384; // Set RTC modulo to 16384 to trigger interrupt twice a second // Configure LCD pins SYSCFG2 |= LCDPCTL; // R13/R23/R33/LCDCAP0/LCDCAP1 pins selected LCDPCTL0 = 0xFFFF; LCDPCTL1 = 0x07FF; LCDPCTL2 = 0x00F0; // L0~L26 & L36~L39 pins selected LCDCTL0 = LCDSSEL_0 | LCDDIV_7; // flcd ref freq is xtclk // LCD Operation - Mode 3, internal 3.08v, charge pump 256Hz LCDVCTL = LCDCPEN | LCDREFEN | VLCD_5 | (LCDCPFSEL0 | LCDCPFSEL1 | LCDCPFSEL2 | LCDCPFSEL3); LCDMEMCTL |= LCDCLRM; // Clear LCD memory LCDCSSEL0 = 0x000F; // Configure COMs and SEGs LCDCSSEL1 = 0x0000; // L0, L1, L2, L3: COM pins LCDCSSEL2 = 0x0000; LCDM0 = 0x21; // L0 = COM0, L1 = COM1 LCDM1 = 0x84; // L2 = COM2, L3 = COM3 LCDCTL0 |= LCD4MUX | LCDON; // Turn on LCD, 4-mux selected (LCD4MUX also includes LCDSON) Clear_LCD(); // Configure USCI_B0 for I2C mode UCB0CTLW0 |= UCSWRST; // Software reset enabled UCB0CTLW0 |= UCMODE_3 | UCMST | UCSYNC; // I2C mode, Master mode, sync UCB0CTLW1 |= UCASTP_2; // Automatic stop generated // after UCB0TBCNT is reached UCB0BRW = 0x0008; // baudrate = SMCLK / 8 UCB0I2CSA = 0x0068; // Slave address UCB0CTL1 &= ~UCSWRST; UCB0IE |= UCRXIE | UCNACKIE | UCBCNTIE | UCTXIE0; while(1){ // P1OUT |= BIT0; TXByteCtr = 1; // Load TX byte counter TXData = 0x8C+gain; while (UCB0CTLW0 & UCTXSTP); // Ensure stop condition got sent UCB0CTLW0 |= UCTR | UCTXSTT; // I2C TX, start condition // P1OUT &= ~BIT0; __bis_SR_register(LPM3_bits | GIE); // timer will wake me up // P1OUT |= BIT0; UCB0TBCNT = 0x0003; // 3 bytes to be received voltage=0; UCB0CTLW0 &= ~UCTR; while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent UCB0CTL1 |= UCTXSTT; // I2C start condition __bis_SR_register(LPM3_bits | GIE); // I2C irq will wake me up voltage<<=8; // shift to left corner to do the sign correctly voltage/=32; // calibration is done here: 2048 in an ideal world if ((voltage<400000)&&(voltage>(-400000))){ // autoranging, downshift if (newgain<3) newgain++; } if ((voltage>1000000)||(voltage<-1000000)){ // autoranging, upshift if (newgain) newgain--; } voltage>>=gain; gain=newgain; if ((voltage<500000)&&(voltage>-500000)){ voltage*=10; //low range LCDMEM[11]&=~1; //adjust decimal point LCDMEM[9]|=1; } else{ //high range LCDMEM[9]&=~1; //adjust decimal point LCDMEM[11]|=1; } voltage*=25; voltage/=128; if (voltage<0) {dvoltage=-voltage; LCDMEM[5]|=4 ;} //negative else {dvoltage= voltage; LCDMEM[5]&=~4;} //positive LCDMEM[pos1] = digit[(dvoltage / 100000)%10]; LCDMEM[pos2] = digit[(dvoltage / 10000)%10]; LCDMEM[pos3] = digit[(dvoltage / 1000)%10]; LCDMEM[pos4] = digit[(dvoltage / 100)%10]; LCDMEM[pos5] = digit[(dvoltage / 10)%10]; LCDMEM[pos6] = digit[dvoltage % 10]; // P1OUT &= ~BIT0; __bis_SR_register(LPM3_bits | GIE); // timer will wake me up } } #pragma vector = RTC_VECTOR __interrupt void RTC_ISR(void){ switch(__even_in_range(RTCIV, RTCIV_RTCIF)){ case RTCIV_NONE: break; // No interrupt case RTCIV_RTCIF: // RTC Overflow __bic_SR_register_on_exit(LPM3_bits); break; default: break; } } #pragma vector = USCI_B0_VECTOR __interrupt void USCIB0_ISR(void){ switch(__even_in_range(UCB0IV, USCI_I2C_UCBIT9IFG)){ case USCI_NONE: break; // Vector 0: No interrupts case USCI_I2C_UCALIFG: break; // Vector 2: ALIFG case USCI_I2C_UCNACKIFG: // Vector 4: NACKIFG UCB0CTL1 |= UCTXSTT; // I2C start condition break; case USCI_I2C_UCSTTIFG: break; // Vector 6: STTIFG case USCI_I2C_UCSTPIFG: break; // Vector 8: STPIFG case USCI_I2C_UCRXIFG3: break; // Vector 10: RXIFG3 case USCI_I2C_UCTXIFG3: break; // Vector 14: TXIFG3 case USCI_I2C_UCRXIFG2: break; // Vector 16: RXIFG2 case USCI_I2C_UCTXIFG2: break; // Vector 18: TXIFG2 case USCI_I2C_UCRXIFG1: break; // Vector 20: RXIFG1 case USCI_I2C_UCTXIFG1: break; // Vector 22: TXIFG1 case USCI_I2C_UCRXIFG0: // Vector 24: RXIFG0 voltage=(voltage<<8)+UCB0RXBUF; break; case USCI_I2C_UCTXIFG0: // Vector 26: TXIFG0 if (TXByteCtr){ // Check TX byte counter UCB0TXBUF = TXData; // Load TX buffer TXByteCtr--; // Decrement TX byte counter } else{ UCB0CTLW0 |= UCTXSTP; // I2C stop condition UCB0IFG &= ~UCTXIFG; // Clear USCI_B0 TX int flag } break; case USCI_I2C_UCBCNTIFG: // Vector 28: BCNTIFG __bic_SR_register_on_exit(LPM3_bits); break; case USCI_I2C_UCCLTOIFG: break; // Vector 30: clock low timeout case USCI_I2C_UCBIT9IFG: break; // Vector 32: 9th bit default: break; } } -
timotet reacted to lawrence_jeff in Launchpad USB example and documentation additions/labs
Its been long enough that I would have to take a look to figure it out - can you post your code? Or email lawrence underscore jeff at hotmail.
-
timotet reacted to lawrence_jeff in Launchpad USB example and documentation additions/labs
For those of you attempting to build USB devices I put together some Launchpad examples as well as a lab type walkthrough of how to create custom devices (mainly HID)
Included
1) Examples ported to the Launchpad - Mouse, Keyboard, Composite
2) Updated HID header file with additional device and usage types
3) A new device type called usbdhidcustom - This allows you to make new devices with minimal code changes
4) A complete document in lab type format where you build a volume control device, a gamepad and a keyboard + mouse
5) Completed projects to go with the labs
StellarisWare.zip
-
timotet reacted to will in Temperature & Humidity sensor -with LCD & RF
Hi everyone, this is my credit card size wireless sensor node,
with a 7-seg LCD display showing temperature & humidity, update every second.
using MSP430FR4133 with HDC1080,BMP180 and OPT3002,
transmit by nRF24l01, which sends out temp,humid,pressure,luminosity and also battery voltage per minute.
It is all power by a CR2032, and thanks to MSP430FR4133, I can manage to have half an year battery life.
also thanks to MSP430RF4133 Launchpad with build-in energyTrace, I can estimate battery life with a click(no more oscilloscope )
note that I've actually put an RF430 on the down left ot the board(there is an antenna for that),
which will act as a NFC tag, but it draws too much current (~15uA), so I took it off
and at the down right is the battery voltage measurement with a mosfet to cut the power,
but I found out that I can just measure internal voltage reference to calculate its supply voltage, so I've also remove that.
although I'm pretty much satisfy with this power consumption, but I still think that 16.5uA is a little bit too far from estimating from datasheet
and I am still trying to figure that out
-
timotet reacted to greeeg in GPS logger for a local Beagle club
Polyurethane parts have come up nicely.
Main advantages of this method of rapid prototyping
Part cost is low these use about $0.05 of polyurethane resin. Parts can easily be coloured using dyes. (as demonstrated) Very little time needed for each cast (about 5 minutes) 1-2 Hour cure time 1-1 replica to original part. Of course you need to invest the time and money to make the silicone molds to begin with. So for a single part 3d printing is often the preferred approach.
The parts are a perfect fit over the button and LEDs.
-
-
timotet reacted to greeeg in GPS logger for a local Beagle club
Got my enclosures today. That means I now have all the hardware parts for this batch.
I've been playing around with Fusion 360 instead of Rhino, mainly due to the integrated CAM processor. Also it has easy to use rendering stuff out of the box too.
This is the reason I love companies that provide 3d CAD files. I can define some simple stroke text, and Fusion 360 will project it over the 3d curvature of the part.
My CNC setup is in dis-array. The setup is sub optimal.
But I think the results speak for themselves.
I want to experiment with filling the engravings with a paint to make them stand out.
-
timotet reacted to terjeio in Compact command parser/dispatcher example
A command parser/dispatcher example from my CO2 laser engraver codebase, using a struct array containing the commands and associated pointer to functions. A lot cleaner (and easier to maintain) than switch/case statements or if/else constructs...
Functions get called with a pointer to the command tail for local parameter parsing.
The struct array data are all placed in flash.
typedef struct { char const *const command; bool (*const handler)(char *); const bool report; } command; bool query (char* params); bool start (char* params); bool moveXrel (char* params); bool moveYrel (char* params); bool moveZrel (char* params); bool XHome (char* params); bool YHome (char* params); bool ZHome (char* params); bool XYHome (char* params); bool zeroAllAxes (char* params); bool laser (char* params); bool setLaserPower (char* params); bool setImageDPI (char* params); bool setPulseDutyCycle (char* params); bool enableCoolant (char* params); bool enableAirAssist (char* params); bool setMode (char* params); bool getPosition (char* params); bool setPPI (char* params); bool setPulseWidth (char* params); bool enableExhaustFan (char* params); bool setEngravingSpeed (char* params); bool getStatus (char* params); bool setEchoMode (char* params); bool setAMode (char* params); bool setPWROffset (char* params); bool loadProfile (char* params); bool setXBcomp (char* params); void exeCommand (char *cmdline) { static const command commands[] = { "?", &query, true, "Power:", &setLaserPower, true, "DutyCycle:", &setPulseDutyCycle, true, "PulseWidth:", &setPulseWidth, true, "DPI:", &setImageDPI, true, "Start:", &start, true, "X:", &moveXrel, true, "Y:", &moveYrel, true, "Z:", &moveZrel, true, "HomeXY", &XYHome, true, "HomeX", &XHome, true, "HomeY", &YHome, true, "HomeZ", &ZHome, true, "ZeroAll", &zeroAllAxes, true, "Laser:", &laser, true, "Coolant:", &enableCoolant, true, "Air:", &enableAirAssist, true, "Mach3:", &setMode, true, "Pos", &getPosition, false, "PPI:", &setPPI, true, "Exhaust:", &enableExhaustFan, true, "Speed:", &setEngravingSpeed, true, "Status", &getStatus, false, "ASelect:", &setAMode, true, "PWROffset:", &setPWROffset, true, "LoadProfile:", &loadProfile, true, "XBComp:", &setXBcomp, true, "Echo:", &setEchoMode, false }; bool ok = false; uint32_t i = 0, numcmds = sizeof(commands) / sizeof(command), cmdlen; while(!ok && i < numcmds) { cmdlen = strlen(commands[i].command); if(!(ok = !strncmp(commands[i].command, cmdline, cmdlen))) i++; } if(ok) { ok = commands[i].handler(cmdline + cmdlen); if(commands[i].report) serialWriteLn(ok ? "OK" : "FAILED")); } else serialWriteLn("Bad command"); } For further reading see http://www.barrgroup.com/Embedded-Systems/How-To/C-Function-Pointers
-
timotet reacted to terjeio in PCB Laser Exposer/Printer
Here are the files for my PCB Exposer/Printer, it is the complete package including mechanical design files.
The printer itself.
Example - a power control PCB for Raspberry Pi - 40 x 40 mm.
Code includes driver for MCP4725 DAC, buffered serial port driver, stepper motor control and command parsing for the MSP430G2553 used as the main controller.
Code and design files:
PCB Exposer - controller code for MSP430G2553.zip
PCB Exposer - desktop application.zip
PCB Exposer - mechanical design files in Vectric format.zip
PCB Exposer - schematics and PCBs.zip
Desktop application is coded in C#, schematics and PCBs in KiCad format.
There is some more information to be found in this tread:
http://forum.43oh.com/topic/4990-what-are-you-doing-right-now/page-5
Terje
-
timotet reacted to Rei Vilo in RANT: Cloud of this, IoT of that . . .
Every new year comes with a new fad.
A couple of years ago, it was 3D printer. Then it was quadcopter. Now it is IoT.
From my perspective, IoT is a rash of technology still looking for the killing app.
IoT paramount? A guy checking a dashboard with a tablet on the seaside.
Not to forget the magic IoT is supposed to bring to every dumb things and make them smart.
Smart phones, smart watches, smart cars, smart cities, maybe smart guys?
And greenery as an extra bonus.
-
timotet reacted to Fmilburn in Have you experienced a chilling effect?
I got involved with this community essentially knowing nothing about microcontrollers or C/C++ when I retired as an engineering manager with a mechanical background (in Calgary by the way - one of my favorite places). Microcontrollers were just something that caught my interest after viewing a TED video on Arduino. And on average, the quality of the projects and the help / discussion just seemed to be on a higher level on 43oh than with the Arduino crowd.
For me, learning this stuff beyond the superficial on my own outside of a classroom setting and without colleagues is hard. But it has been rewarding and a great experience. And I have learned something from each of you who have posted above. So, my thanks to you.
This is just a hobby for me, and it is unlikely anyone developing a commercial product is going to gain much from my advice . Having said that, I try to give as much as I take. And a good way to learn and hopefully help others has been to read the problems others are having and see if I can solve them. For those who would like to continue getting that kind of help, here are some tips:
Don't abuse the goodwill of 43oh members in the manner described above Search and make a real effort to solve it yourself first Post sufficient information for someone to help solve the problem but be as succinct as possible and don't post a 100 lines of code Use the thanks button when someone helps - really, how much effort does that take? Somebody just spent personal time to help you for free. When your problem is solved, consider editing your first post and put [sOLVED] in the title, or at least follow up with a post that you finally got it to work and how. The next person with that problem will thank you. My son-in-law has a masters in EE and is now a patent attorney. I asked him a while back about the practicalities of protecting intellectual property for the small guy or hobbyist. My interpretation of that conversation was that unless you have money and/or time it is difficult. A shame, the result is that you must do something like Spirilis suggests and carefully consider/tier responses, help, and what is revealed.
I appreciate the help past and future, and enjoy hearing about the projects. But, I also understand the sentiments expressed above and don't want to see livelihoods threatened.
-
timotet reacted to Rickta59 in Have you experienced a chilling effect?
I have some of the same feelings zeke.
What I've done is to only dole out information in real time using IRC. This allows me to gauge who is looking for the information and why. If it is for commercial use I just ignore them. If it is a lazy student, I especially ignore them. If it someone like me, just looking to find out the information for their own benefit, I share freely.
-rick
-
timotet reacted to greeeg in Decoupling cap: small but beautiful (and necessary)
It doesn't sound right to me calling capacitors on signal lines "decoupling capacitors" sounds more like you've created an RC filter. With the R being the gate resistance of the driver behind the IO pin.
What you're actually seeing is the effects of transmission line theory! Basically when a digital signal changes state very quickly (slew rate, or edge rate) it creates harmonics. On modern chips, even slow (by clock rate) micro controllers, that can span into the 100MHz range. This basically oscillates in your PCB tracks due to their inductance causing ringing on the edges due to reflections from impedance mismatch. If this ringing is bad enough then you will get data corruption.
Adding a series resistor helps, because if you picture your PCB tracks or wires as transmission lines then the resistor acts to impedance match between the IC pins and your PCB tracks. a 50 ohm resistor is ideal for a 50 ohm transmission line.
Here is a quick primer that very concisely explains the basics of this stuff if you don't have a strong EE background.
-
timotet reacted to greeeg in ledClock - dual colour led matrix
Hey Guys,
Exam times again, so I feel like I have a tonne of time for my projects.
This is a project I started in February 2014. I found a very nice 8x8 dual colour LED display. I designed a PCB for them when I ordered them, instead of when I actually had them.
I had built a PCB up with a G2542 8kb / 512b (Mem/RAM) but didn't manage to get it working.
Over the last few weeks I got back into this project, and low and behold it did actually work!!
I built up a new PCB because it was designed as a common cathode driver, but the displays were common anode.... (on the first board, I had bridged the common mosfets.)
of course using 0402 parts. (this display need 64 of these O_O)
back of PCB contains clock, half a DCDC stepup and a BMA222 accelerometer.
Front & back
Now I needed a case, this is my first project I decided to actually make use of a cheap chinesse laser cutter I now own.
The piece with all the slits in it create a "living hinge" which creates a cool organic looking case. as opposed to a rectangle.
I'm still working on improving code. Basic clock functionality is in.
lastly I'll leave you with my dud designs. which while not very practical. are actually 100% useful. A failed design can teach you alot!
I will be making this open source, I would like to make more in the future, which may involve buying more displays from china (if there is interest maybe even a group buy?? )
-
timotet reacted to terjeio in Multimedia Center
PCBs for the controller has now arrived from China, no routing errors! However I have some problems with the KeyStone DAB-module, I cannot get it to respond like the development board which works flawlessy - not good. The DAB module is on the preamp board, I have to delay sending it off for fabrication this until this is resolved.
The controller is performing well, her are a few pics - code will follow later when I am happy with it:
Frame is milled from 10mm solid aluminium.
Assembled controller board, touch sensors are home-made - a bit of black art to get them working reliably when embedded in the aluminium block.
Not too bad for beeing a prototype, I have to allow for some adjustment of the "wheel" - or find a way to perfectly align the alu block after turning it around to mill the front.