Jump to content
43oh

zeke

Members
  • Content Count

    1,782
  • Joined

  • Last visited

  • Days Won

    102

Reputation Activity

  1. Like
    zeke reacted to phenyl in One Wire Controller booster   
    Hi @@zeke
     
    in my (limited) opinion, their work is good. Here's a board (the gerbers came from an eevblog member,[1] not mine) I had made privately:
     







     
    I had some made, the one I soldered the components on works perfectly.
     
    Of the ones from work I don't have any pictures obviously, they were only for a small project with a few components. The finish there was ENIG, which also turned out really well.
     
     
    [1] http://www.eevblog.com/forum/testgear/point-me-to-latest-info-on-dyi-dsoxlan/msg823148/#msg823148
  2. Like
    zeke reacted to phenyl in One Wire Controller booster   
    Hi Zeke,
     
    I was using http://www.pcbway.com/ at work and for a private project or two. At work we paid for fast shipping on some small simple boards that we needed quickly, the boards got here in less than a work week and looked good (and performed well). Otherwise you can check on http://www.pcbshopper.com/, they run comparisons on your size and time-requirements to help you find the optimal boardhouse.
     
    (I am unaffiliated with either company, only a customer and I used pcbshoppers website).
  3. Like
    zeke got a reaction from Fred in T-962 Reflow Oven   
    Your comments about a vacuum pickup tool reminded me that I want to build this manual pick and place rig for myself:
     
    http://vpapanik.blogspot.ca/2012/11/low-budget-manual-pick-place.html
  4. Like
    zeke got a reaction from Fmilburn in One Wire Controller booster   
    I am excited about this one. I finally made some time to work on my one wire controller board tonight.  I placed all the component on it tonight and it looks good to me. 
     
    This design has a single DS2482 One Wire Master controller servicing eight one wire ports that will be selectively enabled with analog switches.
     
    The MSP430 will talk to the DS2482 via I2C and it will take care of all the communication timing.
     
    Theoretically, you could hook up an obscene number of DS18B20 temperature sensors to this. In the lab, I have testing this circuit with about 600 DS18B20 sensors on it. 
     
    Practically, you would be limited by the capacitance of the cable as the lengths increased. There was no cable in the lab test.
     
    This board will work with any one wire devices so you are not limited to just temperature sensors.
     
     
    The intention is to create a mating board that contains an MSP430, power supply, mass storage device and communications. That board will be one of my re-launchpad board designs. Probably the 5529 based design so I can get the USB port.
     
    What do you guys think?
     
    Edit: Added schematic PDF.

    RE-OWC-1-10062.PDF
  5. Like
    zeke got a reaction from Fmilburn in T-962 Reflow Oven   
    Your comments about a vacuum pickup tool reminded me that I want to build this manual pick and place rig for myself:
     
    http://vpapanik.blogspot.ca/2012/11/low-budget-manual-pick-place.html
  6. Like
    zeke got a reaction from yyrkoon in T-962 Reflow Oven   
    Your comments about a vacuum pickup tool reminded me that I want to build this manual pick and place rig for myself:
     
    http://vpapanik.blogspot.ca/2012/11/low-budget-manual-pick-place.html
  7. Like
    zeke reacted to RobG in Need a buck switching power supply design   
    How about LM2576? They are super simple and dirt cheap (~$1.25 for all parts,) used them in few projects.
    They are only 3A, but you could split your supply rail and use two of them.
     

  8. Like
    zeke reacted to USWaterRockets in Need a buck switching power supply design   
    I've had good luck with the TI Nanomodules. I've used the LMZ21700 in a project to get 5V @ 650mA from a 4S LiPo battery.  I've been working on another design using the TPS81256.
     
    I know these parts don't meet your exact requirements, but I'm just pointing out that I've been happy with the experience I have had with the TI nanomodules I've used so far. Take it for what that's worth.
  9. Like
    zeke got a reaction from spirilis in Need a buck switching power supply design   
    Yeah, those MuRata modules are pretty great in many respects except one. Their cost does not scale downwards when you buy in large quantities.
     
    For example, the OKL-T/3-W12N-C pricing looks like this:
     

     
     
    But!  I managed to find a TI part that would scale down quite well in quantity.
     
    The LM43603PWPT pricing looks like this:  
     

     
     
    And this is the simplified schematic. There's not too many parts there. Only the inductor will add significant cost to the BOM.
     

     
     
    These are the features that I like:
    3.5V < Vin < 36V Vout (max) = 28V Iout <= 3A Step down regulator Output = adjustable  16 pin TSSOP package  
    I have to redo the BOM cost analysis but I am seriously considering using this part over the MuRata part. 
       
     
  10. Like
    zeke reacted to veryalive in Need a buck switching power supply design   
    Two in parallel?
  11. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    Hmm.  What next...
     
    I said next I'd do networking.  I think in preparation for that I should remake the gatekeeper task into a C++ class that's semi-encapsulated away (for simplicity's sake and to start down that path), then make it into a task utilizing GPIO SPI chip select management, SPI write/read/read & write, and uDMA.
     
    After that, the SimpleLink WiFi CC3100 library should be attempted on Tiva.
  12. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    OK, brief rundown of the "analysis" process for getting started with uDMA.
     
    A cursory look at the uDMA chapter in the TM4C123GH6PM datasheet:
    Micro Direct Memory Access (?DMA)The TM4C123GH6PM microcontroller includes a Direct Memory Access (DMA) controller, knownas micro-DMA (?DMA). The ?DMA controller provides a way to offload data transfer tasks from theCortex

  13. Like
    zeke reacted to roadrunner84 in Stupidest Thing you had to Troubleshoot?   
    printf and friends are very hungry beasts, for integer to hex string and vice versa I prefer manual conversions.
    const char *const hex = "0123456789ABCDEF"; unsigned long input = 10; char output[9]; char *result = output; for(unsigned int ctr = 28; ctr; ctr -= 4) *result++ = hex[(input >> ctr) & 0xF]; *result = '\0'; something like this.
  14. Like
    zeke got a reaction from roadrunner84 in RANT: Cloud of this, IoT of that . . .   
    Ten years ago, IoT used to be labeled M2M or machine to machine. It was a fad as well.
     
    It's crazy how marketing can make me feel like my work is worthless unless I implement "that one killer feature".
     
    I think it's best for me to ignore the false sense of inadequacy and just be awesome at doing and making the things that I like.
  15. Like
    zeke reacted to tripwire in My time with FreeRTOS on the TM4C   
    At the moment the code is using basic DMA transfer mode, which means the CPU has to wake up to prepare the next DMA transfer.
     
    The ARM uDMA also offers ping-pong mode, where it automatically kicks off a second transfer once the first is completed. Meanwhile the CPU wakes up to set the inactive DMA control structure up for the next transfer. This double buffering means the DMA is kept active and doesn't have to wait on the CPU.
     
    Finally there's scatter/gather mode, where the DMA module writes its own control structure(s), allowing up to 256 pre-planned transfers. That one's the most fun
     
     
    I'm curious about that too. I'm wondering why SPI_CLK has pauses between bytes in the latest zoomed in scope trace. What with the TX FIFO and DMA feeding the SSI I'd have hoped the Tiva would manage continuous output at 8MHz.
  16. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    Turns out that was only part of what I was missing.
     
    Also forgot this piece:
    MAP_uDMAChannelAssign( UDMA_CH13_SSI2TX ); Yeah that might be important.  This configures the UDMACHMAPx registers to assign a particular DMA channel to a particular peripheral trigger that it supports.
     
    Then we get beautiful, tight, SPI output:

     

     
    Note the PF_2 waveform at the bottom, i.e. logic analyzer channel #2.  It transitions up or down every time an IRQ occurs.  Notice how infrequently that is.. relative to the sheer amount of data passing over the wire.  That's the value of DMA.
    In between those IRQ firings, other tasks may run - the SPI gatekeeper task isn't spinning CPU cycles polling the MAP_SSI_Busy() function.  This is implemented by the SPI Gatekeeper task pending on its own task-ISR binary semaphore (which makes the task sleep).  The real "running thread" for SPI I/O is inside dedicated hardware, separate from the Cortex-M4 CPU and separate from FreeRTOS control, that of the UDMA controller itself.
  17. Like
    zeke got a reaction from greeeg in The Marquee Clock   
    Here's a brief update.
     
    I've been working on the layout for the display board.
     

     
    I rearranged the LEDs so that they could be properly soldered by hand (if that is needed).
     

     
    Now, I must make some design decisions:
    - Should I include an on-board buck power supply on this Alpha design?
    - Should I include an on-board CPU on this Alpha design?
    - Should I include an off-board interface (set of pins) for an off-board CPU daughter board?
     
    To overcome my decision fatigue, I might have to include everything, test it, delete from the design all that doesn't make sense then create a Beta PCB design.
     
    Oh, also, it was a challenge but I managed to procure an adequate supply of LEDs for the prototypes that need to be assembled.

     
    How many do you see here?

     
     
  18. Like
    zeke got a reaction from abecedarian in The Marquee Clock   
    Here's a brief update.
     
    I've been working on the layout for the display board.
     

     
    I rearranged the LEDs so that they could be properly soldered by hand (if that is needed).
     

     
    Now, I must make some design decisions:
    - Should I include an on-board buck power supply on this Alpha design?
    - Should I include an on-board CPU on this Alpha design?
    - Should I include an off-board interface (set of pins) for an off-board CPU daughter board?
     
    To overcome my decision fatigue, I might have to include everything, test it, delete from the design all that doesn't make sense then create a Beta PCB design.
     
    Oh, also, it was a challenge but I managed to procure an adequate supply of LEDs for the prototypes that need to be assembled.

     
    How many do you see here?

     
     
  19. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    Allrighty... got a handle on things here.
     
    Indeed it was insufficient memory, and FreeRTOS's options for investigating these matters is decent enough.
     
    They mostly reside around a hook function you can define (vApplicationStackOverflowHook()) which is required based on the value of #define configCHECK_FOR_STACK_OVERFLOW in your FreeRTOSConfig.h:
     
    ================
    #define configCHECK_FOR_STACK_OVERFLOW (1 or 2)   Executes vApplicationStackOverflowHook( TaskHandle_t *pxTask, signed char *pcTaskName ) - supplied by the user   Method 1 (#define set to 1):   A task's entire execution context is saved onto its stack each time it gets swapped out.  It is likely that this will be the time at which stack usage reaches its peak.  When configCHECK_FOR_STACK_OVERFLOW is set to 1, the kernel checks that the stack pointer remains within the valid stack space after the context has been saved.  The stack overflow hook is called if the stack pointer is found to be outside its valid range.   Method 1 is quick to execute, but can miss stack overflows that occur between context switches.   Method 2 (#define set to 2):   When a task is created, its stack is filled with a known pattern.  Method 2 tests the last valid 20* bytes of the task stack space to verify that this pattern has not been overwritten.  The stack overflow hook function is called if any of the 20 bytes have changed from their expected values.   Method 2 is not as quick to execute as method 1, but is still relatively fast, as only 20 bytes are tested.  Most likely, it will catch all stack overflows; however, it is possible (but highly improbable) that some overflows will be missed.   * - per include/StackMacros.h, it's actually 16 bytes, not 20? ================   My stack size assigned to all 3 tasks was initially 32.  As it turns out, the value needs to be 39 at the minimum (for task1/task2, GK task needs less) to satisfy all tasks' needs.  I'll show you how I discovered (please copy this function all you want):  
    volatile signed char *stackovf_ptrs[8]; void vApplicationStackOverflowHook(TaskHandle_t *pxTask, signed char *pcTaskName) { int i=0; MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, GPIO_PIN_1); // red LED comes on indicating stack overflow for (i=0; i < 8; i++) { if (stackovf_ptrs[i] == NULL || stackovf_ptrs[i] == pcTaskName) { // ensure we record a task only once (return; is important) stackovf_ptrs[i] = pcTaskName; // pointer to task name string, which should be easy to identify in the debugger return; } } } For quick reference, here's what actually happens during context switch with configCHECK_FOR_STACK_SIZE == 1, from FreeRTOS/include/StackMacros.h:
    #if( ( configCHECK_FOR_STACK_OVERFLOW == 1 ) && ( portSTACK_GROWTH < 0 ) ) /* Only the current stack state is to be checked. */ #define taskCHECK_FOR_STACK_OVERFLOW() \ { \ /* Is the currently saved stack pointer within the stack limit? */ \ if( pxCurrentTCB->pxTopOfStack <= pxCurrentTCB->pxStack ) \ { \ vApplicationStackOverflowHook( ( TaskHandle_t ) pxCurrentTCB, pxCurrentTCB->pcTaskName ); \ } \ } #endif /* configCHECK_FOR_STACK_OVERFLOW == 1 */ and for configCHECK_FOR_STACK_OVERFLOW == 2:
    #if( ( configCHECK_FOR_STACK_OVERFLOW > 1 ) && ( portSTACK_GROWTH < 0 ) ) #define taskCHECK_FOR_STACK_OVERFLOW() \ { \ const uint32_t * const pulStack = ( uint32_t * ) pxCurrentTCB->pxStack; \ const uint32_t ulCheckValue = ( uint32_t ) 0xa5a5a5a5; \ \ if( ( pulStack[ 0 ] != ulCheckValue ) || \ ( pulStack[ 1 ] != ulCheckValue ) || \ ( pulStack[ 2 ] != ulCheckValue ) || \ ( pulStack[ 3 ] != ulCheckValue ) ) \ { \ vApplicationStackOverflowHook( ( TaskHandle_t ) pxCurrentTCB, pxCurrentTCB->pcTaskName ); \ } \ } #endif /* #if( configCHECK_FOR_STACK_OVERFLOW > 1 ) */ Method #2 is a stack coloration technique albeit using a single byte, not a pattern, but that's obviously easier to implement (and probably cheaper on CPU) at context-switch time.  I find it odd that Richard's book (the FreeRTOS maintainer) says it requires 20 bytes yet the code clearly only compares four 32-bit integers... so I assume it only needs 16 bytes.
     
    Using method#2, I've set all 3 tasks (task1 The quick brown fox, task2 bluehash runs a great forum, and the Gatekeeper task) to 36 (words), which would be the original value of 32 plus 4 words to account for the required 16-byte (4-word) buffer in the stack coloration:
     
    Debugger showing that all three tasks overran their stack:   Incidentally, despite overrunning their stack, 36 words is enough to make the SPI traffic look correct:   Method #2 for stack analysis is rather nice I would say since it lets you detect stack overrun with a margin of error and correctly ascertain between-context-switch limits.   Using a value of 37 for all 3 of the tasks:  
    All three tasks ran within or over 16 bytes of their stack.
     
    Value 38:

     
    Value 39:

     
    Jumped ahead, the gatekeeper task quit overrunning at 41:

     
    Finally the main SPI transfer tasks quit at 43:

     

     
    So technically the gatekeeper task requires (41-4 =) 37 words of stack space, and client transfer tasks require (43-4 =) 39 words.
     
    Testing that with method #1, which doesn't color the stack and doesn't require a margin... everything looks good.
     
    As a quick tip, when going from configCHECK_FOR_STACK_SIZE 2 to 1, it registered stack violation with sizes 37 and 39 (for GK and transfer tasks).  I forgot to Rebuild Project - thus any time you modify FreeRTOSConfig.h be sure to rebuild the whole project instead of just hitting the build button.  After rebuilding the project it ran cleanly with no red LED (and no entries in stackovf_ptrs).
  20. Like
    zeke reacted to veryalive in My time with FreeRTOS on the TM4C   
    super work, mister spirilis !!
  21. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    Yeah if power/battery/lack of access to ethernet is no concern, the TM4C1294 or E is a beast on resources and peripherals. Just a beast. 
    So next I plan to do gatekeeper SPI, then I want to touch uDMA as I've never done DMA work and want to. With a gatekeeper task.
     
    After that networking should be attempted but I dunno which way to go. Since there is already an example for it, maybe FreeRTOS+uIP on TM4C1294 will be easier. I do need to figure out SimpleLinkWiFi for CC3100 for future projects at some point.
  22. Like
    zeke reacted to Clavier in MIDI Booster Pack   
    And it links to this thread!
     
    And the schematic is capable of improvement: the output connector's pin 2 must be grounded; the unused inverters' inputs must not float; the optocoupler needs a resistor of about 10 k? between pins 5 and 7; and it needs a decoupling capacitor between pins 5 and 8.
  23. Like
    zeke got a reaction from spirilis in My time with FreeRTOS on the TM4C   
    @@spirilis
     
    Wow!
     
    I can't thank you enough. I ran out of my quota for giving thanks on the forum.
     
    Excellent work!
     
    Please keep going. I'm a willing student. :-)
  24. Like
    zeke reacted to tripwire in My time with FreeRTOS on the TM4C   
    This is where it gets really interesting! Any RTOS can turn out a clean-looking led blinking program. The true test is how it deals with shared resources. I'm looking forward to the next few posts!
  25. Like
    zeke reacted to spirilis in My time with FreeRTOS on the TM4C   
    RTOS concurrency and communications peripherals.  How about we take 2 tasks and have them both spam the SPI peripheral on the Tiva with output?
     
    main.c:
    /* * main.c */ #include <FreeRTOS.h> #include <task.h> #include <stdint.h> #include <stdbool.h> #include "inc/hw_types.h" #include "inc/hw_ints.h" #include "inc/hw_memmap.h" #include "inc/hw_gpio.h" #include "driverlib/gpio.h" #include "driverlib/pin_map.h" #include "driverlib/rom.h" #include "driverlib/rom_map.h" #include "driverlib/sysctl.h" #include "driverlib/ssi.h" // for SPI #include <string.h> // for strlen() void Task_SPI_Transfer(void *); int main(void) { MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2); // SSI2 on PB4/PB6/PB7 MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); // Need this to configure PB for SSI usage while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_SSI2)) ; while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOB)) ; // Configure PB4, PB6, PB7 as SSI pins MAP_GPIOPinTypeSSI(GPIO_PORTB_BASE, (GPIO_PIN_4 | GPIO_PIN_6 | GPIO_PIN_7) ); /* Sadly, it's not just enough to configure GPIO pins for the correct peripheral. You also have to set a register called GPIOPCTL for these. * * Register 22: GPIO Port Control (GPIOPCTL), offset 0x52C * The GPIOPCTL register is used in conjunction with the GPIOAFSEL register and selects the specific * peripheral signal for each GPIO pin when using the alternate function mode. Most bits in the * GPIOAFSEL register are cleared on reset, therefore most GPIO pins are configured as GPIOs by * default. When a bit is set in the GPIOAFSEL register, the corresponding GPIO signal is controlled * by an associated peripheral. The GPIOPCTL register selects one out of a set of peripheral functions * for each GPIO, providing additional flexibility in signal definition. */ MAP_GPIOPinConfigure(GPIO_PB4_SSI2CLK); MAP_GPIOPinConfigure(GPIO_PB6_SSI2RX); MAP_GPIOPinConfigure(GPIO_PB7_SSI2TX); // Init SSI2 MAP_SSIClockSourceSet(SSI2_BASE, SSI_CLOCK_SYSTEM); // System CPU clock used MAP_SSIConfigSetExpClk(SSI2_BASE, MAP_SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 8000000, 8); // 8MHz SPI, mode 0, 8 bits MAP_SSIEnable(SSI2_BASE); // SPI peripheral is now live. // Two EQUAL PRIORITY tasks will continously duke it out trying to send SPI data. // Prototype for xTaskCreate: // BaseType_t xTaskCreate( TaskFunction_t pvTaskCode, // const char * const pcName, // uint16_t usStackDepth, // void *pvParameters, // UBaseType_t uxPriority, // TaskHandle_t *pvCreatedTask); xTaskCreate(Task_SPI_Transfer, "Task1", 32, "The quick brown fox", 4, NULL); xTaskCreate(Task_SPI_Transfer, "Task2", 32, "bluehash runs a great forum", 4, NULL); vTaskStartScheduler(); // Start FreeRTOS! while(1) ; // Shouldn't get here. return 0; } void Task_SPI_Transfer(void *pvParameters) { const char *str = (const char *)pvParameters; const size_t slen = strlen(str); size_t i = 0; while (1) { // Wait for SPI peripheral to stop transmitting while (MAP_SSIBusy(SSI2_BASE)) ; // Stuff the FIFO full while (MAP_SSIDataPutNonBlocking(SSI2_BASE, str[i]) > 0) { i++; // Note: do not be tempted to use "str[i++]" in the while() statement for this. It will increment 'i' even if the call fails. if (i >= slen) { i = 0; } } } } After capturing 100ms of the output, my Saleae Logic16's software did a protocol analysis of the SPI data and after mangling it a bit with GNU awk, here's what it looks like (apostrophes are meant to be spaces):
    b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f o r u m b l u e h a s h ' r u n s ' a ' g r e a t ' f T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n ' f o x T h e ' q u Besides the endless accolades it provides for @@bluehash, of note is that you can tell when the RTOS tick "task switch" occurred:
     
    b l u e h a s h ' r u n s ' a ' g r e a t ' f T h e ' q u i c k ' b r o w n ' f o x T h e ' q u i c k ' b r o w n
     
    Now that's no good!  Even if the point was to spam the SPI bus with data, doing so in coherent blocks/sentences would be preferable.  Those sentences could be coherent blocks of data or control information for an Ethernet peripheral, SPI-attached radio (CC3100, nRF24L01+, etc) or who knows.  Having the data cut in the middle of a logically-contiguous block could cause corruption (especially if separate SPI Chip Select lines are used - but - the task never had a chance to complete its SPI I/O and then deselect the intended peripheral's SPI CS line before the next task goes to town).  Moreover, electrical problems/short circuits could result if multiple SPI slave devices try driving the MISO line due to more than 1 having their Chip Select line selected.  How do we manage this in an RTOS environment?
     
    One way is using Mutual Exclusion - mutex's - and having a common mutex for an SPI peripheral.  Another way, would be a "gatekeeper" task - a task specifically designed to perform SPI communication on everyone else's behalf, using RTOS queues to pass the buffers back and forth.  This gatekeeper task would take a single request off the queue, then run it to completion, returning the results in a private queue encapsulated inside the request for the original caller to digest - all the while, NOT reading from the queue so that other tasks attempting to use the SPI bus will halt.  I am going to try the Mutex idea first, then the gatekeeper task.
×
×
  • Create New...