Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    tripwire got a reaction from zeke 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!
  2. Like
    tripwire reacted to chicken in The excitement of ordering parts on Ebay   
    That's what I get for being a cheapskate:

    Arguably, the listing does not specify the orientation of the connector. But the picture on the listing, even though out of focus, still shows vertical connectors.
    The seller didn't answer yet, so I still assume it was a genuine mix-up.
    [Edit: It was a mix-up, the seller will send me replacements.]
    What were your predictable sourcing mishaps?
  3. Like
    tripwire 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 */ #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.
  4. Like
    tripwire reacted to spirilis in My time with FreeRTOS on the TM4C   
    Picking this forum for a blog thread on learning the "ropes" of FreeRTOS.  TM4C123 launchpad is my learning board for now, using CCSv6 under Windows, latest FreeRTOS and the GNU GCC compiler that ships with CCS (Linaro).
    From a fresh download of FreeRTOS, I finally have a working example (not relying on "importing" a CCS example and modifying it - you learn more this way).  Here's main.cpp with all the init + task code:
    /* * main.c */ #include <FreeRTOS.h> #include <task.h> #include <timers.h> #include <stdint.h> #include <stdbool.h> #include "inc/hw_memmap.h" #include "inc/hw_types.h" #include "inc/hw_ints.h" #include "inc/hw_gpio.h" #include "driverlib/gpio.h" #include "driverlib/interrupt.h" #include "driverlib/pin_map.h" #include "driverlib/rom.h" #include "driverlib/rom_map.h" #include "driverlib/sysctl.h" void UsrSW1_Monitor(void *); int main(void) { MAP_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); while (!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF)) ; MAP_GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_0 | GPIO_PIN_4); MAP_GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_0 | GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU); MAP_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3); MAP_GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD); if (pdTRUE != xTaskCreate(UsrSW1_Monitor, "Pushbutton_Monitor", 48, NULL, 3, NULL)) { // Crash due to insufficient heap memory? MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_PIN_1 | GPIO_PIN_2); // Illuminate R+B for purple while(1) ; } //xTaskCreate(NullTask, "Nothing", 48, (void *)1, 4, NULL); vTaskStartScheduler(); // If FreeRTOS ever exits, illuminate orange (R+G) MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_PIN_1 | GPIO_PIN_3); while(1) ; return 0; } void BlinkyTask_LEDBlink(void *pvParams) { unsigned int whichLed = (unsigned int)pvParams; uint8_t whichBit = 1 << whichLed; uint8_t currentValue = 0; while (1) { currentValue ^= whichBit; MAP_GPIOPinWrite(GPIO_PORTF_BASE, whichBit, currentValue); vTaskDelay(250 / portTICK_RATE_MS); } } void UsrSW1_Monitor(void *pvParams) { uint16_t inputShifter = 0; bool inputLatched = false; const uint32_t USR_SW1 = GPIO_PIN_4; // PF4 uint8_t whichLed = 1; xTaskHandle blinkerTask; // Start blinker task with current whichLed value. if (pdTRUE != xTaskCreate(BlinkyTask_LEDBlink, "Blinker", 32, (void*)whichLed, 4, &blinkerTask)) { // Crash due to insufficient heap memory? Halt scheduler and hold all RGB LEDs to white. vTaskSuspendAll(); MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3); while(1) ; } while (1) { // Poll USR_SW1 GPIO - active LOW if (MAP_GPIOPinRead(GPIO_PORTF_BASE, USR_SW1)) { inputShifter <<= 1; } else { inputShifter <<= 1; inputShifter |= 1; } // Test if button has been pressed or released if ( !inputLatched && (inputShifter & 0xF0) == 0xF0 ) { // Rotate LED whichLed++; if (whichLed > 3) { whichLed = 1; } // Kill blinker task vTaskDelete(blinkerTask); // Switch off all LEDs MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, 0); // Start new blinker task with new whichLed value. if (pdTRUE != xTaskCreate(BlinkyTask_LEDBlink, "Blinker", 32, (void*)whichLed, 4, &blinkerTask)) { // Crash due to insufficient heap memory? Halt scheduler and hold all RGB LEDs to white. vTaskSuspendAll(); MAP_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3); while(1) ; } // Latch button press so we don't re-trigger until button has been released inputLatched = true; } if ( inputLatched && (inputShifter & 0xFF) == 0 ) { inputLatched = false; // un-latch USR_SW1 } // Wait 10ms before checking again vTaskDelay(10 / portTICK_RATE_MS); } } Result: Red LED blinks, left pushbutton toggles to blue & green and back to red.  Pressing & holding the pushbutton switches the LED but only once, as the pushbutton task "latches" it.
    The technique of debouncing a pushbutton using periodic polling + bit shifts and logic tests was something I saw on hackaday recently - http://hackaday.com/2015/12/10/embed-with-elliot-debounce-your-noisy-buttons-part-ii/
    I didn't use the same test values but it doesn't matter...
    Using polling instead of interrupt for the pushbutton is definitely one of those things that is easy & practical only if using an RTOS.
  5. Like
    tripwire reacted to spirilis in ESP32, a challenge to the CC3200?   
    Fwiw I found out recently looking at the footprint & datasheet, TI's certified modules don't actually include an antenna (for the CC3100MOD and presumably CC3200MOD).  You still have to provide the antenna and balun.  TI's wiki mentions it's still "certified" if you follow the antenna layout guidelines in the datasheet, but in any case it's not a "simple" solder & play part (though it's probably not hard to add the antenna piece to your board).
    ESP32 substantially steps up the game.  WiLink-like dual protocol support but in an MCU, with double the SRAM of the CC3200, built-in Ethernet MAC and CAN.  The working temperature range seems larger too, that's closer to what TI bills for automotive grade parts IIRC...
    Speaking of which, I wonder if this is an automotive play on Espressif's part?  CAN, Ethernet, WiFi, decent MCU, wide temperature range, touch sensor support... Hmm...
  6. Like
    tripwire reacted to bluehash in ESP32, a challenge to the CC3200?   
    CNX has an article on the new ESP32, a step up from the popular ESP8266. This new guy will have Wi-Fi and Bluetooth 4.0 on board - almost an SoC. This looks more like a competitor to TI's WiLink devices.
    No details on pricing yet. I do like TI's documentation and certified modules 

  7. Like
    tripwire reacted to monsonite in ChipStick - a Low Cost Digital Debug Tool (DDT) for Hobbyists and Education   
    An Update,
    I have now partially built up a batch of 14 ChipSticks, and completed 4. The remainder will be done during the week.
    Over the weekend I have written some more code to exercise the on board 128K byte RAM - and this appears to be working well.
    I can now execute my Simplex code out of the external SRAM.
    There will be an update to the code on my Github plus some more information geaned whilst building these up.
    It's not often you get an uninterrupted 4 day stretch to work intensively on a project  like this.  I can return to work tomorrow - knowing that most of what I aimed to achieve this weekend has been accomplished.
    The MSP430FR2433 device is still on a 12 week leadtime - so that puts us into nearly July before these are able to be manufactured in volume. Some beta samples may be available in due course.


  8. Like
    tripwire reacted to chicken in New Out Of the Box MSP430FR5969   
    On 1 and 3:
    1. Make sure the reset pin is wired as recommended in the datasheet. From memory, it requires a pull-up resistor and a small capacitor is recommended.
    3. Yes. While you might get away with leaving pins unconnected, you can't be sure whether the MCU will behave as specified. Leaving VCC or VSS pins unconnected, you might power parts of the MCU in unintended ways, maybe even through GPIO pins.
  9. Like
    tripwire reacted to pine in Stupidest Thing you had to Troubleshoot?   
    Keep getting error message in CCS saying unable to program the LP (not exactly but something very similar to that meaning). 100% sure the board is connected. Unplugged the USB and plugged in again, restarted CCS and restarted PC. Turns out I tried to program a non-existent 2553 as I moved it out from the LP to a breadboard 
  10. Like
    tripwire reacted to monsonite in ChipStick - a Low Cost Digital Debug Tool (DDT) for Hobbyists and Education   
    In this post I reveal the applications of the new product I have been working on this last month.

    ChipStick is a tiny, low cost ($10)  16 bit microcomputer based on the MSP430FR2433 attached to a PC via a USB cable. It comes with up to 256K bytes of non-volatile memory - uniquely using ferro-electric memory.
    It has up to 16 accessible GPIO lines - which include a mix of SPI, I2C, UART, Timer and ADC channels.
    ChipStick may be plugged into a breadboard or stripboard and act as an intelligent programmable controller interfacing with other circuitry.
    ChipStick can also act as a Digital Debug Tool (DDT), with jumper wires attached, - used to debug/develop low voltage (3V3) target hardware.
    This is not for "MSP430" debugging - more a general purpose tool for exercising digital hardware, ICs etc
    In each case, the extendable Scripting Language SIMPLEX may be tailored to the exact requirements of the user's application.
    ChipStick is based on non-volatile ferroelectric technology.  This means that your applications and any recorded data remain in memory even after power down.
    ChipStick may be extended in hardware to meet the requirements of the application - this is planned through both a series of larger expansion boards (based on the low cost 50x50mm format) and stackable micro-modules that match the DIL 20 socket format.
    In this respect, a high resolution 4 channel 24-bit ADC micro-module is under development which additionally provides 8 extra GPIO lines for external applications 
    This 24-bit module opens up the ability to interface to high resolution sensors such as loadcells, strain-gauges, precision temperature sensors, energy monitors and other applications where 10 bits of ADC resolution is just not enough.
    Other modules in planning are a high speed flash converter for digital oscilloscope projects and high speed capture/replay memory for logic analysers, arbitrary waveform generators and VGA video generation.
    With these primary applications in mind, ChipStick has been designed to be as versatile as possible - within the constraints of the small footprint.
    As a debug tool, it is no bigger than a USB Stick - easily carried around with essential hacking tools.
    I have designed it as a socketable component that may be added to a board (see above) - where a small amount of intelligence is required, or for bridging between sensor devices. It can also collect or send data to SPI devices and bridge that back to the PC via the UART channel.
    Equally, it could be used as a small test equipment device to exercise, monitor or control prototype hardware - it has 16 GPIO lines - including two full SPI ports. These can be attached to the target hardware, and using the SIMPLEX scripting language, the various target hardware can be exercised and data reported back to the PC.
    With the right SIMPLEX script, it can be used to transfer a hex, bin or ascii file from the PC to the target under development.
    The external memory may be used for sensing and datalogging applications, capturing waveforms, playing back arbitrary waveforms - as a signal generator.  The ADC channels may be used as a low bandwidth oscilloscope, test meter or for monitoring changing physical quantities in science experiments.
    ChipStick takes much advantage from the trend in modern sensors and peripherals to connect via the SPI or I2C bus. The MSP430FR2433 device provides up to 3 separate SPI buses.
    ChipStick can be interfaced to Wireless and WiFi modules such as the RFM69 via SPI and the low cost ESP-01 via the second UART port.
    Suitable sensors include accelerometers, gyroscopes, digital compass, temperature, pressure, loadcells etc.
    For basic GPIO operations - common shift registers may be used with the SPI bus such as the 74HC595 for 8-bits output - for driving LED arrays, the high power TPIC6B595 for driving stepper motors, and the 74HC165 for 8-bit inputs.
    Using a LED driver IC - such as the MAX7219 or AS1100 series - up to 8 digits or an 8x8 array of LEDs may be driven from the SPI port.
    OLED and LCD graphics displays may also be driven from SPI  with a couple of control signals.
    Educational Applications

    ChipStick as been designed with education and experimentation in mind.  It has been priced such that cost should not be a barrier to using it.
    The module can be made in China for as little as $4, and there may be a "kit" version available with just the awkward QFN-24 and SMT parts soldered to the tiny pcb, leaving the user add their own through-hole connectors  - if needed.  You can then use your own 3V3 programming USB-Serial lead.

    It can be used specifically to assist in the teaching of electronics, computer science and interactive coding.

    It is versatile enough to meet the needs of high-school and university undergraduates, plus simple enough meet the requirements of the maker and hacker community.

    The small size of ChipStick allows it to be used to give intelligence and connectivity in situations where other technology is just too bulky to fit - with the programmer section detached it is only 26.5 x 11mm - small enough to fit inside a 4x2 Lego block!

    It's low cost means that it can deployed in areas where other solutions might prove too expensive.

    Here are a few of the educational applications:

    Teaching Forth.

    Forth is an interactive language and can be best taught with hardware that creates a stimulating interactive environment. This includes the use of LEDs, sound, touch and movement (such as stepper motors and servos).

    The MSP430 is a good fit for a "traditional" Forth machine - with 16-bit Von Neuman architecture.

    MSP430FR2433 with 16K FRAM and 4K RAM is architecturally similar to the early minicomputers that Charles Moore would have first coded Forth onto in the late 1960s - just a bit faster.

    The external SPI memory has been included - specifically so that users can experiment and learn about interpreted languages running on virtual machines. OK - single byte access to external RAM takes approx 30uS - but block access is 3uS per byte. ChipStick will come with a 128Kx8 external SRAM 23LC1024, or FRAM to special order.
    The use of the 23LC1024 SRAM with its quad SPI port immediately opens up applications for logic analysers, dataloggers arbitrary waveform generators and other memory capture/playback devices.

    The SPI buses on the MSP430FR2433 allow expansion hardware like sensors and shift registers, LED and graphic display drivers etc to easily be added - with minimum of wiring.

    Teaching Coding
    ChipStick is not limited to Forth  - it is easily programmed in C with CCS or Energia, BASIC or in native MSP430 assembly language.  
    The SIMPLEX scripting language is written in C, easily modified and uses a Forth-like syntax. It encourages the use of short functions or blocks of code, that may be tried and tested individually by the interactive interpreter, edited if necessary and when fully working compiled and stored in the on-chip non-volatile FRAM.  Code Blocks may then strung together to make more complex applications.
    An innovative but intuitive, cross platform GUI to visualise the process of coding is currently being developed.  

    Teaching Digital Electronics

    ChipStick can animate electronic projects in a low cost way not previously possible.  With a breadboard and a few LEDs and switches, ChipStick can form the central controller of many digital projects.

    It's ability to easily interface to displays, sensors and actuators allows it to make projects exciting.

    ChipStick can also be used to exercise digital electronics, and report results back to a PC for display on a graphical user interface. In teaching environments where real hardware may not be possible or practical - ChipStick can use virtual hardware and achieve most of the same educational aims.
    Creating Practical Hardware
    ChipStick helps to break down some of the barriers between modern electronic devices and practical hardware hacking. It's method of construction effectively converts between the awkward surface mount technology, and 0.1" (2.54mm) pitch pins - that are a lot more user and breadboard friendly.
    The small format and layout of the ChipStick board means that accessories and expansions may be easily prototyped on breadboard or stripboard at minimal cost, and then easily converted to a pcb - using tools such as KiCAD or EagleCAD. Simple designs can be created in a few hours, or over a weekend - with low cost pcbs delivered from China within a couple of weeks.
    ChipStick promotes the use of 50mm x 50mm expansion boards with a common header layout. This allows boards to be used together, shared or swapped between friends or whatever.

    Making and Hacking

    As a result of it's low cost, ChipStick can be used in projects where other solutions may seem over expensive. Projects no longer need to be stripped down, to salvage the only $20 Arduino for another purpose.  ChipSticks will be supplied in multi-packs at very low prices - so that the cost of the device is no longer seen to be a barrier to creativity.

    ChipStick is compatible with Energia - an "Arduino Like" IDE. This allows an easy transition to the new device from familiar territory.
    ChipStick will enter production in the Summer. However - it is fully opensource, and the design files and firmware will be available via Github in due course.
    Happy Easter
  11. Like
    tripwire reacted to spirilis in I'm struggling with the CC3200   
    I take FreeRTOS as a "blank canvas".  It provides a scheduler, and synchronization/message-passing primitives, plus it requires (and thus provides as a standard interface) heap allocation mechanisms so you have a malloc/free type of setup.
    Thus, it can be sculpted into whatever you want it to be ..... or it can be a source of frustration if you would prefer to have all your RTOS-aware drivers written for you.  TI-RTOS does, for the most part or "in theory" might be a better term, provide the latter (at least for some stuff TI-related like MCU peripherals and network stacks like CC32xx/31xx SimpleLink WiFi in native RTOS-compatible form).  So I can see where someone would talk about FreeRTOS being "not up to par", but it's a double-edged sword.
    For someone who's thinking about this topic in the context of making a product that might become commercialized - that is to say really, of what "foundation" one should commit their time into learning with the purpose of conserving one's time and energy yet maximizing utility, one has a couple schools of thought they can choose from.  TI-RTOS is supported by TI, the vendor, and has device drivers supported by the vendor.  But the build process so far as I've seen seems a bit complicated and difficult to trace and so if you have problems with the drivers, you are kind've beholden to TI to fix them or help you figure out how you're using them wrong/etc.  I guess at some point folks become XDC maestros and experts in the subject but I can't imagine willingly committing a lot of time to getting there when there are other things to spend your time on... as I may have said earlier, XDC appears to be an esoteric attempt to replicate C++'s features in C using a domain-specific language to glue everything together.  Still though, some people like committing trust into a "partner" like TI to provide everything they need, and at some level it's an arbitrary decision.
    But if you have adequate driver support by other means -- say, the driverlib that comes with most 32-bit ARM MCUs by TI and other vendors, and you have a good idea of how complicated driver implementation & use-cases needs to get to make them RTOS-native/aware (possibly writing special driver tasks and RTOS-message-passing-oriented APIs to wrap them), and/or you are fully willing to write or port your own external peripheral drivers (which you may have to do with TI-RTOS too since it doesn't support every IC on the planet), FreeRTOS is a very transparent RTOS system that you can use as your base.  It's also commercially supportable and well known (supports multiple vendors), seeing as even TI provides FreeRTOS examples in many of its chip lines and driverlib suites (TivaWare, HALCoGen coming to mind).  It's the more DIY option, but some might take comfort in knowing they wrote the most important interfaces from scratch and should understand where things could go wrong.
    Anyway, that's my 2 cents with my current state of knowledge.  Ask me again once I've digested all those TI-RTOS training videos... (though presently I am digesting the FreeRTOS Cortex-M3 book I printed out)
  12. Like
    tripwire reacted to zeke in I'm struggling with the CC3200   
    Yeah, I did find that page. Thanks.
    Did you notice how much detail is (or isn't) on that page? It's just enough to prove to yourself that you can get it to run. 
    The reason for me shifting my focus to freeRTOS is this page:
    I looked through the list and noted how many times the OS Support column said freeRTOS versus TI-RTOS. There's not much TI-RTOS in that list but there is plenty of freeRTOS mentions.
    If the people who compose the example programs choose freeRTOS rather than TI-RTOS then there's something there.
    So, I take that as an omen about TI-RTOS:
     Abandon all hope, ye who enter here. - Dante's Inferno
  13. Like
    tripwire reacted to spirilis in I'm struggling with the CC3200   
    I don't think we're saying they are selling boards with no TI-RTOS support.What we're saying is TI-RTOS is a pain in the ass to get started with.
  14. Like
    tripwire reacted to zeke in I'm struggling with the CC3200   
    I found the answer.  It's a debugger based on the FTDI chip.
    I followed these instructions to get me onto the right path:
  15. Like
    tripwire reacted to spirilis in I'm struggling with the CC3200   
    Got the basic freertos_demo for ek-tm4c123gxl (example from TivaWare found via TI Resource Explorer) running on my TM4C123G launchpad.  That codebase still looks a bit "busy" but some of the concepts are coming back to me.  It just blinks the RGB LED and the left pushbutton changes color, while the right pushbutton changes the cadence.
    Attaching a few pictures for kicks.

    Main function in freertos_demo.c which gets the party started:

    Just going to paste the actual code for the ledtask_init and switchtask_init stuff:
    LEDTaskInit (called from main):
    //***************************************************************************** // // Initializes the LED task. // //***************************************************************************** uint32_t LEDTaskInit(void) { // // Initialize the GPIOs and Timers that drive the three LEDs. // RGBInit(1); RGBIntensitySet(0.3f); // // Turn on the Green LED // g_ui8ColorsIndx = 0; g_pui32Colors[g_ui8ColorsIndx] = 0x8000; RGBColorSet(g_pui32Colors); // // Print the current loggling LED and frequency. // UARTprintf("\nLed %d is blinking. [R, G, B]\n", g_ui8ColorsIndx); UARTprintf("Led blinking frequency is %d ms.\n", (LED_TOGGLE_DELAY * 2)); // // Create a queue for sending messages to the LED task. // g_pLEDQueue = xQueueCreate(LED_QUEUE_SIZE, LED_ITEM_SIZE); // // Create the LED task. // if(xTaskCreate(LEDTask, (const portCHAR *)"LED", LEDTASKSTACKSIZE, NULL, tskIDLE_PRIORITY + PRIORITY_LED_TASK, NULL) != pdTRUE) { return(1); } // // Success. // return(0); } SwitchTaskInit (called in main):
    //***************************************************************************** // // Initializes the switch task. // //***************************************************************************** uint32_t SwitchTaskInit(void) { // // Unlock the GPIO LOCK register for Right button to work. // HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY; HWREG(GPIO_PORTF_BASE + GPIO_O_CR) = 0xFF; // // Initialize the buttons // ButtonsInit(); // // Create the switch task. // if(xTaskCreate(SwitchTask, (const portCHAR *)"Switch", SWITCHTASKSTACKSIZE, NULL, tskIDLE_PRIORITY + PRIORITY_SWITCH_TASK, NULL) != pdTRUE) { return(1); } // // Success. // return(0); } So xTaskCreate is used to register tasks with the RTOS before the scheduler begins (via vTaskStartScheduler()).
    In theory, all of that init crap could be stuffed into main() just before vTaskStartScheduler, but doing it this way "encapsulates" the code a bit.  Note that led_task.c and switch_task.c have respective .h files, but those just register the blahblahTaskInit functions as extern so freertos_demo.c (where main() is located) can see them:
    extern uint32_t SwitchTaskInit(void); Also this example has TI's "anti-viral open source" stuff in it.  Luckily, the FreeRTOS stuff, including the critical piece - the "third_party/FreeRTOS/Source/portable/CCS/ARM_CM4F/port.c" and portasm.asm files do NOT have this "anti-viral open source" license applied to them, rightfully so since FreeRTOS requires any modifications to the RTOS to be open-source.  Which makes me wonder why TI's included their "anti-viral open source" wording in conjunction with such a "viral" open-source product... (sketchy from a legal standpoint but none of us geeks give a crap, including TI's own developers apparently).
  16. Like
    tripwire reacted to spirilis in I'm struggling with the CC3200   
    There are more "extras" you can d/l and plug into FreeRTOS of course though. Anyway I found it ironic TI-RTOS was never supported on Hercules. It's probably because there's a commercial version of FreeRTOS called SafeRTOS designed for the kinds of apps Hercules is intended for.
  17. Like
    tripwire reacted to jazz in New MSP430FR2311 Launchpad   
    I don't work with qfn. For other packages I use on board p2p without adapter.

  18. Like
    tripwire reacted to monsonite in New MSP430FR2311 Launchpad   
    I think this new '2133 chip is targeted at smoke alarm applications.
    The TIA is just what is needed to convert the nano-amps from the ionisation chamber into a detectable change of voltage.
    At $0.60 in 1000off it's clearly aimed at high volume disposable products.
    I think you could just about run a Forth in 3.75K of FRAM
    Today I have just started looking at the MSP430i2041  which has 4 x 24 SD ADCs  - aimed at 3 phase electricity metering applications.   It's only $1.20 in 1000+  and makes the ideal smart analogue front end for loadcells, strain gauges, pressure sensors, altimeters  or  accelerometers.
    My only gripe is that I have to buy another schmartboard adaptor every time I want to use a TI chip in a breadboard.  And very few of them share the same pin-outs. Its like you have to start all over again, each time you want to evaluate a new device. 

  19. Like
    tripwire reacted to SteveR in New MSP430FR2311 Launchpad   
    Ti dropped a new launchpad today, it isn't even listed on the ti.com/launchpad page. 
    From the email:
    "the world
  20. Like
    tripwire reacted to nickn in Code breaks when optimization is used (msp430-gcc)   
    Thanks for the answer and suggestion. I shall go see if that works.
    UPDATE: Your suggestion worked
  21. Like
    tripwire reacted to chicken in Code breaks when optimization is used (msp430-gcc)   
    PS: your approach might work if you declare flag as volatile.
    volatile int flag=0;
  22. Like
    tripwire reacted to chicken in Code breaks when optimization is used (msp430-gcc)   
    Your delay loop will be optimized away.
    Not sure if it's supported by the gcc tool chain, but in CCS I use __delay_cycles() for this purpose.
  23. Like
    tripwire reacted to dubnet in MSP432 without MT   
    First of all, welcome to the forum.
    Sorry to hear you are having difficulty. I am not aware of any way to use the MSP432 under Energia without using the TI-RTOS underpinnings. However, I have used it with the MSP432 with both single task and multitask programs and it seems to work consistently (for me anyways). Perhaps, if there is a way to disable multitasking @@energia would be the person to answer. The other option is to install and use TI's CCS IDE. With that you have the option of using, or not using, TI-RTOS. CCS6 has the ability to import Energia files and you get the added bonus of having a debugger as well as EnergyTrace.
    In the meantime, please detail the problem you are having by posting your code, include any error messages that you see, and describe your operating environment (OS and version). Also include areas where you have had some success as that helps narrow things down as well. Having this information makes it much more likely that someone can spot the problem and assist.
    EDIT: One other thing that may be happening is that not all the examples are supported for all variations of Launchpads. Either there are hardware differences involved or the example was written long before the newer hardware came along. Unfortunately, this is not always clear by looking at the example programs.
  24. Like
    tripwire reacted to tonyp12 in tiny msp430 preemptive multitasking system   
    preemptive means that the code (e.g.each task that is pretty much its own main.c) does not know it is sharing a single mcu core.
    it does not need to say "i take a pause now so next task can go on", you can even run two instances of the same task (though not really useful)
    A higher power takes over and switch tasks.
    Sure there is stuff to add like system_sleep and priority and maybe even new task and end task etc.
    I plan to show how to use a 512Hz mems osc to NMI pin, so task switching can not be overridden by (maybe mistakenly) disabling GIE.

    ?wiki: Preemptive multitasking
    wiki: Cooperative multitasking
    P.S I also have a Cooperative multitasking system that uses a Event Machine in main.c and each (up to 16) tasks are all State Machines (switch/case) as that is a good time slicer.
    ?What I like about that is that I know I have exclusivity while I'm doing my thing so no race conditions.
    ?And very little overhead so better for battery-operation as task that needs to use a time-constant can sleep from 1ms to 64sec independently keeping in LPM3 95% of the time
  25. Like
    tripwire reacted to NickTompkins in FFT   
    Here is some C code I have used to make the sine table for the fix_fft function if I wanted to change the size of the FFT
    #include <stdio.h> #include <math.h> #define POINTS 128 #define BITS   16 int main(void) {   int n;   int a=0;   int TF_FLAG=POINTS-POINTS/4; printf("#define N_WAVE      %d    /* full length of Sinewave[] */\n",POINTS); printf("#define LOG2_N_WAVE %d      /* log2(N_WAVE) */\n",(long)log2(POINTS)); printf("/* 3/4 of N_WAVE = %d  */\n",TF_FLAG); printf("const int8_t Sinewave[N_WAVE-N_WAVE/4] = {\n");   for (n=0; n<POINTS; n++){         if(n==TF_FLAG){           printf("/*");         }   if(a<15){     printf("%d,", (int)floor(0.5 + ((1 << (BITS-1)) - 0.50001) * sin(2 * 3.1415926535897932 / POINTS * n)));         a++;}        else{         a=0;         printf("%d,\n", (int)floor(0.5 + ((1 << (BITS-1)) - 0.50001) * sin(2 * 3.1415926535897932 / POINTS * n)));         } } printf("*/"); printf("};\n");   return 0; } You can copy and paste the output into your fix_fft.c file ;-)
  • Create New...