Jump to content
43oh

zeke

Members
  • Content Count

    1,782
  • Joined

  • Last visited

  • Days Won

    102

Reputation Activity

  1. Like
    zeke got a reaction from pine in I like government surplus stores   
    I really like government surplus stores. I mean, reeeeeeally like them.
     
    This week, I bought two HP laserjet printers:
    A Laserjet 5000n which can print 11"x17" and that is great for schematics, and A Laserjet 4350dnt which has the duplexer and a second 500 sheet paper tray. I know I didn't steal them because I have a bill of sale. The total for both printers was $30!
     
    I also got a Fellowes Powershred C-320 paper shredder. That thing can swallow 25 sheets of paper at a time and will not choke!  I paid $80 for it.
     
    So, yeah, I like this government surplus stuff.
  2. Like
    zeke reacted to chicken in GPS logger for a local Beagle club   
    I feel some serious tool-envy
  3. Like
    zeke reacted to greeeg in GPS logger for a local Beagle club   
    Got my enclosures today. That means I now have all the hardware parts for this batch.
     
    I've been playing around with Fusion 360 instead of Rhino, mainly due to the integrated CAM processor. Also it has easy to use rendering stuff out of the box too.
     
    This is the reason I love companies that provide 3d CAD files. I can define some simple stroke text, and Fusion 360 will project it over the 3d curvature of the part.

     
    My CNC setup is in dis-array. The setup is sub optimal.

     
    But I think the results speak for themselves.

     
    I want to experiment with filling the engravings with a paint to make them stand out.
  4. Like
    zeke got a reaction from spirilis in Questions on SFP transceivers in hobbyist projects.   
    Yes, I am glad someone resurrected this topic. I fell into a black hole of busyness after I posted my replies.
     
    If I were to tackle this hardware design myself, I would:
    - pick the serial port
    - configure it for 1Mbps
    - attach LVDS drivers and receivers to the TX and RX pins
    - connect those LVDS ports to the SFP cage
    - connect the I2C port to the SFP module's diag port
    - write a device driver for the SFP module which uses a state machine to keep track of flags and packets and stuff
    - write a test program that does local and remote loopback.
    - write a test program that acts like a serial port bridge
     
    If the serial port talks too slowly then I would find a faster two wire serial peripheral and repurpose it. How about that serial audio interface port? It's pretty fast. I might have to create a circuit to regenerate the clock signal from the optical signal but that's not uncommon.
     
    I'm just thinking out loud.
  5. Like
    zeke reacted to spirilis in Questions on SFP transceivers in hobbyist projects.   
    Lol... Decided to take another look at this thread, as my boss and I were chatting about how many (potentially bad) SFPs we have laying around the office.
     
    So if I'm not mistaken, the SFP has an LVDS interface for the TX and RX side, and you just need an LVDS interface - something like http://www.ti.com/product/ds90lv011a (TX) and http://www.ti.com/product/ds90lv012a (RX) for example (a 400Mbps PHY available for ~$1 at mouser in single qty) - and boom, an LVDS interface you make?
     
    Per https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver - there are lines to disable TX, sense if TX is faulty, and sense if there is no optical RX present.  Sounds simple enough?  Does the transceiver not really give two craps about the speed of the LVDS PHY except for obvious issues that can emerge when you push it to its upper speed limits?  So you could just route the LVDS TTL in/out to the UART, and speak high speed UART over fiber?
    (High-speed differential traces of course respected for the LVDS stuff... luckily my favorite PCB CAD software, DipTrace, now has differential pair management in v3.0+)
     
    Also to make a hobby board out of this I'd need a suitable edge connector for the SFP's.  Unless SFF's are available cheap...
  6. Like
    zeke reacted to spirilis in Questions on SFP transceivers in hobbyist projects.   
    I see SFP cage slots aren't hideous - http://www.mouser.com/ProductDetail/Amphenol-Commercial-Products/U77-A1114-100T/?qs=sGAEpiMZZMtLo%252bUrTGGA8Qu%252bjOiyxwrr - and the edge connectors - http://www.mouser.com/ProductDetail/Amphenol-Commercial-Products/UE75A206000T/?qs=sGAEpiMZZMvlX3nhDDO4ADdPO33nqrQcj0jVg%252b39E7Q%3d - also not too expensive.
     
    Damn.  I might have to get this rolling soon.
  7. Like
    zeke reacted to spirilis in Questions on SFP transceivers in hobbyist projects.   
    Looking up the datasheet for some of the SFP's I have laying around (potentially bad)-
     
    https://www.finisar.com/sites/default/files/downloads/finisar_ftlf8524p2xny_4.25gbs_rohs_compliant_short-wavelength_sfp_transceiver_product_specification_1.pdf
     
    Finisar FTLF8524P2BNV (from a 4Gbps Brocade ED-48000 fiberchannel switch)
     

     
    Sounds like there are different speed-related modes that are switchable via I2C (OR a GPIO toggle) but there is no "Min" in the bitrate...
  8. Like
    zeke reacted to Sterny in Questions on SFP transceivers in hobbyist projects.   
    @@spirilis
     
    Wow, how exciting it is that you decided to resurrect this thread.
     
    I had a quick look at your links.  So along with TI LVD driver chip, and the PHY you linked, is it essentially routing the control and signaling to some GPIOs on a launchpad MCU?  And with that, you'd be able to drive the SFP?
  9. Like
    zeke got a reaction from spirilis in Questions on SFP transceivers in hobbyist projects.   
    @@Sterny,
     
     
     
    I did a lot of work with SFPs from COTSworks. They take SFPs from other vendors and ruggedize them for aeronautics, military and industrial applications. There's no one else that I know of that does this.  That said, I chose to use their SFF-2G-SX-DPLX-LC-R-A SFP module. The datasheet is right there on the page.
     
    Additionally, I studied everything I could on LVDS, PECL, and other differential signalling standards. Here's a couple of links:
    LVDS Fundementals - Fairchild AN-5017 Interface Guide - Texas Instruments Board Design Guidelines for LVDS Systems - Altera I bring up the above links because you will soon discover that the differential interface is not the same between all SFPs. Some are LVDS, others are PECL and others something else weird.  It's a small detail that is only discovered after you bought a few samples that you can't use >:-(
     
    I faced the above challenge because I ended up using SFF modules which are not exactly the same as SFP modules. An SFF has pins and solders into a pcb.
     
    Here's an excellent summary of SFP characteristics.
     
    The SFP manufacturer that I turn to first is always Finisar. In my world, they are the largest manufacturer of SFPs. I would bet money that Cisco and JDSU get theirs made by Finisar.  I know that COTSworks sometimes ruggedizes a particular Finisar module when their customer requests it.
     
    Here's how I classify SFP modules:
    - Glass:  Singlemode or Multimode?
    - Colour:  1310/1550 nm vs 850/1300 nm?
    - Data rate: OC1/3/12/24/48/192/768 ?
    - Distance: practically infinite (SM) vs 2000/550/220m (MM)
    - Cost: SM is usually two to four times the cost of MM electronics
     
     
    For fun, here are a couple of videos on fiber optics that I think are fantastic:
    The Engineer Guy - Fiber optic cables: How they work The Discovery Channel - How's It's Made: Fiber Optics  
    Back to circuitry...
     
    Here is the Finisar FTLX1371D3BCL transceiver datasheet.  It is stuffed with plenty of details that will help you design an interface for it. Look on page 10. There's your basic interface. There are two sections: Signalling and Control.
     
    The Control interface is power, I/O and I2C. All low speed stuff.
     
    The Signalling interface is filtered power, RX and TX. 
     
    You have to translate your single ended signal into an LVDS differential signal. You could make use of an SN65LVDS050-Q1 since it contains two RX/TX pairs. 
     
    Keep this app note from TI on LVDS Interface circuits.
     
    I hope this helps to get the ball rolling.
  10. Like
    zeke reacted to greeeg in structure in Capacitive Touch.   
    See "2.4.2.3 Initializing Structure Members" Here https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Declaring-Structure-Variables-After-Definition
     
    There are a few other ways to assign constant data in structures. It's not normally seen, I'm not sure why. I find it much easier to read/understand.
  11. Like
    zeke got a reaction from greeeg in The Marquee Clock   
    @@greeeg
     
    I am still using the 5529 LaunchPad to develop my code on so I can stick to that context for a little while longer.
     
    I took a look at the 5529 datasheet to learn where the RTC gets its clock source from and it runs off of the ACLK. So, I went back through my code to see how I was setting up the ACLK. Ugh. Turns out that I was still running off of the default internal REFO oscillator and not the external XT1 source. No wonder it wasn't very accurate.
     
    Using TI sample program MSP430F55xx_UCS_04.c as inspiration and guidance, I reprogrammed the 5529:
    To run off of the XT1 external 32kHz crystal To use the internal load capacitors To drive ACLK to using by LFXT1. It will take a while before I can tell if the clock is more accurate now.
  12. Like
    zeke reacted to terjeio in Compact command parser/dispatcher example   
    @@zeke : I am happy that you found my post useful.
     
    My example is a relative primitive command line parser, a command line is always a string (char *) so may contain all kinds (types) of parameters. When calling the function associated with the command I pass the command tail, a pointer to the rest of the command line. It is the up to the called function to parse this and do any required sanity checking/conversions. Some command line parsers may break up the line into an array of strings, usually using space as a delimiter - argc/argv as arguments to main() is an example of that.
     
    The parseInt() function is a poor mans implementation of atoi(), it is inherited from the MSP430G2553 version of my code - atoi() uses quite a bit of RAM so is a no-no when only 512 bytes are available. Here it is:
    int32_t parseInt (char *s) { int32_t c, res = 0, negative = 0; if(*s == '-') { negative = 1; s++; } else if(*s == '+') s++; while((c = *s++) != '\0') { if(c >= 48 && c <= 57) res = (res * 10) + c - 48; } return negative ? -res : res; } Pretty primitive and does not do much sanity checking - but works...
     
    Some of my commands take two numerical parameters - comma separated, to parse them I use:
    bool start (char* params) { char *p2; uint32_t xpixels = 0, ypixels = 0; bool ok = false; if((p2 = strchr(params, ',')) != NULL) { *p2++ = '\0'; ypixels = parseInt(p2); } xpixels = parseInt(params); if(xpixels == 0 || ypixels == 0) serialWriteLn("Bad/missing parameters"); else { ... Hope this helps.
     
    Terje
  13. Like
    zeke reacted to terjeio in Compact command parser/dispatcher example   
    @@zeke - converting code from switch/case statements is just creating a function of/for each case: ... break; block with signature as defined for the handler in the command struct. The handler signature can of course be changed to suit your needs.
     
    Another use of pointer to functions is for implementing a HAL (Hardware Abstraction Layer), I am going to use that approach in my port of Grbl to Tiva C. I find using #defines in the main code (as it stands now) makes it messy and hard to read and modify - using function pointers instead clearly defines the signatures of the functions to be implemented and there is (in theory) no need to change the main code for a new HAL/processor implementation.
     
    This is my current HAL structure for Grbl:
    typedef struct { void (*initMPU)(struct HAL *hal); void (*releaseMPU)(void); void (*serial_write)(uint8_t data); uint8_t (*serial_read)(void); void (*limits_disable)(void); uint8_t (*limits_get_state)(void); void (*coolant_stop)(void); void (*coolant_set_state)(uint8_t mode); void (*delay_ms)(uint16_t ms); void (*delay_us)(uint32_t us); uint8_t (*probe_get_state)(uint8_t probe_invert_mask); void (*spindle_stop)(void); void (*spindle_set_state)(uint8_t state, float rpm); uint8_t (*system_check_safety_door_ajar)(void); void (*stepper_wake_up)(uint8_t pulse_time); void (*stepper_go_idle)(void); void (*stepper_disable)(uint8_t state); void (*stepper_set_outputs)(uint8_t step_outbits); void (*stepper_set_directions)(uint8_t dir_outbits); void (*stepper_cycles_per_tick)(uint16_t cycles_per_tick); void (*stepper_pulse_time)(uint8_t cycles_per_tick); uint8_t (*uart_receive_data)(void); void (*uart_send_data)(uint8_t data); void (*uart_int_enable)(bool on); // callbacks - set up by library before MCU init uint8_t (*stepper_driver_interrupt_callback)(void); uint8_t (*stepper_reset_interrupt_callback)(void); uint8_t (*stepper_delay_interrupt_callback)(void); void (*limit_interrupt_callback)(void); void (*control_interrupt_callback)(uint8_t pin); settings_t *settings; } HAL; IIRC TIs graphics library has implemented the driver HAL in the same/similar way.
  14. Like
    zeke reacted to yyrkoon in Compact command parser/dispatcher example   
    @@zeke
     
    Function pointers in C. I'd have to try and dig up the link I had a long time ago, but it was used for . . .well state machines. Typically state machines in C use if/else, or switch statements. But as @@terjeio has shown here, you can use function pointers as well.
  15. Like
    zeke reacted to terjeio in Compact command parser/dispatcher example   
    @@zeke - ok I'll try, here is the setEchoMode function as I have implemented it:
    bool setEchoMode (char* params) { echo = parseInt(params) != 0; return true; } echo is a boolean variable - command will be either "Echo:0" (off) or "Echo:1" (on - in fact any parameter value diferent from 0 will set echo to true).
    this version relies on my parseInt function, code can be simplified to:
    bool setEchoMode (char* params) {     echo = *params == '1';     return true; } with improved parameter checking and proper status return:
    bool setEchoMode (char* params) { if(*params == '1') { echo = true; return true; } else if(*params == '0') { echo = false; return true; } else return false; } I am using ":" as command/parameter separator, I have added this to the command in the command list so easy to change.
  16. Like
    zeke got a reaction from spirilis in Compact command parser/dispatcher example   
    I was just thinking about this command line stuff as I work on my marquee clock code.
     
    My way is so cumbersome and tedious if I want to add in more commands.
     
    You way is pretty straight forward.
     
    <YOINK!>
     
    Thanks!
  17. Like
    zeke reacted to yyrkoon in Compact command parser/dispatcher example   
    http://www.cprogramming.com/tutorial/function-pointers.html
     
    Cant find the link I was looking for, but this guy usually gets the point across. But the term I was looking for above in my last post was "PID controller", and the link I had was from a guy who illustrated the concept in code using 4 functions pointers( perfectly ). Maybe I'll be able to find it again ? Then more importantly the code was simple, so not a hard read to figure out.
     
    EDIT:
    Here it is: https://kjarvel.wordpress.com/2011/10/26/table-driven-state-machine-using-function-pointers-in-c/ but not exactly what I remember it to be. But one goo reason to put information up on this forum http://forum.43oh.com/topic/324-best-information-for-those-new-to-the-msp430/?p=27295 Because you get to run into it again if you need it and otherwise impossible to find on the web.
     
    Anyhow the guy illustrates a state machine using function ptr's, but not a PID like I was remembering.
  18. Like
    zeke reacted to bluehash in Compact command parser/dispatcher example   
    Thank you for sharing!
    Also as an FYI... Tivaware also has a similar parser, under utils/cmdline.c
  19. Like
    zeke reacted to terjeio in Compact command parser/dispatcher example   
    A command parser/dispatcher example from my CO2 laser engraver codebase, using a struct array containing the commands and associated  pointer to functions. A lot cleaner (and easier to maintain) than switch/case statements or if/else constructs...
    Functions get called with a pointer to the command tail for local parameter parsing.
    The struct array data are all placed in flash.
    typedef struct { char const *const command; bool (*const handler)(char *); const bool report; } command; bool query (char* params); bool start (char* params); bool moveXrel (char* params); bool moveYrel (char* params); bool moveZrel (char* params); bool XHome (char* params); bool YHome (char* params); bool ZHome (char* params); bool XYHome (char* params); bool zeroAllAxes (char* params); bool laser (char* params); bool setLaserPower (char* params); bool setImageDPI (char* params); bool setPulseDutyCycle (char* params); bool enableCoolant (char* params); bool enableAirAssist (char* params); bool setMode (char* params); bool getPosition (char* params); bool setPPI (char* params); bool setPulseWidth (char* params); bool enableExhaustFan (char* params); bool setEngravingSpeed (char* params); bool getStatus (char* params); bool setEchoMode (char* params); bool setAMode (char* params); bool setPWROffset (char* params); bool loadProfile (char* params); bool setXBcomp (char* params); void exeCommand (char *cmdline) { static const command commands[] = { "?", &query, true, "Power:", &setLaserPower, true, "DutyCycle:", &setPulseDutyCycle, true, "PulseWidth:", &setPulseWidth, true, "DPI:", &setImageDPI, true, "Start:", &start, true, "X:", &moveXrel, true, "Y:", &moveYrel, true, "Z:", &moveZrel, true, "HomeXY", &XYHome, true, "HomeX", &XHome, true, "HomeY", &YHome, true, "HomeZ", &ZHome, true, "ZeroAll", &zeroAllAxes, true, "Laser:", &laser, true, "Coolant:", &enableCoolant, true, "Air:", &enableAirAssist, true, "Mach3:", &setMode, true, "Pos", &getPosition, false, "PPI:", &setPPI, true, "Exhaust:", &enableExhaustFan, true, "Speed:", &setEngravingSpeed, true, "Status", &getStatus, false, "ASelect:", &setAMode, true, "PWROffset:", &setPWROffset, true, "LoadProfile:", &loadProfile, true, "XBComp:", &setXBcomp, true, "Echo:", &setEchoMode, false }; bool ok = false; uint32_t i = 0, numcmds = sizeof(commands) / sizeof(command), cmdlen; while(!ok && i < numcmds) { cmdlen = strlen(commands[i].command); if(!(ok = !strncmp(commands[i].command, cmdline, cmdlen))) i++; } if(ok) { ok = commands[i].handler(cmdline + cmdlen); if(commands[i].report) serialWriteLn(ok ? "OK" : "FAILED")); } else serialWriteLn("Bad command"); } For further reading see http://www.barrgroup.com/Embedded-Systems/How-To/C-Function-Pointers
     
     
     
  20. Like
    zeke reacted to greeeg in The Marquee Clock   
    @@zeke That's quite a speedup. About 0.5% by my calculation. No where near the +\-50ppm a watch crystal should run at.
     
    If you don't have enough capacitance loading on your crystal it will run faster (or maybe slower...). It's important to get the loading right, esspecially for a 32.768 kHz crystal, since small changes in oscillating frequency add up over time.
    Since the F5529 doesn't have internal load caps they should be external.
     
    What value are your loading caps currently? (looks like they're C16 and C17 on your PCB)
    Do you have a datasheet for the crystal you're using?
  21. Like
    zeke got a reaction from yyrkoon in MSP430G2 emulator.   
    You could also bust out one of those old V1.5 G2 LPs and make your own pluggable LP.
     
    All the parts are in the V1.5 G2 LP box right now.
     
     
    It will look like this:
     

     
    Then plug that into the ZIF socket and away you go!
  22. Like
    zeke got a reaction from Fmilburn in SD card reader Sleep   
    @@bhills
     
    That fr5969 has 64KB of *FRAM* on board. You could use that to your advantage.
     
    Why not do periodic writes to the FRAM? Then, at some power budget friendly interval (say one day), power up that SD Card and dump the FRAM buffer contents to it.
     
    What do you think?
  23. Like
    zeke got a reaction from yyrkoon in MSP430G2 emulator.   
    For future reference, here's a schematic for a bare bones LaunchPad using a 20 pin DIP package:
     
    http://forum.43oh.com/topic/5520-randomelectrons-lp10062/?p=48226
     
     
  24. Like
    zeke got a reaction from yyrkoon in MSP430G2 emulator.   
    @@Rickta59
     
    Nah. I'm good.
     
    Anythiing to help a friend.
  25. Like
    zeke got a reaction from yyrkoon in MSP430G2 emulator.   
    The only issue is usually power - who provides it.
     
    Normally, the G2 LP will supply all the power to the target msp430 but the Wulf board wants to supply it as well.
     
    So, you will have to make a choice of which board ought to supply the power.
     
    If the Wulf board had proper circuitry on the TEST and RST lines then you would have to ask questions about that as well. But it doesn't so that's off the checklist.
×
×
  • Create New...