Jump to content

Nytblade

Members
  • Content Count

    99
  • Joined

  • Last visited

  • Days Won

    2

Reputation Activity

  1. Like
    Nytblade got a reaction from oPossum in Books about C2000?   
    I found a really good tutorial.  Download the C2000 Teaching ROM... it is a bunch of pdfs from a university class.
  2. Like
    Nytblade got a reaction from spirilis in MSP430F5172 LaunchPad XL   
    Spirilis had an extra board from the original batch he sent me to try out.  Here is a video review of it I made and an explanation of how to program it: http://www.youtube.com/watch?v=GHjFCnXXAoQ
  3. Like
    Nytblade got a reaction from bluehash in MSP430F5172 LaunchPad XL   
    Spirilis had an extra board from the original batch he sent me to try out.  Here is a video review of it I made and an explanation of how to program it: http://www.youtube.com/watch?v=GHjFCnXXAoQ
  4. Like
    Nytblade got a reaction from jsolarski in MSP430F5172 LaunchPad XL   
    Spirilis had an extra board from the original batch he sent me to try out.  Here is a video review of it I made and an explanation of how to program it: http://www.youtube.com/watch?v=GHjFCnXXAoQ
  5. Like
    Nytblade reacted to timotet in Launchpad U2 & U3   
    I think this is the answer you are looking for:
    http://www.forum.c2kcentral.com/topic/135-c2000-launchpad-gpio-question/
  6. Like
    Nytblade reacted to infinityis in [S] ProtoPowerSwitch Boosterpack (formerly AC-powered Relay BoosterPack)   
    The gate resistor is indeed a standard resistor; it is only called a gate resistor because of how it is used in the circuit, connected to the gate of the TRIAC or SCR. Good catch on R3, I've corrected it above to be a 180ohm resistor part number.
     
    In the schematic, yes, SW2 is a TRIAC and SW3 is a SCR. 
     
    R1 for the relay section is either a 330ohm resistor for an opto-driven relay coil or a 680ohm resistor for a transistor-driven relay coil (I've updated the BOM above to reflect that as well). In the schematic, SW1 is a relay that is driven by an optocoupler, whereas SW4 is a relay driven by an NPN transistor. The rationale behind which to choose depends on several factors:
     
    Arguments for using optoisolator-driven relay coil
    In some instances (such as the transformerless power supply configuration), the optoisolator is required because the configuration uses two voltages (3.3V for the MSP430 and 24V for the relay coil) with separate grounds. In the transformerless power suppply specifically, the 24V ground is basically tied to the positive side of the low voltage. If you try to use a transistor instead of an opto, the microcontroller would be unable to turn it on (because the microcontroller is unable to drive the base of the transistor above the 24V ground, i.e. the emitter voltage)
    In other instances, someone may choose to use an opto because of noise or voltage level issues. For example, if you're driving a 12V relay coil from a $200 FPGA output pin, the optoisolator might be preferred over a transistor because if somehow the transistor gets damaged, you could expose your expensive FPGA to high voltages which can damage it, whereas the opto will likely continue to isolate electrically.
    If the relay coil injects a bunch of noise into the driving circuit, you may want to isolate the ground through an opto, because a transistor precludes having isolated grounds.

    Arguments for using transistor-driven relay coil
     

    On the other hand, you may want a transistor because Vce (the voltage drop across the collector to the emitter) is low. At tens of milliamps (which is the relay coil current) passing through the output of the optocoupler, there is about a corresponding 1V drop across the output of the optocoupler. This means that with a 5V USB-powered circuit, the relay coil will never see the full 5V across it. The opto will create a voltage drop slightly more than 1V, leaving only 4V across the relay coil. The Omron relay I use states in the datasheet that it "must make" at 75% of the rated voltage, so as long as the relay sees more than 3.75V across the coil, the relay will turn on. However, that only leaves less than 0.25V of margin. Alternatively, with the NPN transistor, the Vce is only about 0.2V, you can still provide 4.8V to the relay coil directly, leaving plenty of margin (more than 1V of margin). Note also that if a 12V or 24V relay coil were to be used (which is a higher voltage than a USB connection provides), a 1V drop would be a lot less significant than it is for a 5V relay coil.
    The CTR of optocouplers  is generally lower than the hfe (the DC current gain) of a transistor...The selected opto has a minimum CTR of 600%, which means that you can pass at least 6x the current through the output compared to what you drive through its input (internal LED). The 5V relay coil requires 72mA of current. 72mA is right at the maximum output current for the opto; beyond that you start to exceed the power rating of the opto. Looking at the datasheet for the LTV-815 (figure 5 specifically), I see that at 10mA forward current (into the internal LED), I get about 7.5x CTR, so I can draw 75mA on the output (which corresponds to the maximum collector current specified in the electro-optical characteristics table as well). That is barely enough to turn on the relay coil at 5V, but we can assume the current draw will be less because (as we already established) the opto driven relay coil will not give the full 5V anyway. So we figure the coil will actually draw 75mA * 4/5 = 60mA and we actually look ok with 10mA in. But do you really want the MSP430 to have to drive 10mA per relay? With all four relays on, 40mA is quite a bit of current (especially given that some MSP430 have a total maximum current output of 48mA...and we haven't even started counting the current drawn on MSP430 pins from LEDs, etc.). You can of course drive the opto (and LEDs) with a transistor instead, or by adding a transistor on the output of the opto (which is effectively taking the Darlington transistor pair on the output of the LTV815 yet another step). You could also sidestep this issue by spending a little more on the opto...insead of ~$0.2 per LTV815 at Mouser for 600% CTR, you could go for the ~$0.6 per PS2502-1-A at Mouser for a 2000% CTR (still with a 1V drop on the output though)...
    The transistor costs less. If you want something that does the job elegantly by providing a 25x current gain when the output current is 75mA (so we only need 3mA to drive it on) and only 0.2V drop across the output, the transistor I chose is only $0.4. Less than 20% of the cost of the cheapest opto. For someone wanting to prototype a design with plans to go into production, that cost savings can make quite a difference.
     
    I'd say the bottom line is that unless you require isolation for noise immunity, or because you need/have different grounds or other reasons to maintain isolation, I would certainly prefer the transistor-driven relay coil as shown for SW4 in the schematic (for a 5V coil relay, anyways) . The cost is lower, the voltage margins are better, the current required from the microcontroller is lower, and you are not susceptible to the CTR degradation of the opto over time (i.e. your long term reliability improves).
     
    I can say that I have implemented both and at the very least, both options are functional. You can see this on the second page of the pictures of the boards pdf, where two have the optos and two have the transistors. (note that on the opto versions, I forgot to buy 330ohm resistors, so I just go it close enough by installing a 680ohm on both the top and bottom side of the board to get a parallel combination of 340ohms).
  7. Like
    Nytblade reacted to infinityis in [S] ProtoPowerSwitch Boosterpack (formerly AC-powered Relay BoosterPack)   
    (sorry for the delay in responding; the kids were sick last week and there was quite a bit to respond to!)
     
    Assuming you avoid the transformerless AC power supply capability of the board (which I recommend to keep things safer while still in development, and there would need to be a power budget analysis to see if it is feasible)...   You should not need to disconnect the USB from the computer, because all the high voltage traces/planes are optoisolated from the microcontroller (and thus from any USB connected devices as well). I mention that because I occasionally found it useful to keep it connected for debugging purposes. Also, if you disconnect the USB from the computer, then prior to step six you will need to plug in a USB charger/power supply to the Launchpad and power strip.   In my testing, IProtoPowerSwitch Demo Programs.zip
    Schematic ProtoPowerSwitchBoard v8.pdf
    AssemblyDrawing ProtoPowerSwitchBoard v8.pdf
  8. Like
    Nytblade got a reaction from msptest6 in Books about C2000?   
    I found a really good tutorial.  Download the C2000 Teaching ROM... it is a bunch of pdfs from a university class.
  9. Like
    Nytblade got a reaction from Scardini in Books about C2000?   
    I found a really good tutorial.  Download the C2000 Teaching ROM... it is a bunch of pdfs from a university class.
  10. Like
    Nytblade reacted to bluehash in Enter the TI MCU BoosterPack Design Challenge!   
    Hi Everyone,
    43oh is glad to be a sponsor for TI's BoosterPack Design Challenge.This is your chance to design your BP and also have it made by CircuitCo.
     



    Minimum Requirements:

        1. Submit an original BoosterPack design for your MCU LaunchPad.

            - Schematic Layout (including reference designators and an
              extractable net-list)
            - Bill of materials not to exceed $40 (in unit orders of 1K, in XLS format,
               noting reference designators and manufacturer part numbers)
            - Record a video describing your BoosterPack idea and upload it to
               YouTube. Get creative!

        2. Upload your project to an online file sharing site (ex: Google Drive, Github) and set it for
               public view.
        3. Follow the link to complete your MCU LaunchPad BoosterPack Challenge entry.

    Please note: This contest is intended only for the residents of the continental U.S.
  11. Like
    Nytblade reacted to gwdeveloper in Emmoco Bluetooth Low Energy BoosterPacks EDB-BT and EDB-BLE   
    I have the Emmoco kit. It works very well. I created a CCS project for the Stellaris LP using their API; one is included for several mcu/compiler options. Not sure what the license is but I'm only using it to tinker, for now.

    Using their em-hub is pretty easy. Software is really easy to find; no chasing links, registering for each piece of software or having to wait for codes. Information is really abundant once you're logged in. I don't think you get to see the goodies until you get a reg code in the box's lid.

    The device needed a firmware update right away but since the kit included a usb-ftdi, it only took a few minutes to download and update. The kit also contained a level shifter board for different mcu voltages. A connector cable was provided for use with boards other than the Msp430 Launchpad v1.5.

    I'm using their em-builder to create the required schemas. It's capable of building and debugging to the msp430 via GCC. I ran the demo and tested the msp430 stuff, it worked well so I moved over to the more exciting Stellaris LP. Since I'm more familiar with CCS, I'm using it to compile my applications.

    The free demo apps on the App Store are simple and to the point. I'm currently using their em-browser to check data transfers from the LP's ADC. The only issue I've run into is compiling an iOS project. It's a fresh install of Xcode on the wife's new iMac. Only tested that today and it wouldn't compile a new project, the errors were Emmoco related but I'm not faulting them. (yet?) Didn't look too much into it for lack of time but can report back later. When you make sure to follow the directions and not miss a step, the project compiles with no issues. Hoping to make my first iOS app a color wheel for changing the RGB on the Stellaris LP.

    iOS project compiling aside, I can't say enough good things about the Emmoco kit. Very easy to follow tutorials, quick to launch API and a well equipped hardware bundle makes it a winner for me. Next, I'd like to connect it to the ipad using techbasic.

    No, I'm no being compensated for this but yes, I did receive a free kit.
  12. Like
    Nytblade got a reaction from larsie in Emmoco Bluetooth Low Energy BoosterPacks EDB-BT and EDB-BLE   
    I haven't used that one.
     
    The Nordic nrf8001 is an easy to use one that doesn't require a software stack.  Their development kit is expensive though.
     
    The hard part to me is the "master" end of the bluetooth connection, not the slave.  TI has an open source bluetooth master library (I forget what it is called - one of their bluetooth stacks).  However, I think the standard way of operation is that a computer or phone is the master, rather than another microcontroller being the master, which is what I was trying to do in my project.  I wanted to have a higher-end MSP430 master controlling a bunch of dumb slaves in a home automation system using BLE.
     
    The Bluetooth LE spec is insane... 2300 pages in the Core Spec.  Of course you don't have to understand all that... but I like to know what I'm doing.
     
    TI has some chips that require a "binary blob" bluetooth library... like on the MetaWatch.  I strongly prefer open source - you have to watch out for those.
  13. Like
    Nytblade got a reaction from spirilis in MSP430F5172 LaunchPad XL   
    I see I am not the only one to experience the 'joys' of the UCS. :thumbup: Good clean coding style.
     
    I am going to attempt to port my wiznet DHCP client to your board.  My code is too bloated to fit on the original MSP430 Launchpad.  However, if I can get it working, people could use Rob's ethernet boosterpack with your board and have automatic IP address assignment via DHCP.  I think that would be useful.  I can post the code to a simple telnet server or webserver with DHCP support.
     
    Do you know if it is possible to have the pins sticking out on both side with your board like they do with the C2000 Launchpad?  Or a female header on the bottom like the Stellaris Launchpad?  How do they solder that I wonder..? (I don't have one in front of me right now...)
  14. Like
    Nytblade reacted to Thomas1426459898 in SLLogicLogger - A simple logic analyser for the Stellaris Launchpad   
    Hi,
     
    Here is my last project with the Stellaris Launchpad: SLLogicLogger - A simple logic analyser for the TI Stellaris Launchpad.
     
    Logic levels on PORTB are sampled with 10MHz to RAM (16 kBytes) and then transmitted through the debugging controller over USB to a host computer. No additional hardware is needed - a pure Stellaris Launchpad connected over the debug-USB to an PC is enough. The firmware implements the main functions of SUMP, a serial protocol for logic analysers. There are some clients which supports SUMP. I used LogicSniffer OLS (http://www.lxtreme.nl/ols/) which is a multiplatform Java client. A simple OLS profile file is sufficient to read out the sampled data from the Launchpad.
    Sampling starts on any state change on PORTB, no further trigger functions are supported yet.
     
    Further description and download:
    http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/
     
    The logic states are sampled from the GPIO to an array within an for-loop:
    // sampling buffer char buffer[BUFFERSIZE]; // aquire data for (i = BUFFERSIZE; i != 0; i--) { buffer[i - 1] = GPIO_PORTB_DATA_R; } With this method I get 10 MHz sampling rate at 80 MHz system clock. Does anybody know, if there is a chance to speed it up? E.g. using AHB, uDMA, ...?
     
    Thomas

  15. Like
    Nytblade reacted to abecedarian in Total "food stamp" recipients exceed population of 24 states combined   
    http://www.breitbart...States-Combined
     
     
    Please note- this is a "record", meaning never before in history have this many people been on food stamps. Mind you, this is the 4th year of the current administration and we're up for 4 more.
     
    Say what you will about the economy getting better and the housing market being up; historically relevant numbers of people on the welfare dole is not good no matter which way you slice it... and may even be a sign of impending doom.
     
    How can the economy and housing go up if ~1/6 of the population are receiving public assistance?
     
     
     
     
    Sorry- had to vent for a moment.
  16. Like
    Nytblade reacted to jpnorair in Coding for MSP430 in C++   
    Disclaimer: this is my general opinion based on a lot of experience developing hyper-optimized embedded stuff for communications, RTOS, signal processing, graphics, and crypto, for which I think C++ is horribly suited. There are always exceptions, so it's not a riff at anyone personally who likes C++. Of course, C++ can do everything that C can do, so what we are really discussing are "best practices" of typical C++ coders.
     
    That said, I've never seen a good, clean, elegantly optimized piece of C++ code, apart from what I've seen from some game devs. As a case study, in 2010 I was contracted to solve a performance bottleneck caused by OpenCV for BeagleBoard. After taking a month to remove all of the "C++ best practices" in favor of C practices, guess what, 20x performance improvement. I will outline here some of the dumbest C++ practices for embedded & performance-oriented code:
    malloc everywhere (or just using objects instead of pointers). Seriously? Are you spawning threads? no? Then why in the name of Zeus are you mallocing?
    Passing objects when a pointer will do. You can argue that the compiler might be optimizing these out, but, in my experience, it's a lot better to be able to just scan through the C and find the problems than to have to analyze the crap out of it during runtime or read through generated assembly, required because there isn't a transparent connection between the compiler and the code.
     
    Storing sequentially accessed data, often of multiple objects of the same class, in the objects instead of in a coherent data block. In archs that have slow memory access -- MSP430 is one -- this is a great way to waste CPU cycles. On bigger multicore systems with shared L2 Cache it can actually be much, much worse.
     
    Inheriting objects into other objects, such that design changes during optimization cause cascaded errors that are difficult to find in large projects.
     
    Making efficiency compromises in order to design objects for multiple inheritance.
     
    Using conditional logic instead of arithmetic transforms and bit twiddling, and using pointers naively because strong typing is a religion.
     
    Hiding-away object class definitions deep into the file structure, or making stuff private when you're building an open source project. Open Source... the guy from Russia who downloaded your shit just changed all the private classes to public, anyway. Save Boris the 30 minutes and just make a comment.
     
    On the note of comments, comments are better than "self-commenting code." Self-commenting code is a disgrace. I'm not German, so I'm not trained at an early age to ReadWordsThatAreSixtyLettersLongWithWeirdCapitalizationRules. For whatever reason, I see this practice a lot in C++ and Java, but rarely in C.

    I could probably think of more, but those are the ones that come to mind. Anyway, I'll throw down the gauntlet. I will offer a free optimization consultation of C++ source to doubters on this thread.
  17. Like
    Nytblade reacted to Fred in Eagle Library for Stellaris LaunchPad   
    Attached is my Eagle Library for the Stellaris LaunchPad. It's my first attempt at creating an Eagle library so any advice would be gratefully received, but go easy on me! It was created in Eagle 6.2 so may not be compatible with earlier versions. It's heavily based on Gordon's MSP430 booster pack library from 43oh - http://forum.43oh.co...gle-footprints/
     
    I intend to use to for mounting the launchpad on a larger PCB using the female header on the bottom but it should be OK for booster packs too. I've not used it on a board yet so there's a reasonable chance I've made a mistake somewhere and not noticed yet. Please check thoroughly before using it.
    StellarisLaunchPad_Fred.lbr
  18. Like
    Nytblade reacted to spirilis in Wolverine sneak-peek!   
    Just caught this on the MSP430 E2E forums at TI-
     
     
    Guys,
     
    a sneak peek for you! http://www.ti.com/product/msp430fr5969
     
    Regards,
     
    Leo Hendrawan
    --------
     
    Direct link to datasheet: http://www.ti.com/li...sp430fr5969.pdf
    FR58xx and FR59xx user's guide (preliminary): http://www.ti.com/li...367/slau367.pdf
     
    The FR5969 shows a 48VQFN and 100LQFP (PZ) package, but I'm not sure about the latter; pin count is way out of line and the datasheet doesn't even mention it, just the VQFN version. Regardless, according to the datasheet there are plans for the FR5959 to be sold in DA (TSSOP-38) pinout which has 0.65mm pitch pins (easier to DIY). The FR5959 only supports HFXT (high frequency crystals), then the FR5949 only supports LFXT (32.768KHz crystals), but all of those have 64KB FRAM + 2KB SRAM.
     
    Development board listed as "MSP-TS430RGZ48C"
     
    FRAM on these chips still only runs at 8MHz write (125ns write per word), not sure if it's the same on the reads (guessing so).
  19. Like
    Nytblade reacted to jazz in MSP430 USB Benchmark   
    MSP430F550X is full-speed USB devices, 12 Mbits/s (1500 KB/s). Theoretical maximum transfer rate with 19 full-size packets is 19 * 64 bytes / ms = 1200 KB/s. And what about reality?
     
    I am working on CNC project, that is working just fine with uC/PC uart connection at 921600 bps. Problem is that uC/PC traffic is fast, but only few bytes are exchanging, and USB with generic drivers (usbser.sys / winusb.sys) is much slower than uart. Well, for uart connection PL2303HXD USB/uart bridge is used, and it can go fast, so what is the problem. Problem is in drivers, and USB for sure can go fast (with any data), but with customized driver, and this story I will leave for some other time.
     
    During last few weeks I done some tests regarding (CDC) transfer rate, but today I made application just for this. I read on many places on net that winusb.sys (WinXP SP2, and after) is much better (not only more stable) than usbser.sys. Was hoping that it will maybe resolve my (CNC) problems, but it didn't. Generic bulk transfer (winusb.sys) is not suported by TI USB Stack, anyway it was not problem to implement it. On uC side is the same (CDC) code, only enumeration data are different. On PC side, almost the same code. For CDC ReadFile/WriteFile are used and for generic bulk WinUsb_ReadPipe/WinUsb_WritePipe.
     
    I done my first MSP430F5510 board by p2p, long time ago. Later I done another (again p2p) with MSP430F5508. There are 2 4-pins connector, one on left side is for SBW, and another on right side is for USB. Just to show what was used for benchmark testing. If you have something like http://forum.43oh.co...elopment-board/ and poor USB transfer rate, problem is not in board, problem is in software, for sure.
     

     
    Here are the benchmark results for generic bulk transfer. Double buffering and/or ping pong method are/is not used (because it will not give better results). It was 4 MB transfer in both ways, first PC send to uC 4 MB, and after this uC send to PC 4 MB. For each test buffer size (WinUsb_ReadPipe/WinUsb_WritePipe) was changing, 4MB = number of loops * buffer size. It was not dummy transfer, because each side (uC/PC) was marking begining and ending side of packet, before sending, and other side (uC/PC) was checking this values after receiving.
     

    Size: 4 MB (4096 * 1 KB) Dir: MSP430 <- PC Time: 8344 ms Rate: 491 KB/s Dir: MSP430 -> PC Time: 8344 ms Rate: 491 KB/s Size: 4 MB (2048 * 2 KB) Dir: MSP430 <- PC Time: 6219 ms Rate: 659 KB/s Dir: MSP430 -> PC Time: 6234 ms Rate: 657 KB/s Size: 4 MB (1024 * 4 KB) Dir: MSP430 <- PC Time: 5157 ms Rate: 794 KB/s Dir: MSP430 -> PC Time: 5171 ms Rate: 792 KB/s Size: 4 MB (512 * 8 KB) Dir: MSP430 <- PC Time: 4656 ms Rate: 880 KB/s Dir: MSP430 -> PC Time: 4625 ms Rate: 886 KB/s Size: 4 MB (256 * 16 KB) Dir: MSP430 <- PC Time: 4375 ms Rate: 936 KB/s Dir: MSP430 -> PC Time: 4359 ms Rate: 940 KB/s Size: 4 MB (128 * 32 KB) Dir: MSP430 <- PC Time: 4219 ms Rate: 971 KB/s Dir: MSP430 -> PC Time: 4235 ms Rate: 967 KB/s
     
    This test confirmed information available on net, that host must make request with/for biggest possible data size, and in this case transfer rate will be higher. Changing host request from 1 KB to 32 KB, doubled transfer rate.
  20. Like
    Nytblade reacted to gordon in Better MSPDebug integration   
    Fresh find: http://mspdebug.git.sourceforge.net/git ... 94b110f07e
     
    ...and a group bow towards Daniel's general direction!
  21. Like
    Nytblade got a reaction from dacoffey in Internet-connected MSP430 Experimenter Board   
    The maximum size of a DHCP packet is 576 bytes per the RFC.
     
    However, that is not really the problem. I made my code abstract so that the user just passes a pointer to some block of memory and my functions copy the data to the wiznet buffer and flush it out over the internet. I did it this way so that if I wanted to switch to wifi or a different ethernet chip in the future, I would not have to change the entire codebase. I would just add another driver function for the new device.
     
    If you compare this to the Arduino W5100 ethernet and dhcp library, what they are doing is using the wiznet onboard memory buffers directly, to save memory. Of course then their code is littered with all sorts of wiznet-specific hackery. That is not really something I wanted since mine is supposed to be a more general "operating system" that I wouldn't have to keep rewriting. Their code does use less memory though.
     
    In summary, my code works like this: 1) User allocates memory on stack or heap 2) user passes buffer pointer and size to networking functions 3) networking functions hide all the ugly wiznet details and push the data out.
     
    Since I have written my own heap memory allocator, external memory chips should not be too difficult for me to add support for.
     
    To actually answer your question: The amount of free memory should be at least the size of the data the user wants to send. (although there is nothing preventing them from calling send more than once if it is some graphic for a webserver or something like that)
  22. Like
    Nytblade got a reaction from RobG in Internet-connected MSP430 Experimenter Board   
    The maximum size of a DHCP packet is 576 bytes per the RFC.
     
    However, that is not really the problem. I made my code abstract so that the user just passes a pointer to some block of memory and my functions copy the data to the wiznet buffer and flush it out over the internet. I did it this way so that if I wanted to switch to wifi or a different ethernet chip in the future, I would not have to change the entire codebase. I would just add another driver function for the new device.
     
    If you compare this to the Arduino W5100 ethernet and dhcp library, what they are doing is using the wiznet onboard memory buffers directly, to save memory. Of course then their code is littered with all sorts of wiznet-specific hackery. That is not really something I wanted since mine is supposed to be a more general "operating system" that I wouldn't have to keep rewriting. Their code does use less memory though.
     
    In summary, my code works like this: 1) User allocates memory on stack or heap 2) user passes buffer pointer and size to networking functions 3) networking functions hide all the ugly wiznet details and push the data out.
     
    Since I have written my own heap memory allocator, external memory chips should not be too difficult for me to add support for.
     
    To actually answer your question: The amount of free memory should be at least the size of the data the user wants to send. (although there is nothing preventing them from calling send more than once if it is some graphic for a webserver or something like that)
  23. Like
    Nytblade reacted to xpg in ENC28J60 Booster Pack   
    For use on a small micro like the 43oh, I would say that the extra costs are quite ok with the Wiznet. Having the entire IP-stack in the micro controller simply takes up too much flash and requires more RAM than available (thus the external SRAM on the ENC28j60 booster).
    Especially TCP handling takes up large amounts of both flash and RAM.
    While I personally prefer IPv6, I havde to admit that IPv6 is not well adopted, and for many (most?) scenarios IPv4 will do just fine. One of the cool things
    about IPv6 is that I would be able to address all units globally via the Internet. With IPv4 that is just not possible.
     
     
    I really appreciate your information. I chose the ENC28J60-chip as it was the cheapest I could find that did SPI. I found out about the Wiznet chips later when I had started working with the ENC28J60. I might still prefer the ENC28J60 today, mainly due to the fact that I can use IPv6 with it. But as mentioned above, that might not really be a requirement for everyone. The ENC-chip driver that I wrote for my own stack was ported to uIP in an hour or so, and I guess it wouldn't take longer to port it to other IP-stacks as it behaves as a regular MAC/PHY-device. I'm not quite sure how a hybrid devices, such as the Wiznet chips should be driven by uIP.
     
     
    I have considered trying out both Contiki and NuttX on both MSP430F5510 and the Stellaris Launchpad. However, I haven't had the time to take a serious look at them. NuttX seems to support Stellaris LM3s, so it might be the easiest to get working on the Stellaris Launchpad. I even think NuttX has an ENC28J60-driver, so it might be an easy task.
    Anyways, porting any of those OS'es to any of the platforms would be great fun. If anyone is up to it, I will be happy to help. I just don't have the time to do it on my own, currently (I have one of those todo-lists that doesn't know how to shrink).
     
     
    Indeed. I had a quick look at lwip when I started working with the booster on Stellaris, but for some reason decided uIP was easiest to get working. Can't remember why, though. Probably it was a (un)lucky pick. To be honest, I just wanted the thing working as quick as possible
    But I'm curious, so maybe I should try getting the booster working with lwip as well
     
     
    Interesting. I will be following your progress closely. It's cool that your doing your own OS, you will learn plenty from doing that.
    Do you have any design goals for your OS?
  24. Like
    Nytblade reacted to jazz in Timer based Stepper driver   
    I am working on CNC (still software part only) for PCB's. My PC interface application load G files exported from Eagle, and use MSP430F55x with DRV8811 (http://gandalf.zemri...or_control.html) for stepper control. There are 2 Z tools (drill/mill). No need for tool change stoppage, so all job can be completed without user intervention. PC sending simplified G-Code commands to uC, and than uC informs back all the time PC about (all motors) stepping, so there is live animation on the screen about changing of all positions (X, Y, ZM, ZD). If something goes wrong on uC side, PC stops the job.
     
    There is no control panel (leds/buttons) that can be more user friendly than PC interface. And my system will not have any of those, only on/off (or emergency button) and limiter switches.
     
    uC side is written and optimized in assembler (min resolution 0.1 um), and it is fast. If you want to run any kind of G-Code interpreter on uC (100 MHz) side, it will be slow. I tried it at the beginning and late gave up. If you are using uart standard 115200 bps for data exchange, it will be slow again.
     
     

  25. Like
    Nytblade reacted to jazz in Timer based Stepper driver   
    I didn't find any user friendly application regarding PCB milling/drilling topic, and started 3 years ago to work on my own. One day, when the first board will be produced, I will put details about project on 43oh forum, because it is based on MSP430F550x. It will not be open source project, but I will explain PC/uC/stepper used interface (it will be open), give answer to all questions regarding the topic.
     
    As input for PC interface application (picture posted upper), milling "singlesided.bot.etch.tap" and drilling "singlesided.bot.drill.tap" G files (exported from eagle) are used. On the right side of window, there are 2 tolls, for milling (upper) and drilling (lower). On the main part is small white dot that shows X/Y position, and on the tolls part is Z position. I made the screen shoot during milling, so milling tool is scratching the board (red scrached path, and blue will be), and drilling tool is in up position and waiting (holes on board are marked with blue plus). After one G file is processed, job with next file is started.
     
    PC interface application is running on Win XP and it is connected by USB to control board (only MSP430F550x with few parts). Control board is powered by USB and have standard stepper drive connection (STEP, DIR, GND), so it will be possible to use any existing CNC device, just by reconnecting stepper drive connectors from original control board to MSP430F550x board.
     
    All not X/Y/Z command regarding motors from G files are ignored, and there is configuration setup. Ratio is motor resolution value, um needed for one step. So when in G file X change in +/- 5.1 um, motor for X axis will made one fwd/bck step. Delay is used to defined minimum time between 2 steps, or stepper frequency/speed. Delay is separated, and it can be used for example, for drilling tool to go faster up than down, or for milling to go slower when board is milling and faster when toll is moving over the board without milling. There are 2 tolls on Z axis (with at least different X or Y position), and offset is used for zeroing (local X/Y/Z zero position of each tool related to real zero position). For testing and finding all configuration values calibration part is used. My target was to be able to use 4 different steppers for X/Y/ZM/ZD (different number of steps per revolution, and different speed) without any problems.
     

     
    I was working a lot with DS89C4x0 (3 years ago), and started uC code with DS89C4x0 in assembler. Minimum resolution was 0.1 um, and it was working with 3 bytes numbers (for X/Y/Z). DS89C4x0 at 32 MHz, was communicating with PC by serial connection on 2 Mbps (PL2303HXD was used). At the end system was working OK, but I was looking for higher speed and direct USB connection, so later switched to MSP430F550x (0.1 um precision, 4 bytes numbers for X/Y/Z). MSP430F550x is able to process (test mode without running motors using 921600 bps serial connection) sample PCB (upper picture) in 30 seconds.
×
×
  • Create New...