Jump to content

elpaso

Members
  • Content Count

    66
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    elpaso reacted to juanb in Digital Thermographic Camera   
    Hi everyone,
    My name is Juan Beroy from John Brown Univeristy and this is my final project for my embedded systems class.
    The objective of this project, the Digital Thermographic Camera, is to demonstrate the usage of the Texas Instruments MSP430 G2553 microcontroller to control the various parts of the project. The project consists of two servo motors, a set of DC batteries, a MLX90614ESF-BCI-000-TU infrared sensor, as well as a RS-232 serial connection to establish connection with the computer. The signals used to control the servo motors are sent using two different pins of the microcontroller. At the same time, the Inter Integrated Circuit (I2C) synchronous communication mode was used to read the data (temperature measurements) coming from the infrared sensor.
    Attached is a table summarizing the main conmponenents of this project as well as their purposes. If you need more info please contact me.

    Projects parts table.pdf
  2. Like
    elpaso reacted to TI_Trey in Quadcopter BoosterPack   
    Here's a little more information on how its setup:
     
    4x TMS320F28027F + DRV8312 make up the ESC.  That is the bulk of what is on the board which you can see on the first post.
    1x C2000 LP acts as the brain.  This board decodes the control signals and sends torque commands to each of the ESCs via a PWM signal.  This LaunchPad runs the open source AeroQuad firmware on top of Energia...which also means other LaunchPads could be used as the brain.
    Control Inputs come via a standard RC 2.4GHz radio and receiver.  Because the LaunchPad doesn't have 1 million capture inputs I am using a receiver which supports S.Bus.
    3 axis accelerometer, gyro, magnetometer, barometer and GPS
     
    I agree that for efficiency it would be better to integrate the "brain" microcontroller on board and do away with the headers, but part of the cool factor of this is the open source nature and the ability to share boosterpacks between the different LaunchPads.
     
    I'll post some pictures of the boards when I get them next week.
  3. Like
    elpaso reacted to pabigot in Wolverine Launchpad   
    Here's your reverse function:
    static unsigned char reverse (unsigned char i) { unsigned char rv; __asm__ __volatile__ ("rlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" "\trlc.b\t%1\n" "\trrc.b\t%0\n" : "=&r" (rv) /* Output must be register, is write-only and clobbered */ , "+r"(i) /* Input is register and is mutated */ : ); return rv; } The main problem with your original is that MSPGCC ABI requires that the input argument is passed in R15, and the output is returned in R15.

    See the gcc constraint modifier documentation.
  4. Like
    elpaso reacted to pabigot in Wolverine Launchpad   
    I did a total slash and burn of slac645 and tracked down the problem: two incompatible rules to build object files, one of which actually built an executable. I have no idea whether it would run; I won't be trying out this board until later this week.
     
    Diffs for a Makefile that fixes the link issue are at: https://gist.github.com/pabigot/9235449/revisions
     
    Some of the changes are irrelevant; you probably only need the one that comments out the %o rule.
     
    Good luck.
  5. Like
    elpaso reacted to pabigot in Wolverine Launchpad   
    Assuming we're still talking about this error:
     Linking main.elf ~/energia-0101E0010/hardware/tools/msp430/bin/msp430-gcc -mmcu=msp430fr5969 -Wl,-Map=main.map main.o .lib/lib.a -o main.elf main.o:(.vectors+0x0): multiple definition of `__ivtbl_64' ~/energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/mcpu-430x/mmpy-16/crt0ivtbl64.o:(.vectors+0x0): first defined here ~/energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: main.elf section `.vectors' will not fit in region `vectors' ~energia-0101E0010/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: region `vectors' overflowed by 128 bytes collect2: ld returned 1 exit status make: *** [main.elf] Errore 1  
    then in theory it's fixed by figuring out who's putting two definitions of __ivtbl_64 into that link line. Normally it should be coming from crt0ivtbl64.o, which mspgcc adds, so presumably there's another in .lib/lib.a (or, somehow, main.o).  There should be no reason to touch linker scripts; the interrupt issue is not relevant unless you're using one of the affected versions of msp430mcu (none of which were ever approved for use with an LTS or development version of mspgcc; if energia updated to one of those, it probably wouldn't work at all).
     
    I'll be getting my EXP430FR5969-LP probably today, so will be able to check things out soon (though I normally use an internal development version of mspgcc so my results may not apply).
  6. Like
    elpaso reacted to spirilis in Wolverine Launchpad   
    I don't think mspgcc supports Wolverine at all in no small part due to interrupt vector table changes in the chip over previous MSP430's. Peter Bigot knows the details there but don't expect anything. I'm not getting excited about Wolverine until RedHat's GCC port is more stable.
     
    Sent from my Galaxy Note II with Tapatalk 4
     
     
  7. Like
    elpaso reacted to greeeg in Wolverine Launchpad   
    @@elpaso Looks to me that your mspgcc doesn't have the linker files for the 5969.
    can you check? you should have these files
     
    msp430/include/msp430fr5969.h
    msp430/lib/ldscripts/msp430fr5969/memory.x
    msp430/lib/ldscripts/msp430fr5969/periph.x
  8. Like
    elpaso reacted to cubeberg in Christmas PCB   
    @@elpaso - sorry for the delay - here are high-resolution images of the board, front and back.  
    The blue resistors are the larger value resistors for the red LEDs, the brown ones are for the green LEDs.  I believe I included different colors with yours, but this way you know where they go
    The larger capacitor goes on the right, smaller on the left.  I'll check the markings so that you know which is which.


  9. Like
    elpaso reacted to energia in New Energia release 0101E0011 - 12/17/2013   
    I am happy to announce that release 0101E0011 just went up on energia.nu.    I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!   The highlights are: Lots of bug fixes Major update to the CC3000 WiFi BoosterPackLibrary for the MSP430F5529 and TivaC/Stellaris LaunchPad Updated ARM tools to gcc-arm-embedded Initial C2000 support (thanks to Trey German for all his hard work on getting Energia ported to the C2000) CCSv6 Energia Sketch import Support for MSP-EXP430G2 LaunchPad Support for MSP-EXP430F5529LP LaunchPad Support for EK-TM4C123GXL (TivaC) LaunchPad Support for EK-LM4F120XL (Stellaris) LaunchPad Runs on Windows (XP/7/8), Mac OS X and Linux (32/64 bit) Happy Making!
     
    Robert
  10. Like
    elpaso reacted to bluehash in 43oh just crossed 20,000 members!   
    Congratulations and  thank you all! 
    We just crossed 20,000 members yesterday. Happy to say we seem to be a healthy, well behaved community with no bans or crazy fights... very rare on a forum of this size. Thank you again for sharing your posts, thoughts, pictures, projects, threads and not to forget members who make it a point to welcome new comers.
     
    - Team 43oh.
  11. Like
    elpaso reacted to Automate in Chronos: (open) where to start?   
    Congrats, you made DP.  http://dangerousprototypes.com/2013/12/03/ti-ez430-chronos-watch-getting-started-on-custom-firmwares/
  12. Like
    elpaso reacted to petertux in Chronos: (open) where to start?   
    happy birthday
     
    regarding your question, it depends of what you intend to do.
     
    'openchronos'  is more in line with the original sourcecode, they patched the original code to compile with mspgcc. complete with SimpliciTI stack for wireless comms. the bluerobin stuff was dropped due to too much blobbiness.
     
    'openchronos-ng' is more of a complete rewrite, it's much more modularized which makes the code much easier to understand and to tweak by users. the only problem is that not all of the features were ported. there is no SimpliciTI in this fork, but you can switch to the 'swap' git branch that includes code for the swap stack [1] if you need to talk to the outside world.
     
    so if you want to slightly tweak the original code go with the first one, however if you want to implement new ideas definitely go with '-ng'.
     
    [1] http://code.google.com/p/panstamp/wiki/SWAPchronos
  13. Like
    elpaso got a reaction from bluehash in Chronos: (open) where to start?   
    Ok, I did start and wrote a few notes for those who are willing to start hacking this watch under Linux:
     
    http://www.itopen.it/2013/11/28/the-hackable-watch-a-wearable-msp430-mcu/
     
    Comments, corrections and suggestions are always welcome!
  14. Like
    elpaso reacted to enl in How to calc this resistor ?!   
    Detailed explanation:
     
    There are several types of power supply, but the type most often seen in the consumer and electronics world  is constant potential (constant voltage). The current specification is the MAXIMUM current it will supply at the specified voltage (give or take... sometimes the voltage will drop a bit before the current rating is reached, sometimes there is a little leeway), but the voltage is, nominally, fairly constant for most types.
     
    Most important is the type of supply...
     
    Presuming that the supply is a DC supply, three main types exist. Unregulated, linear regulated, and switching.
     
    Most wall wart types are unregulated or switching, thought there are a few linear regulated in the wild.
     
    Unregulated may provide much higher than rated potential at lower than rated load, and are generally not very stable, with a lot of noise (typically at 100 or 120 cycles per second, depending on line frequency, and up to 50% or more voltage at full load), and should not be used with devices requiring regulated supplies.
     
    Switching are pretty tightly regulated, and generally cut out (drop to near zero output) if the rated current is exceeded by more than a few percent. Within the rated current, they drop very little with load and have moderate to low noise -- maybe less than a percent -- at high frequency (10 KHz to 1MHz). Some types may not regulate with less than a few percent load, so ALWAYS load these at 10% or so current when testing them, and be careful when using to power low loads. For low loads -- less than about 10% rated -- check with a dummy load to be sure that it regulates. Use an oscilloscope, as the overvoltage may be pusles to pretty high potential, with average potential looking ok on a meter. This isn't as big a problem with modern supplies as with the units from the 70's through the 90's, but some of the no-name and counterfeit units from the far east are pretty bad.
     
    linear are typically the least noisy, but not as efficient as switching types. They may have a little more variation over load than switching, in the simpler ones, but can be significantly more stable than switching in the higher quality designs. They tend to drop off more gradually at overload, and usually are conservatively rated, tolerating a few to 20% overload, at least for a brief period, without dropping from specified voltage. They generally regulate well down to zero load, but some may have stability issues with loads that are principally inductive or capacitive. Then again, so can switchers.
     
    -----------------
     
    If the original supply was regulated, and the new one is (switching or linear), no issue.
     
    If the original was unregulated, or the new one is, then you need to do some work to be sure, but are likely ok. If the old one was, the new one should be fine as long as the device powered wasn't relying on the supply limiting current.
     
    If the new one is unregulated, DO NOT use it. You will likely have a problem.
     
    If old and new are both regulated, no dropping resistor needed and all should be good.
     
    ------------------------
     
    Additional info: many older (1970's and 1980's) supplies were unregulated and were designed to work with a particular load. The transformers in much consumer grade product used saturation limiting in the transformer for protection from overload (often no fuse or thermal protection was used... sat limiting met the requirements for certification by UL and other ratings agencies if the primary wire could safely burn on a primary short... still find devices like this even today) The saturation limiting also provided a controlled drop under load, and a nominal 5V supply might show 8 or 9V open circuit, dropping fairly linearly to 5V at rated load, and limiting current at not much more due to transformer saturation. These types of unit ARE NOT suitable for modern electronices, are not that safe, and should not be used with anything other than the devices they were designed for. Back in the 90's a ton of Coleco and other similar wall warts came on the surplus market that fall into this category, as well as a bunch of cord-and-brick supplies. Lost a lot of gear to unclueful power suppply replacement. Mostly other people doing it, as after the first time, I learned (but still managed to lose a really nice frequency counter to my not looking at the supply. Right connector, so I went with it. Poof!)
     
    More info, since I have diherria of the typing finger (and it is frigid and windy here):
     
    The other type of supply is constant current. They tend to be seen as blocks in circuits (op amps use them by the bucketful internally), but are sometimes seen in high power applications. There are parts of the world (eastern europe and rural US, in particular) where costant current street lighting is still used. The lamps then don't need individual ballasts, but must fail electrode shorted at end of life.
     
    Yet more info: MIG and fluxcore (wire feed) welding is constant potential. Stick (SMAW/MMA) and TIG (GTAW) welding are constant current. Neither is true constant, and true constant potential or constant current makes for a very difficult to control process. Real welding sources have some 'droop', to allow for an equilibrium to be established with inherent negative feedback for control. This holds true for both manual and automated processes, though automated processes are often held to a flatter curve.
     
    ----------------
     
    Cat got off my lap, so I'll stop now....
  15. Like
    elpaso reacted to grahamf72 in Building low power into Energia   
    I've had a little bit of a play, and have made up a few libraries for basic LPM support. These libraries are based on the Energia core files, but take advantage of the fact that the Energia linker gives a higher priority to libraries than to the core, consequently if you add these libraries to your sketch, they will be used seamlessly instead of the core files.  The advantage of doing it this way, is that unless you add the library to your sketch, the standard core files are used, so there's no compatibility issues resulting from modifying the standard core.  I have also designed the routines so that they maintain total compatibility with the existing Energia framework.  Although I don't expect any insidious bugs, the code isn't thoroughly debugged, so if you do choose to use it, it is at your risk.  I have only tested on the 2553 & 2452 - perhaps someone with a 2231 or 5529 could test and modify if they feel so inclined.
     
    My replacement libraries are:
    LPMinterrupts - replaces the core Winterrupts.c.  The inbuilt pin handler now clears LPM bits on exit, so you can go to LPM4 and have your program wake up after a pin interrupt occurs.  Also I've added a couple of functions "waitForAnyPin" and "waitForPin" that allow you to pause execution at a set low power mode until a pin interrupt occurs, with an optional timeout.
     
    crystalWDT - replaces the basic timer core in wiring.c with a version that uses the 32.768 crystal instead of SMCLK. This reduces the resolution of millis & delay, but allows the use of LPM3 timed delays. I have enhanced the delay function to take an optional parameter specifying the low power mode.  In addition I have also added a seconds() function which gives the number of seconds since startup. It takes about 136 years for seconds() to roll over, compared to approx 50 days for millis().
     
    VLOclockWDT - replaces the core wiring.c with a version that uses the internal VLO clock. Again this allows the use of LPM3 timed delays but the VLO clock has poorer resolution and is not nearly as accurate as the standard SMCLK.  I didn't bother with a seconds() function here, as I don't believe the low accuracy of the VLO clock would make it useful.
     
    I have also attached a couple of basic sketches to demonstrate the functions in the libraries.  When I tested I found the following power consumption in the delay and waitForPin functions:
     
    LPM0 - 735uA
    LPM3 - 9uA
    LPM4 - <1uA (my meter read 0)
     
    These are just an idea that I'm throwing out into the open for people to look at, criticise, praise, use or delete as they desire. I'm not suggesting that it be the method ultimately used in Energia (although I'd be very flattered if it is).
     
     
    EDIT: Apparently some people are having trouble opening the zip - if it doesn't work, try the version attached a couple of posts down.
    lpm.zip
  16. Like
    elpaso reacted to Rickta59 in How to make a ROM image of a sketch for distribution   
    Why not zip up your source files so we can all learn something.
     
    -rick
  17. Like
    elpaso got a reaction from roadrunner84 in Building low power into Energia   
    Well, no, sorry, I mixed up things, I was thinking about misllis(), I meant that with current millis implementation, the millis stop counting in LPM, I would also like to have a millis() which still counts (from the chrystal) when in LPM.
     
    So, to summarize, I would like to see a LPM-delay and a LPM millis, I tend to use millis for debounching push buttons, if I go to sleep in the loop and attach an interrupt to a pin, currently I cannot use millis to debounce because it stops counting when sleeping.
     
    I would implement an RTC with an interrupt, but I usually get an external DS1388 to have battery backup.
  18. Like
    elpaso got a reaction from M-atthias in Accessibility keyboard for impaired people   
    @@simpleavr
     
    I'm not an ASCII artist   , please check if it's ok:
    /* Schematics Note: decoupling CAP and LDO are not shown // VCC (3.3V) // | // +------+ MSP430G2452/ // _ _ MSP430G2553 // |1| |4| --------------- // |K| |K| | XIN|--+ // |5| |7| | | [ ] 32.768KHz XTAL (optional) // - - | XOUT|--+ // | | | | __o__ // | +---|RST P2.0|--o o---o LEFT \ // | | | __o__ | | // +----------|P1.0 P2.1|--o o---o UP | // | | | __o__ | | // | +---|P1.1 P2.2|--o o---o CENTER CLICK > Mouse controls // _ _ | | __o__ | | // |6| |6| | P2.3|--o o---o RIGHT | // |8| |8| | | __o__ | | // |R| |R| | P2.4|--o o---o DOWN / // - - _|_ // | | /// // USB D+ D- // // */ I've also added an XTAL string to the end of the string descriptor:
    #ifdef USE_32768HZ_XTAL static const uint8_t String_Descriptor_2[] = { 30, 30, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4', 0, '3', 0, '0', 0 , ' ', 0, 'X', 0, 'T', 0, 'A', 0, 'L', 0 }; #else static const uint8_t String_Descriptor_2[] = { 20, 20, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4', 0, '3', 0, '0', 0 }; #endif just to be sure I've built and uploaded the right fw.
     
  19. Like
    elpaso reacted to simpleavr in Accessibility keyboard for impaired people   
    @@elpaso
     
    The "toggle_syncled" define in bbusb.h can be ignored. I will remove it when I check-in next time. We make bbusb.h from bbusb.inc for 'C' compiler, The toggle_syncled() is only used in bbusb_receive.S which is assembly and looks at bbusb.inc
     
    As for usb error, I only tried hid430 on win7 + cygwin.
     
    You can try editing hid430.c and change
     
    n = 40 to n = 80, and later
     
    n = 250 to n = 1000.
     
    If you look at boot430.c, it's using larger values.
     
    The larger values allow for more time to wait and calibrate the 1ms reset signal from the usb host.
     
    If you are trying both boot430 and hid430, may be also try to alway "make -f Makefile.hid clean" before "make -f Makefile.hid" since some objects are shared.
     
    As for your w/ Xtal build, you can temporary modify the line
     
      ;#error @simpleavr @[member=M-atthias] For the moment, detecting whether we are in bootloader or not with a crystal is not implemented.   by commenting it out, placing a ';' (semi-colon) in front. For hid430, this is really not needed as this is for sharing interrupt between bootloader and app.
     
    I will correct this later.
     
    I did, after checking in 0.91a, git clone everything fresh and tried both boot430 and hid430 on win7 + cygwin. I don't have crystal right now so I can only test the crystal version tomorrow.
     
    Keep us up-to-date if you encounter problems.
  20. Like
    elpaso reacted to simpleavr in Accessibility keyboard for impaired people   
    I've read thru briefly on your adventure. You had a very good start as many things works for you the 1st time.
     
    I had done the following in hope to support your good will project.
     
    I checked in boot430 v0.91a w/ the following changes.
     
    . I added Makefile.hid, bbusb_protocol_hid.c, hid430.c so we can build the simple "mouse" project that represents the original bbusb.c + etc.
    . I called it hid430 instead of bbusb as there is already a led project called bbusb in github, to avoid confusion.
    . I remove (commented out) the P1.4 SMCLK output and replaced syncled macro so there is no occupy of unnecessary pins.
    . The default build is NO crystal, although you can enable them via #define, but crystal build I did not verify.
    . Now one could "git clone" the project and do "make -f Makefile.hid" and "make -f Makefile.hid flash" to build and flash the "moving mouse" project.
    . A "hid430.hex" firmware hex file is also include for anyone who has a hardware setup but no build-chain to try things out.
    * the source code had been synced to the latest known bug free kind that I know of.
     
    Now for your project.
     
    . The hid430 would be a base and you can add button processing to it.
    . Myself also want the most simple solution and will try to avoid xtal where possible.
    . I had not test the USB connectivity for long connection time w/ no xtal option, but I think you should try.
     
    As no xtal option just syncs based on reset timing signal from PC, it syncs at startup, it then calibrate DCO based on that. When running after a while, the accuracy can be affected by the temperature of the environment. Whether it can, or for how long it can keep up the clock accuracy I don't know.
     
    But for simple applications, we could also use a "reset" button and once the "mouse" became not responsive, we could simply "reset" the device and start over again, with a new clock sync.
     
    Good luck to your project, let me know if I can of any help to your project.
  21. Like
    elpaso reacted to simpleavr in Bit-Bang USB on MSP430G2452   
    @@elpaso
     
    I had added hid example build within boot430 github repository. I did not make a separate project because it is easier for me.
     
    Since this is a usage of bbusb and not core bbusb functionality discussion, we should discuss this on your "mouse" thread.
  22. Like
    elpaso reacted to M-atthias in Bit-Bang USB on MSP430G2452   
    Good morning to Italy - I like your project a lot !

    Mecrimus-B already defines a mouse, it is constantly moving the pointer to the right, but adding buttons should be simple if you feel comfortable with assembly.
    Replace this sequence in Mecrimus-B-32768Hz.asm with button states - movements are 8-bit signed integers, moving to the left would be -1=255:

      mov.b #0, &Irq_In_Sendepaketpuffer+2 ; Buttons pressed
      mov.b #1, &Irq_In_Sendepaketpuffer+3 ; X movement
      mov.b #0, &Irq_In_Sendepaketpuffer+4 ; Y movement
      mov.b #0, &Irq_In_Sendepaketpuffer+5 ; Wheel movement

    Replace toggle_syncled with a 4 cycle nop, remove the clockout init code and change the PxDIR settings accordingly after Reset, and the debug signals are gone.

    toggle_syncled macro ; Preserve clock cycles if you want to remove this !
      xor.b #4, &P1OUT   ; Toggles Sync LED, good for triggering an oscilloscope and visual feedback
      endm

    toggle_syncled macro ; Preserve clock cycles if you want to remove this !
      nop2
      nop2
      endm

    Remove this: bis.b #010h, &P1SEL ; SMCLK an P1.4 ausgeben  SMCLK for measurements on P1.4

    Boot430 includes a lot of special code not needed for a mouse, and note that the bbusb package still contains a serious bug in its receiver code inherited from early Mecrimus-B, as this has been mostly a development shapshot. @@simpleavr Maybe you could repackage bbusb as a simple C starting point and replace the receiver with the Boot430's one which has the SE0-unstuff-bug fixed ?

    I understand that you are puzzled by now. USB support on MSP430 is still in an early stage, Boot430 is the first application and the most current piece which development is focussed on. Boot430 is based on the bbusb snapshots, and bbusb is an enhanced and improved C rewrite of Mecrimus-B, which is assembler only. I fixed all known bugs in Mecrimus-B, but it is a pioneer, and it has not received so much testing effort, high-level protocol support and functionality enhancements.

    Altough it will be possible in future, you have no choice but to use the 32768 Hz crystal for long-time stability at the moment. Mecrimus-B offers direct input of stable digital external 15 MHz or 18 MHz clock, but this is not what you search for.

    For a prototype, you can drop ESD protection, look at the pictures of my early msp430f2012 board and simpleavr's breadboard clone at the beginning of this thread to get an idea what is needed for a start.

    Best wishes for your project from Germany,
    Matthias
     
  23. Like
    elpaso reacted to M-atthias in Bit-Bang USB on MSP430G2452   
    Hello @@theprophet,

    if the crystal is in place, it helps to stabilize the DCO to 15 MHz by having a timer running in a software frequency locked loop which counts how many DCO ticks occour within one 32768/8 Hz tick and adjusts DCO in given direction. This helps in long time connections, as temperature changes which change DCO frequency are regulated away, but for the case of detecting, you can have the same check as in the crystal-free implementation, as the DCO will be in RSEL 15 tap, too. Personally, I would opt for an P1IE line bit check instead in both cases, as the target application might want to run with 16 MHz, which is also within the BCSCTL1 RSEL tap 15.

    Christian Starkjohann of V-USB has implemented a frequency locked loop on the USB protocol itself, basically every 1 ms there is a SE0 on the bus without transmitting a packet. This consumes a timer just as in the crystal variant and might be implemented by setting P1IE on the other USB line and checking for that if catching the sync pattern fails. This is called "Keep alive signaling" and occours always, not only after fresh connection as simpleavr uses this for initial clock setup. In Bootloader application, long time clock stability is not a concern, but if you are going to establish long-time connections as for your IR receiver, for example there may be a stream of warm air from ventilation with varying temperature that will cause the connection to break down over time.

    "Frames: On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet." http://www.usbmadesimple.co.uk/ums_3.htm See USB specification for more info.

    The "USB Tinkerer" is simply a small tribute in this forum for those having advanced USB usage on MSP430 :-)

    Matthias
     
  24. Like
    elpaso got a reaction from Rickta59 in Accessibility keyboard for impaired people   
    Ok, breadboard test completed thanks to the marvellous mecrimus-b, bbusb and boot430 project.
     
    It works fine.
     
    I started from bbusb_gcc from oPossumm and just changed a few lines to read the buttons.
    uint8_t MOUSE_BTN_CLICKED = 0; uint8_t centerClicked(){ if((P2IN & BIT2) == 0){ if(!MOUSE_BTN_CLICKED){ MOUSE_BTN_CLICKED = 1; return 1; } } else { if(MOUSE_BTN_CLICKED){ MOUSE_BTN_CLICKED = 0; return 0; } } return 0; } uint8_t horizClicked(){ if((P2IN & BIT0) == 0){ return -1; } if((P2IN & BIT3) == 0){ return 1; } return 0; } uint8_t vertClicked(){ if((P2IN & BIT1) == 0){ return -1; } if((P2IN & BIT4) == 0){ return 1; } return 0; } void MouseIrqIn(uint8_t *d) // { // -- Mouse HID response *d++ = 5; // Length // Data PID toggle *d++ = (Data_PID_ToggleIrqIn ^= (USB_PID_DATA0 ^ USB_PID_DATA1)); *d++ = centerClicked(); // Buttons *d++ = horizClicked(); // X *d++ = vertClicked(); // Y *d++ = 0; // Wheel } in main I've added:
    // ABP: mouse // Input Pull-up P2OUT = 0; P2SEL &= ~(BIT0 | BIT1 | BIT2 | BIT3 | BIT4); P2DIR &= ~(BIT0 | BIT1 | BIT2 | BIT3 | BIT4); P2REN |= BIT0 | BIT1 | BIT2 | BIT3 | BIT4; P2OUT |= BIT0 | BIT1 | BIT2 | BIT3 | BIT4; and called my  MouseIrqIn instead of the original.
     
     
     
     

  25. Like
    elpaso got a reaction from bluehash in Accessibility keyboard for impaired people   
    Hi,
     
    just a quick update, I've successfully breadboarded the boot430  https://github.com/simpleavr/boot430, USB works fine with M430G2452, I've also USB-uploaded  a test sketch (blink) and It works, even if it gives an error while uploading:
    device (2452), version (0.91), application end at (0xffff) firmware out of range for device 0xc000 < 0xe000 flash_start = 0xe000 range.. 0xe000 -> 0xe000 (0x0000) EDIT: commandline/boot430load . supports msp430g2553 only  but it seems to work on M430G2452 too...       At this point, I would like to build a mouse from this, any hint about where to start?
     
    I'm working with mspgcc on Linux, I don't want to use proprietary software so IAR and TI proprietary dev tools are not an option.
×
×
  • Create New...