Jump to content
43oh

tonesenna

Members
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    1

tonesenna last won the day on November 24 2012

tonesenna had the most liked content!

About tonesenna

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://omnismart.wordpress.com

Profile Information

  • Gender
    Not Telling
  1. I attached the design files for this initial version of the rocketfuel. You are free to copy, modify or use it any way, although a reference to the original work would be appreciated. Prototypes mounted and first tests already done. The charger circuit has one flaw: the body diode of the P-channel MOSFET creates a current path that lets current flow from the battery into the state LEDs and even the charge controller's supply pin. In practice, we see both leds dimmly lit when the USB supply is removed. This can be somehow circumvented by removind one of the LEDs - the DONE LED, leaving
  2. Good news! :mrgreen: Remaining parts arrived today. I have 3 boards assembled, except for the stacking headers, which I'm still waiting to arrive by normal mail. Since the sparkfun batteries are also still on transit, I am using an old BL-5B Nokia battery, soldered and soldered wires on it for a quick test. So far everything looks good. Both the battery and the pass transistor are running very cool (although I'm not sure if the charger is already in CC phase) :thumbup: It's kinda late so no pictures or test results right now. On the weekend I'll grab a few photos and do some testing.
  3. I discovered 43oh quite recently and had very little experience with the previous forum. As for the current implementation I wouldn't say it increased or decreases my commitment to the forum. The same goes for user experience. For me the main driving factor is the community. The role of the forum software is important in the sense that is doesn't get in the way. I guess that's true for both incarnations. As for site administration, if this version improves management, filters malicious bots/scripts/whatever and allows more feafures efficiently, that's seriously very cool!! :thumbup:
  4. On one hand it's sad to know that the store is soaking so much of yout time and effort in such a way that you need to tap the brakes to avoid letting things go out of control. On the other hand it is very nice to know that you managed to build such a significant community around 43oh and the interwebs as well. Congrats for that. I really hope you can sort out a way to run the site and store and, also important, take due credit and compensation for all the effort you're investing on the project. -- to
  5. Hi everyone, I am in the process of evaluating which tool might be more suitable for the design of relatively simple boards. From the alternatives that I found, diptrace and eagle seem to be the top contenders. These are clearly tools not intended for complex jobs, although they can get the thing done for a fraction of the cost of more capable tools. I think eagle has a cumbersome way of defining the coverage of vias with soldermask. The management of component libraries would be better if eagle had an automated way of updating a landpattern accross all libraries that make use of it.
  6. The PCB prototypes arrived today. These units come green. However I plan to make them red on the final version. The PCB quality came quite good in general, although there are some quircks: some drills are slightly off-centre. This can be noticed specially in vias, althouth it's effect is mainly cosmetic There is no soldermask on vias. I have to check the PCB design to fix this silkscreen clearance to copper seems too small apparently. The silkscreen got truncated around some SMD pads, which I wasn't expecting. Need to review my landpattern library. Some placement drills are plated, al
  7. I second pagibot. In a way, any language is unsuited for a particular purpuse if used inappropriately. All those items are generally known as coding/design flaws, regardless of using C, C++, java or any other language. The question at hand is not if there are people that know C++ and if these people have the skills to code for an MSP430 in C++. The question is about the possibility of using the features of C++ (only the ones that make sense in an embedded world) to code for the MSP430 without compromising performance and code size. I guess oPossum's links above depict that quite well
  8. I, for sure, would like to be enlightned on this matter, as it does seem to contradict common kowledge regarding the MSP430 architecture. I believe that C++, properly used, may be effectivelly used to reduce coding effort and keeping the generated machine code as efficient as the equivalent C would. It comes to my mind that using templates to code for several implementations of an USCI driver might accomplish that, with a single template one might easilly implement, for instance, an UART on all USCIs of a given device. -- to
  9. It depends on the device and the supply voltage applied to them. Typical maximum frequencies are 8, 16 and 25 MHz. The best to do is actually check the datasheet for the particular device that you're interested in.
  10. After many iterations the PCB was *finally* :mrgreen: sent for fabrication. This is my first experiment with a PCB prototype so... fingers crossed. The prototypes will be green although I'd like to make them red if they happen to spark the interest of the community. Here's a peek of the final (yup, really) design: The boosterpack takes the battery on top to minimize stacking height. Components on the solder side were kent away from obstacles (DIP package, jumpers) to minimize stacking height to the least possible. There is a 1x2 female header located matching with the VCC conn
  11. Last minut changes... The original idea was to place the battery beneath the PCB. However, when stacking the RFBP with the LP, the stacking height was too high and forced the use of staching headers that were way too expensive and didn't allow to stack the RFBP with other boards. So, I'm in thr process of moving all components to the bottom and placing the battery on top. I keep the area of the DIP socket clear so that we can stack boards with only 10mm spacing. This will allow to keep BOM cost down, make the RFBP stackable and make it more convenient to handle. -- to
  12. Thanks! I searched in forum for "C++" and oddly got zero results. I'l follow your hint though. -- to
  13. I never tried this and I could easilly check this for myself. But out of curiosity, I wonder if it is possible to code for the MSP430 in C++. In particular I was thinking of mspgcc which is freely available. Has anyone tried this already? Thanks. -- to
  14. VLO , DCO and External crystal are all clock generatores. Which one to use depends on your needs in terms of clock speed, accuracy and power consumption. VLO is a very low power clock that runs in the 10s kHz. While speed is very limited, it provides you a means of having a clock driving some system logic with minimal power consumption. This clock generator isn't accurate at all IIRC. DCO is a high speed clock generator that runs in MHz range. Is requires more power but allows clock speeds magnitudes higher than VLO. Accuracy is tipical in the range of 1 ~2% so it should be ok for appl
  15. It would be nice to have some kind of filter that showed a list of currently unanswered posts, ie, topics with 0 replies. Would such a thing be attainable? Thanks! -- to
×
×
  • Create New...