Jump to content
43oh

elpaso

Members
  • Content Count

    66
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    elpaso got a reaction from abecedarian in Accessibility keyboard for impaired people   
    Hi,
     
    this project is aimed to build a low-cost simplest possible accessibility keyboard using MSP430 (MSP430G2452?), I've built something with Attiny85 V-USB in the past and I took a quick look to bbusb, mecrimus-B and boot430 but I don't really know where to start.
     
    The initial project would consist in a simple 5 keys keyboard that emulates a mouse, keys are LEFT, UP, RIGHT, DOWN and a central CLICK button. When the user presses a button, the mouse arrow should move accordingly.
     
    Similar devices exists in Italy and are currently used in schools but their cost is very high (around 300 $) and the families cannot afford to buy one to keep at home. I've been asked from a friend to help him building a low-cost device for the children and I immediately thought about launching a community effort on this forum.
     
    The device should work out-of-the-box without the need of drivers out of the standard mouse drivers already available on Linux and Windows .
     
    The prototype should be built on a breadboard with minimal components, tactile micro switch are just fine even if we are already thinking about using captouch or proximity sensors for some kind of people.
     
    Is the anybody interested or willing to help?
      Of course, the project code and schematics must be GPL (or other FOSS) licenced.
  2. Like
    elpaso reacted to pabigot in mspgcc right shift question (energia)   
    To slightly clarify roadrunner84's comment:  "char" is neither signed nor unsigned.  It is a type distinct from both "signed char" and "unsigned char", and the compiler must specify that its behavior is equivalent to one or the other.
     
    gcc treats char as equivalent to signed char while IAR and CCS make it equivalent to unsigned char.
     
    Using uint8_t and int8_t is the right choice of data type when operating on specifically 8-bit data (as opposed to character data, where char is correct).  I do use "unsigned char" when I mean "the unsigned form of the smallest integral data type supported by the processor", though, just as I'll use "unsigned int" for "the unsigned form of the native integral data type" in preference to uint16_t when it really isn't the range that I'm concerned about.  Thus I have no problem using unsigned char to hold the value of P1IN when programming an MSP430.
    So many choices.
  3. Like
    elpaso reacted to roadrunner84 in mspgcc right shift question (energia)   
    The signedness of a char is undefined in the C standard. This means that it's up to the compiler to define this.
    Would a char be signed then, if it contains the binary value 0b10000000 then the corresponding decimal value is not 128 as you might expect, but -128.
    Shifting this value one to the right yields the result 0b11000000 which is equal to -64.
    If you want your char to behave as a unsigned integer of 8 bits, declare your variables explicitly unsigned
    unsigned char c;
     
    Or even better, include stdint.h (or cstdint for C++) and delare your variable as a 8 bit unsigned variable
    uint8_t c;
  4. Like
    elpaso reacted to veryalive in mspgcc right shift question (energia)   
    i don't know about the compiler, but here's how 2's complenent arithmetic would work:
    it means we interpret the byte quantity as a 2's complement number, not as a bit pattern.
    other machine instructions can interpret the byte 'logically' and fill from the left with zero, the carry bit, etc.
     
     
    so, in 2's compl arith........................      this can be called 'sign extending'  where the msb is the + or - sign bit.
     
     
    80 hex byte      =          -128 (decimal)
     
    right shift -128 (arithmetically, ie divide by 2)    =   -64 (decimal)
     
    -64 (decimal)        =      C0  hex byte
     
                                =  1100 0000     binary
     
     
    (!!!!!!!   note that the msb is a 'one',  this a nice property of right shifting 2's complement numbers   !!!!!!!)
       (it is very standard)
     
     
    now, even in a larger bit machine; such as 16, 32, or even 64 bits;   all those extra 'ones' on the left STILL make the same negative number !
     
    so, the decimal number -64 can be
     
    1100 0000                      binary byte
    C0                                   hex byte
    1111 1111 1100 0000    16-bit binary word
       FFC0                            hex word
     
     
    etcetera
     
     
    ciao
  5. Like
    elpaso got a reaction from reaper7 in [Energia Library] RTClib (external: DS1388, PCF8563 etc.)   
    Another trivial port... this is the RTCLib I've been using for a couple of AVR projects, it runs with really minor modifications (just stripped out PROGMEM related stuff).
     
    I've already pulled a request to the main repo (I've been contributing DS1388 to this lib in the past).
     
    While the pull gets in, here is the library on my fork:
     
    https://github.com/elpaso/rtclib
     
    I've tested the library on my LP 1.5 with a DS1388 (3.3V version) and it's working fine.
     
    Example
    #include <Wire.h> #include <RTClib.h> RTC_DS1388 RTC; DateTime now; // Ugly globals... uint8_t timeH; uint8_t timeM; volatile uint8_t timeS; uint8_t dateD; uint8_t dateM; uint16_t dateY; uint8_t dateW; void setup() { Wire.begin(); RTC.begin(); if (!RTC.isrunning()) { // following line sets the RTC to the date & time this sketch was compiled RTC.adjust(DateTime(__DATE__, __TIME__)); } } void loop() { // Read clock now = RTC.now(); timeH = now.hour(); timeM = now.minute(); timeS = now.second(); dateD = now.day(); dateM = now.month(); dateY = now.year(); // Do something with those figures... }
  6. Like
    elpaso got a reaction from bluehash in [Energia Library] RTClib (external: DS1388, PCF8563 etc.)   
    Another trivial port... this is the RTCLib I've been using for a couple of AVR projects, it runs with really minor modifications (just stripped out PROGMEM related stuff).
     
    I've already pulled a request to the main repo (I've been contributing DS1388 to this lib in the past).
     
    While the pull gets in, here is the library on my fork:
     
    https://github.com/elpaso/rtclib
     
    I've tested the library on my LP 1.5 with a DS1388 (3.3V version) and it's working fine.
     
    Example
    #include <Wire.h> #include <RTClib.h> RTC_DS1388 RTC; DateTime now; // Ugly globals... uint8_t timeH; uint8_t timeM; volatile uint8_t timeS; uint8_t dateD; uint8_t dateM; uint16_t dateY; uint8_t dateW; void setup() { Wire.begin(); RTC.begin(); if (!RTC.isrunning()) { // following line sets the RTC to the date & time this sketch was compiled RTC.adjust(DateTime(__DATE__, __TIME__)); } } void loop() { // Read clock now = RTC.now(); timeH = now.hour(); timeM = now.minute(); timeS = now.second(); dateD = now.day(); dateM = now.month(); dateY = now.year(); // Do something with those figures... }
  7. Like
    elpaso reacted to Rickta59 in [Help] how to get RAM usage from mspdebug?   
    You can mark RAM with a known value say (0xfeee). Then at runtime use mspdebug to examine memory looking for locations that no longer have the value of 0xfeee. Memory in ram that no longer contains the value 0xfeee is an indication that it has been used by a data variable, the heap or as stack memory.
     
    You need to write a function that runs prior to the start of main and "colors" ram. See the code link below for an example of how to create such a function. Link this function with your code and run it with mspdebug. Use CTRL-C to break after you have exercised all your functions. Then use the eXamine gdb cmd:
     
    > x/4xw 0x200
     
    Here we are eXamining ram memory starting at the lowest address (0x200 is the first ram location for most g series chips). Each time you press enter after that command, it will show the value of the next 4 words of ram. Press enter repeatedly and skip over the bss and data addresses and then start looking for '0xfeee', that is where the heap ends. Continue looking for 0xfeee until it changes, that address indicates the lowest stack value. The difference between the end of the heap and the lowest stack address is how much free ram you have. Note: If the value 0xfeee is a common value used in your program then you probably want to use another value to color the stack.
     
    Note: You can't get the amount of free ram just looking at the static numbers provided by the compiler. You must run your code and exercise all code paths to find out the true amount of memory your application uses. See this file for an example of a routine that can "color the stack"
     
    https://github.com/RickKimball/fabooh/blob/master/include/msp430/core/main.h
     
    Code starting at line 101
     
    -rick
  8. Like
    elpaso reacted to jpnorair in [Help] how to get RAM usage from mspdebug?   
    Not many MSP430 projects have dynamic memory allocation.  Unless you are using dynamic memory allocation (i.e. malloc), you can simply look at the bss (sometimes BSS) output from the compiler to see what your static allocation is.
     
    For the stack, unless you are running a threaded RTOS you're going to be running on a single program stack (if you are running a threaded RTOS, you are probably still saving thread-stack-pointers in static memory and you can probe them).  Anyway, the bottom of the stack is generally the upper most RAM address.  So, the uppermost address minus the stack pointer address will give you stack usage at any given time.  mspdebug can give you the value of the stack pointer.
  9. Like
    elpaso got a reaction from simpleavr in [Energia Library] RTClib (external: DS1388, PCF8563 etc.)   
    Another trivial port... this is the RTCLib I've been using for a couple of AVR projects, it runs with really minor modifications (just stripped out PROGMEM related stuff).
     
    I've already pulled a request to the main repo (I've been contributing DS1388 to this lib in the past).
     
    While the pull gets in, here is the library on my fork:
     
    https://github.com/elpaso/rtclib
     
    I've tested the library on my LP 1.5 with a DS1388 (3.3V version) and it's working fine.
     
    Example
    #include <Wire.h> #include <RTClib.h> RTC_DS1388 RTC; DateTime now; // Ugly globals... uint8_t timeH; uint8_t timeM; volatile uint8_t timeS; uint8_t dateD; uint8_t dateM; uint16_t dateY; uint8_t dateW; void setup() { Wire.begin(); RTC.begin(); if (!RTC.isrunning()) { // following line sets the RTC to the date & time this sketch was compiled RTC.adjust(DateTime(__DATE__, __TIME__)); } } void loop() { // Read clock now = RTC.now(); timeH = now.hour(); timeM = now.minute(); timeS = now.second(); dateD = now.day(); dateM = now.month(); dateY = now.year(); // Do something with those figures... }
  10. Like
    elpaso got a reaction from energia in Can I use libraries written for Arduino with Energia?   
    I was tired of all my web dev work and took some spare time to port LedControl to Energia and test with AS1106: it works wery well: see
    http://forum.43oh.com/topic/4312-energia-library-ledcontrol/
  11. Like
    elpaso got a reaction from energia in [Energia Library] LedControl   
    A quick port to Energia of the famous LedControl library for Arduino.
     
    Download:
     
    https://github.com/elpaso/ledcontrol-energia
     
    Original library:
     
    http://playground.arduino.cc/Main/LedControl
     
    Enjoy!
  12. Like
    elpaso got a reaction from bluehash in [Energia Library] LedControl   
    A quick port to Energia of the famous LedControl library for Arduino.
     
    Download:
     
    https://github.com/elpaso/ledcontrol-energia
     
    Original library:
     
    http://playground.arduino.cc/Main/LedControl
     
    Enjoy!
  13. Like
    elpaso reacted to abecedarian in Minimalistic 64 led matrix driver   
    Search the Projects forum for "matrix" and you'll see other projects people have done, and how they did it. Some have driven more than one LED matrix with an MSP.
     
    If you're looking at doing it 'stand alone' without the LaunchPad, that makes it a little more difficult, but can be done. Need to keep the voltage to the MSP at 3.3v maximum, and don't forget the decoupling capacitors and pull up the reset pin.
  14. Like
    elpaso reacted to Rickta59 in Is it just me or tonight TI doubled LaunchPad price?   
    Chip availability. I can't get these chips in small quantity from a variety of vendors. This is one of my personal priorities.That was on the USB Mass Storage Drag and Drop firmware upload. Some chips have that built-in to their ROM. With the Stellaris board, fortunately thanks to the open source community, a user created some software that provides that feature. The '*' indicates you will have to load that firmware to get that capability.
  15. Like
    elpaso got a reaction from roadrunner84 in Launchpad RTC backup battery   
    Ok, I will try to learn the inner of the MCU without Energia libraries, I don't really need and IDE (I'm the kind of vim+Makefile programmer).
    I've put together the first steps I made in this page: http://www.itopen.it/2013/03/01/msp430-energia-on-linux/ , maybe the Makefile could be interesting for other users.
  16. Like
    elpaso reacted to roadrunner84 in Launchpad RTC backup battery   
    I understand it's a little intimidating. You'll notice that the lot of it are chapters about each specific peripheral (WDT, Digital I/O, ADC, Timer, etc.). You don't need to touch those chapers until you're actually wanting to use those. I do recommend reading chapters 1, 2 and 5 (intro, system resets... and basic clock) to get a basic idea about the architecture (chapters 3 and 4 about CPU and CPUX are better left alone unless you're writing assembler). Then just skip ahead to chapter 8 (Digital I/O). This will give you plenty of knowledge to get simple demos like toggling an LED running.
    You don't need to remember everything, just know that something is in a certain way (like how to switch an I/O line from output to input, the details you can look up later).
    It's (in my opinion) important to realize that the MSP430 is designed around the concept of low power, this means that large counting loops to isert a delay are against the ideal of the architecture. You can make a 1 second delay by counting to a million, but you could just as well start a timer that will trip an interrupt after one second. Similar for buttons: instead of looping until a button is pressed, set up an interrupt and go to low power (which will automatically stall further execution of your code).
     
    The 32kiHz crystal was added for the very same reason; it's much more low power to use a watch crystal than a mutli-megahertz crystal. You could use it for an RTC, but since it's not implemented in hardware (at least not the ones shipped with the lauchpad) you'd have to run your own code to achieve it:
    set a clock to run from the crystal, set a timer to run from the clock, set the timer to overflow once per second, increment a seconds counter on that interrupt.
  17. Like
    elpaso reacted to jazz in Launchpad RTC backup battery   
    For battery powered system, can be used something like DS1314 (http://www.maximintegrated.com/datasheet/index.mvp/id/2691). MSP430 familly don't have dedicated internal EEPROM, but internal FLASH segments can be used like EEPROM (flashing during program execution outside of program memory space).
  18. Like
    elpaso reacted to roadrunner84 in Launchpad RTC backup battery   
    The MSP430 (at least the MSP430G value line chips) don't have an internal RTC, they do however have internal timers. Using a little software you can expand these to be RTC. If you want prcision timing you're bount to use either a precicion clock source or a precicion crystal.
    As far as I know you cannot power the timer separately from the rest of the MSP430. But you might use a buffer IC at the output and power the buffer from a second battery.
    Another solution would be to connect the backup battery and the other power supply both via a diode to the MSP430 power supply, make sure the second power supply is at least a little higher in voltage than the coin cell (otherwise you'd run from the coincell all the time). Then Also feed the second power supply to a general purpose input pin. If this pin is high, you know the secondary power supply is available and you can drive the display, of not, you shut down all functions except the time keeping.
  19. Like
    elpaso got a reaction from roadrunner84 in Launchpad RTC backup battery   
    Hi,
     
    I'm approaching LaunchPad after quite some time spent on Atmega MCUs, one of the first projects I would like to make is an alarm clock, the traditional approach I've followed in the past with Atmega was to use an external DS1307 or DS1388, a coin cell for RTC backup and EEPROM to store config and alarms.
     
    The display can be either a 4 digits 7-segments or a MAX7219 (or similar IC) controlled 8x8 LED matrix.
     
    I've read some posts on this forum about the possibility to use the internal RTC (there is even a lib for Energia), but my question here is if it's possible to use the external 32KHz quartz and the internal RTC instead of using an external DS1388 and still have the possiblity to use a coin cell battery backup to avoid time/date reset on power failures.
     
    Am I on the wrong track or is this a feasible project?
  20. Like
    elpaso got a reaction from RobG in Is it just me or tonight TI doubled LaunchPad price?   
    My order cart for 2 devices now looks like:
     
    Order Summary
    Subtotal: $8.60
    Shipping: $0.00
    Total: $8.60
     
    it seems like the west coast is awake now  8-)
×
×
  • Create New...