Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by jim940

  1. Interesting....seems like they're gunning for the Arduino chips indeed :smile:

    But this also means they have to increase the flash limits of the free version of CCS right?  Does anyone know the code efficiency (flash size) taken of MSP430 vs. AtMega328 code?


    The base bootloader on the Arduino is at least 2Kb.


    Still, 16kB is good for many projects, plus we always have GCC if we need to use something else. But maybe TI will keep seeing the light and make it a 32kB code limit for CCS at the minimum at least for the Value Line chips. 



  2. Here is the quote from the beginning (oPossum), that I am specifically countering: "My experience with C++ on the MSP430 has been that it allows for faster, more compact and better organized code."


    As you now know, my experience is exactly the opposite, and the opinion is generally shared among performance-minded devs. You can certainly use C++ with good results, but for large projects where fast, compact, and easy to navigate code is a requirement, it's a bad choice.


    I'm reminded of Torvalds qoute on C++.


    "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it"



  3. I was looking at the C2K Launchpad, and was sort of disappointed they didn't go with a board that uses CAN, so decided to possibly make my own.


    Any ways, I did not route the LIN ports yet, I should have, but as you can see, there is quite a bit of fudging along to make it all work.


    It is more or less pin compatible with the regular C2K LaunchPad, except I'm using the 2 NC pins on the lower right headers to break out the CAN pins. And using a JTAG port for programming and debugging.




    It won't let me upload .brd files so I attached them to my website:




    Dimitri (aka jim940 at 43oh)



  4. Tom,


    Its not a linear regulator, its just in a package suitable for use in where a 78XX type linear regulator would fit.


    It has a efficiency level of 82% when you input only 9V on the 3.3V version, and goes up from there the higher the input voltage.


    Most of my Web Bench designs were not that much better, and tended to be more limited on input voltage options.



  5. Added a power supply 9 to 72V and it has a switch now to select whether the input is from the 2x5 header or the terminal connection.




    I hand routed it in this time oPossum :D


    Might be over kill and its a tad pricy but the 78XX compatible regulator I'm looking at is: V7803W-500R ( http://search.digikey.com/us/en/product ... ND/2757923 ) So you can put in from 9 to 72 V and its all self contained, just used the regular 78XX footprint from the library though so I'm thinking that hole really isn't needed but that is okay I think.


    The regulators data sheet says to place a diode above as I did in the schematic for over voltage protection. So added that as well.


    But getting some errors I don't know what they mean after I installed the SeeedStudio DRC packages. :S







  6. The MSP is low power, so might as well try and keep our boosters from being power hogs with LED's hence why I left LED's out in the first place.


    Anyways here is the Schematic. Also added a termination resistor in case this is the last node in a line and you wanted something more permanent then Jerry rigging the resistor on the outside of the open connector.





  7. Well this is the minimalist version, the LaunchCAN still needs to be finalized in my head. None the less this one is probably what would interest people the most.




    If you catch any errors let me know.


    Pins currently used:

    1 - CAN Bus Interrupt Pin

    7 - UCB0 CLK

    14 - UCB0 SIMO

    15 - UCB0 SOMI

    16 - RESET

    18 - STE for MCP2525

    19 - AutoBaud feature of TI SN64HVD235


    And the BOM of course:


    • [*:3u4zlitu]Microchip MCP2515 CAN Controller (MCP2515-E/SO).
      [*:3u4zlitu]TI SN64HVD235 CAN Transceiver (SN65HVD235D).
      [*:3u4zlitu]16Mhz Crystal
      [*:3u4zlitu]2x 22pf Capacitors
      [*:3u4zlitu]0.1uF Capacitor
      [*:3u4zlitu]5x2pin Male Header (conforming to CANopen spec's for DE-9 Connection)
      [*:3u4zlitu]Phoenix 1923898 Socket (CANopen type)
      [*:3u4zlitu]2x 10pin Female Headers


    You'd also need a Phoenix 1911994 Terminal block to mate with the socket.




  8. Thanks for the screen shot.


    You are right about its length possibly causing it to tip over, I will add some screw holes to mount standoffs to if not used in a enclosure, otherwise, if you installed it in a Hammond 1455C case, you'd have to use ribbon cable and not fixed headers, but you'd be able to slide it into slots that will hold the PCBs both length wise completely, and still leave you with a 20x20x41mm space for a battery pack if required.



  9. Here is the board, with the top user interface completed somewhat as a sample layout.




    Will get the Power and CAN over the weekend. The oddball connector at the end is a Male M12 CAN/DeviceNet sealed "micro" connector in case anyone is wondering.


    Currently includes a 4x4 keypad, the OLED screen (as per Bluehash's booster), and indicator lights up top (top row for GRN, bottom for RED etc). All of the keys and LED's are going to be wired up through I2C chips as mentioned above once the top is completely done.




  10. Sorry I am pretty bad at coming up with catchy names. :lol:


    Anyways, my proposal at the moment involves a "double" booster size of 100x50mm. Which will allow it to sit nicely in a 1455C case from Hammond as well. It will have properly broken out headers for LaunchPad Booster packs.


    Anyways some of the initial specifications I want on the board:


    • [*:vili5prf]TI MSP430G2553 TSSOP-28 (or using headers to a LP) (might need something "bigger"?)
      [*:vili5prf]Microchip MCP2515 CAN Bus Controller aka "SPI<->CAN Bridge"
      [*:vili5prf]TI SN65HVD235 CAN Transceiver w/Auto-Baud Loop Back checking
      [*:vili5prf]Bluehash's OLED display
      [*:vili5prf]Anaren CC110L Module
      [*:vili5prf]TI TCA8418 I2C Keypad Controller attached to a 4x3 or 4x4 Button Keypad
      [*:vili5prf]TI TCA6408A I/O Expander attached to 8 Status LED's for CAN Bus and system information
      [*:vili5prf]National LM34910 Switching Regulator
      [*:vili5prf]CANOpen DE-9 Connector (NOT compatible with SPF's OBD-II cable)
      [*:vili5prf]Phoenix M12 CAN Connector


    One thing you guys may be able to help me with, is how to use 2 power sources and have the system automatically switch from one to the other without user intervention. Never tried anything like that before. Currently in my head, the National LM34910 will provide approximately 3.3V at 500mA with a input range of 10 to 26V making it compatible with both 12V CAN Bus networks (automotive) and 24V CAN Bus networks (Industrial stuff), however a battery back up would provide for power using a TPS780 which will allow the MSP430 to power itself from 3.3V to 2.2V due to the selection pins when there is no power applied to the CAN Bus connectors.


    I might need something bigger then a G2553, however, my CANBus code when I did it on a Arduino was only 4.5K, and nearly 1.5K is automatically taken up by the bootloader when you write your program onto the Arduino, so it might just fit on a mere 16kB, but I am not sure at the moment. Might need a bigger chip, and I feel I would not have the memory space required to implement a SD Card storage on the G2553 at all. Any suggestions are welcomed.


    But there you have it a little do it all industrial interface board. I'll post schematics and pictures of the PCBs in due time. :D



  11. Good explanation.

    Aren't we limited on the number of mailboxes in the microcontroller's hardware?


    Yes and no, its a lot like a UART with a buffer, typically your stuck with 2-4 messages in the buffer at most with the CAN controllers I've seen. But programming wise, you check the buffer using a interrupt routine when the buffer flags a message is incoming. Even the external MCP2515 SPI<->CAN Bus has a additional pin to be connected to what ever uC's interrupt pin to flag that there is a message.


    So, similar to a lot of the MSP430 projects I see around here implementing the power modes, a interrupt routine that wakes up due to the CAN Bus Interrupt, would allow relatively low power, and all the routine would have to do is check with a if or case statement if the message is one the controller wants, if so use the data and then clear the interrupt, otherwise just clear the interrupt and go back to sleep. More or less its the same as any UART interrupt routine because of the way it was designed.


    Typically, a CAN Bus doesn't bombard the network all the time with useless data (trying to send files/large hunks of data over it), only packets of the specific preprocessed data as required.


    So your thermometer in my previous example isn't blasting away messages as fast as it can, instead you may get it to broadcast only once a minute or more (due to the time it takes to actually change the room temperature in the first place), freeing up a large portion of the Bus, and at the same time, your not sending uncalibrated temperature or other data to the master, your sending something it can directly work with in a simple math function or if statement, allowing it to not be burdened with the grunt work.


    Plus, at 250Kb/s or 500Kb/s with most automotive protocols, data takes a while for it to become available compared to the processing ability of the uC (such as running a MSP430 at 8Mhz or better), especially when unwanted message ID's would just be dropped before the rest of the packet is even read/used in the uC's code. As if you know the contents of the message, you can avoid the CPU time of trying to figure out if the data itself is relevant. Which is one of the benefits of a CAN Bus style message ID, verses a address which requires the local device with the same address to work with the data before realizing if some node is just wasting its time.



  12. I just realized I forgot the "u" in forums. :oops:


    Anyways, I know more about the CAN Bus now then any other network protocol, spent a entire semester at my college studying it (first Semester of Project Design) so that when I did my project the next semester (Semester 2 we are supposed to build and make work the project) I was decently well versed in it:




    Its Arduino I know, (don't kill me), but that is what I was asked to work with, so that is what I did. :shh:


    One thing that confused me as I learned about it, knowing the OSI model, is that technically the CAN Bus forgets about that style of operation. For example, for layer 1, connector types etc should be specified, instead, the higher OSI layers that are implemented on top of the CAN Bus Specifications (such as OBD-II) specify the connectors themselves, and while the OSI model relies heavily on the addressing of the node you wish to speak to, the CAN Bus system, is designed so that each and every node will get the same packets and will use the Message ID as a means to detect whether or not the data is useful to them.


    Say you have a home monitoring system running on the CAN Bus, you have a master home controller, a secondary back up controller, and a dozen temperature probes, a couple thermostats, a humidity sensor, oxygen sensor, a couple of smoke sensors and a dozen door sensors.


    You'd assign the smoke sensors, lower message ID's, to give them priority, as the CAN Bus will detect "on the fly" if there is a collision, and the lower the message ID bits, the higher priority it gains and wins out arbitration. As in the case of a fire, you want the data to always reach your main controller. So each message ID will be unique to the sensor itself and not its address, instead its what the smoke sensor will use to broadcast its data.




    Now, your worried about a B&E, so the next lowest set of ID's will go to your door sensors, followed by your oxygen sensor, humidity sensor, thermostats and temperature probes etc. or your own unique priorities.


    Since it doesn't rely on a messaging format such as IP routing in your home, BOTH your main controller and your back up controller will receive every packet from every sensor, however, while your programming the main controller regularly, your back up controller is programmed as a watch dog, so that, you'll have code such as, if (Temperature_probe1 < setpoint) && (main_con !sending_messages) then take over the bus and assume the main controller is "dead". And since all the probes, scattered throughout the house can be "dumb", and not actually know who they are sending the packages to, you can have any combination of back up systems in place that will allow your system to survive any number of failures. So any back up "master" nodes, just need to listen as my above example for the sensors (dumb devices) sending requests and the "master" nodes responses. If the master node is not responding, and the back up takes over, the furnace wouldn't know the difference between a packet from the master node, or from the back up master, it will just do what its told, and the system will not be compromised cause of a single (or multiple) failures.


    This is one of the reasons why, one of the neat things that the CAN Bus is being used for, beyond the typical industrial automation and automotive sectors, is aerospace, for both planes and space bound satellites, due to its redundancy which doesn't require human intervention to correct itself when properly implemented.



  13. I am thinking something simple would do the trick: MSP430, small LCD, and a couple of opto-couplers.


    You'll have to use something like a MCP2515, which will convert the SPI from the MSP430 to a hardware CAN enabled port. Level shifting alone will not actually cut it for the way the CAN Bus was designed, error detection, collision detection etc is hardware not software level on every CAN Bus implementation.


    CAN Bus network packets (which OBD-II is just one of many subsets of message structures with known variables), are nice to work with, only oddity compared to other addressable message systems is that your not supposed to assign devices "addresses" instead CAN protocols use message ID's that are supposed to identify the data in the packet itself, its up to every individual node on the bus to decide where or not the data in the packet is useful to them or not.


    Really its how a embedded networking protocol should work, atleast in my mind. Especially when you have different products with different features and you do not honestly want to program millions of ECU's with different firmware.


    I could read from only one ECU for some reason.


    On cars with a OBD-II port, which were designed to comply with the Californian laws, tend to separate the ECU (Engine Control Unit) from the OBD-II port using a ECU (Electronic Control Unit) with 2 CAN Bus ports on either end, filtering out the non-service/emissions related codes from the car's CAN Bus. Yes 2 names for a ECU, both in cars, cause I guess Automotive EE's are not creative.


    Both to protect the cars functions but also because depending on the car, you can have quite a number of ECU's in a car doing things in the background with sensors for your cars every move, and a lot of that data is typically kept very closed source. Bosh, and other OEM's tend to not even reply to emails about their CAN Bus protocols for their specific products unless your already a known automotive customer.


    If TI watches these forms ... I'd give my first born to them if they made a G2553 and/or a FRAM MSP430 with built in CAN hardware. :thumbup:



  • Create New...