lalalandrus
-
Content Count
16 -
Joined
-
Last visited
-
Days Won
2
-
yes it came with keyless entry, it just was cumbersome especially when the remote is the size of texas AND i fried my remote one day perhaps i should call this "proximity entry"
-
website states it requires 5v ttl which *should* work if you are using 3.3 cmos BUT you as rob said perhaps you need a 5v supply
-
clock the hardware spi faster and use both on the same bus. the csn should be able to take care of it. bitbanged spi can be quite fast, but then you just have no time to process anything else.... i posted this in another thread recently of a bit banged spi (CPOL and CPHA = 0 ) uint8_t spi_send(const uint8_t _data) { const uint8_t MOSI = BIT7; const uint8_t MISO = BIT6; const uint8_t SCK = BIT5; uint8_t data = 0; if (_data & 0x80) P1OUT |= BIT7; else P1OUT &= BIT7; __delay_cycles(10); for (int i = 0 ; i < 8 ; i++) { if (_data & (1 <&
-
In this day and age, we should not need to use any keys or buttons. I have done away with the key remote in my car using this simple setup. I came to the same conclusion as this gentlemen in using the apple nike+ sensor to provide a proximity sensor to the car. https://www.sparkfun.com/tutorials/135 His code lacks a couple things that I was looking for. 1) decoding of the apple serial protocol so that i can use any NRF module 2) detection of when to stop strobing the remote (when the key is inserted) 3) ability to open the trunk and since I can detect when the key is inserted,
-
the timer way is probably the way to go, but if you are short on timers, you can always use the WDT in interval mode...
-
one can implement a simple RC circuit to debounce as well. it is implemented on the launchpad for pin 1.3. look at the schematic another way to use once in the interrupt__delay_cycles(n) to debounce it n cycles within the interrupt, not the most efficient but it will do to get one started.
-
or get another launchpad or equivalent to talk to and take data from one serial port and pipe it out on the other. if the other chip doesnt have hardware serial, you can always bit bang it out. lots of examples on the web. crazier yet, loop it back to the same micro using the bit bang SPI code snippet for bit bang spi: (CPOL and CPHA = 0 ) uint8_t spi_send(const uint8_t _data) { const uint8_t MOSI = BIT7; const uint8_t MISO = BIT6; const uint8_t SCK = BIT5; uint8_t data = 0; if (_data & 0x80) P1OUT |= BIT7; else P1OUT &= BIT7; __delay_cycles(10);
-
the ftdi method only works if the bootloader (cfe.bin) is still intact. in my case my bjorked the boot partition in the flash chip and thus needed the nitty gritty jtag to restore it.
-
edited first post
-
final update: i was annoyed at how long it took, i have upgraded the protocols and now the jtag only takes 30 min to back up 256k notes: - baud rate slowed as the micro was unable to keep up (9600 probably wouldnt be that much slower and could use the application UART) - bytes transfered rather than bit banging - micro changed to a MSP435G2553 uploaded are the files i have modified main_new.c binary.h jt_mods.c jt_mods.h tjtag.c
-
yeah i am using an older msp430 kit so no 16Mhz calibrations and yes, the router is fixed but took literally days, backing up the 128k CFE took three days even though I didnt need it. wrtiting is a little faster at one-ish day. EDIT: new findings - the speed will double if you recompile tjtag-jtmod to disregard the ACKS from every write. - max serial speed is 160000 BAUD which will speed it another 50%
-
Playing around with my router and bricked it. Needed a JTAG but most are done with parallel ports. Google search brought me here to this project. http://sourceforge.net/projects/tjtag/files/v3.0.1-JTMOD/ I ported the code to a MSP430. Changing pinouts should be relatively straight forward in the DEFINES. Note that it uses 115200. The Launchpad application uart only supports 9600. To get 115200, you have to use an external serial cable (i used a FTDI cable). Also, it runs at 16MHz which requires you to do the DCO calibration and modify the msp430 includes to define the 16MHz sele
-
oh where to begin... i did a quick search and here are some notes i see you have a ton of wires soldered. try focusing on just the TX. GND and VCC from the GPS for now. (GPS TX to Launchpad RX and remove jumper) 1) it speaks UART yay! default baud rate is 9600 double yay! default outputs GPS and GSV NMEA data every second triple yay! 2) adapt the above code by using only the GPS decoding functions, then implement the serial functions to grab the data from the serial port 3) alternatively, load energia with the hardware and then use the GPS library from arduino, 4) hook up
-
try moving your flag clear as the first line into the interrupt. also as a good rule of thumb, you should disable interrupts while you are servicing one so you reduce race conditions. that is basically what my line does is disable interrupts entirely until you are good and ready .
-
try replacing the following LPM0_EXIT; with: _BIC_SR_IRQ(LPM0_bits + GIE)
