spirilis

Does the thermocouple lines have a 10nF (0.01uF) capacitor across them close to the AD8495? (or any other kind of filtering)
 
Does the AD8495 have proper bypass capacitors across its Vcc/GND?
Might be induced by momentary power drops in Vcc too... how is the board being powered?

I wrote this up the other week but forgot to post it.  Just a little power-user help for folks interested in really exploring the "potential" behind FRAM memory in Energia.
 
Tips & Advanced Tricks for using Wolverine with Energia 12   I've brainstormed a few things folks might want to play with if they're interested in getting the most out of their Wolverine LaunchPad and its built-in FRAM memory.  The FRAM memory, being modifiable yet persistent, is quite different from Flash and our C compilers aren't necessarily laid out to make it super-simple to use.  That said, it's not really that hard to use.   There are a few "tricks" you can employ with Energia 12 to get more out of your Wolverine-   1. Declare global variables as being part of the ".text" linker section, so they live in FRAM and are not copied to/fro RAM on bootup. (this is the "quick hack" way to do it, the long & canonical way to do this is to define a new section in the Linker Script assigned to the ROM segment and declare your arrays or variables as being a part of that section instead).   2. Write/read to the "High" memory segment -- the Wolverine happens to have a 16KB segment of its FRAM living from 0x10000 to 0x13FFF (that's above address 65536 decimal, outside the realm of what a 16-bit pointer can reference) which is unknown to the MSPGCC compiler that ships with Energia 12, since it doesn't support large-memory model.   3. Move your RAM to FRAM, giving you more RAM (stack & heap) if it's what you want.  This isn't always necessary since you can declare large arrays as a global in the ".text" section per #1 above.   Without further adieu, let me show you:   1. In your sketch, up top you can do something like this:   #define PERSIST __attribute__((section(".text")))   and then declare global variables with this new "PERSIST" keyword like such:   uint8_t DisplayBuffer[LCD_MAXIMUM_Y][LCD_MAXIMUM_X] PERSIST;   Your "DisplayBuffer" array will live in FRAM and won't hog up any of your RAM.  It will co-exist with program code, so be VERY VERY SURE not to make any "buffer overflow" mistakes and write before or past the end of its memory boundaries or you will corrupt your sketch's binary application code.  Take this doubly serious when the application in question involves Internet connectivity of any kind; I can imagine the spectacular headline on the blogs "IoT application sports buffer-overflow exploit where attacker can write any binary MSP430 code they want!"   Alternately, you can use the InfoMem segments:   uint8_t DisplayBuffer[512] __attribute__((section(".infomem")));   which has 512 bytes (maximum) available for your use; it lives outside the main code FRAM area and if you try writing beyond it, you attempt to write to the calibration data (TLV) FRAM segment which should throw an internal violation (not sure what happens, whether the chip halts or resets or does nothing, but the calibration info will remain safe).  Unlike other MSP430 chips, Info segment "A" can be written on these as the calibration data is stored in another "special" FRAM segment at 0x1A00.     2. I wrote some functions employing assembly language; which the current stable release of MSPGCC does understand (the extended-memory 20-bit instructions) that gives you a way to copy data to or from the higher memory segments. See here: HighMem.zip   The functions are called highmem_write() and highmem_read().  You can import the HighMem library into your sketch, and it should add: #include "highmem.h" to your sketch.   The functions are:   void highmem_write(uint32_t dstaddr, void *srcaddr, uint16_t len) You give it the FRAM destination address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM, followed by the # of bytes you want to write.   The reciprocal of this is highmem_read(): void highmem_read(uint32_t srcaddr, void *dstaddr, uint16_t len)   Give it the FRAM source address as a 32-bit integer (0x10000 or above), followed by a pointer to a buffer in your SRAM or lower FRAM where you want the data to be copied into, followed by the # of bytes.  The # of bytes can be an odd or even number, as it uses byte-at-once transfers rather than word-at-once.  It uses DMA channel#2 to do the transfers.   For those using the FRAM to store a display buffer of some sort, this may be useful as a "bonus" loft or swap area for storing multiple versions of your display framebuffer.  The memory up there is not allocated by the linker, so you need to manage it yourself (keep track of which addresses you've used and how much data is stored there).  It's also not possible to reference the data directly by variables, because the MSPGCC compiler used in Energia 12 doesn't support the large-memory model (doesn't produce the 20-bit pointers and appropriate instructions for accessing it directly).  There is a later revision of MSPGCC (developmental) that does support this, but Energia isn't using it.  At some point in the future Energia will use the RedHat msp430-elf-gcc which does support large-memory model, but that'll be a while out I think.   Example sketch using these (writes a stock string to the highmem, then changes 2 bytes before reading it back into an SRAM buffer to be printed over the serial port)- #include <highmem.h> #include <string.h> const char *teststr = "What is this???"; void setup() { // put your setup code here, to run once: pinMode(P4_5, INPUT_PULLUP); delay(10); while (digitalRead(P4_5)) ; // Wait for S1 to be pressed so the user has time to open serial monitor Serial.begin(115200); Serial.println("HighMem test:"); highmem_write(0x10000, teststr, strlen(teststr)+1); // Write stock string to highmem } void loop() { char buf[128]; // put your main code here, to run repeatedly: buf[0] = 'a'; buf[1] = 't'; highmem_write(0x10000+10, buf, 2); // Write 2-byte modification to highmem highmem_read(0x10000, buf, strlen(teststr)+1); // Pull entire string from highmem to 'buf' Serial.print("HighMem string says: "); Serial.println(buf); while(1) delay(1000); } It prints "What is that???" instead of "What is this???", thanks to the modification performed in loop().     3. Edit MSPGCC's linker script for the msp430fr5969 to move "ram" into the FRAM address space.  Note you'll have to move the "rom" linker segment up appropriately to give room for the RAM.   From your Energia install, e.g. C:\energia-0101E0012, the MSPGCC compiler is stored under "hardware\tools\msp430".  The linker scripts live in: C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts with a separate directory for each chip.   Go into C:\energia-0101E0012\hardware\tools\msp430\msp430\lib\ldscripts\msp430fr5969 and locate a file called "memory.x". Open this in a text editor, you should see the default contents which look like this:   MEMORY { sfr : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */ peripheral_8bit : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */ peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */ bsl : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */ infomem : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */ infod : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */ infoc : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */ infob : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */ infoa : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */ ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */ rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ vectors : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */ far_rom : ORIGIN = 0x00010000, LENGTH = 0x00004000 /* END=0x00014000, size 16K */ /* Remaining banks are absent */ ram2 (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 ram_mirror (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 usbram (wx) : ORIGIN = 0x0000, LENGTH = 0x0000 } REGION_ALIAS("REGION_TEXT", rom); REGION_ALIAS("REGION_DATA", ram); REGION_ALIAS("REGION_FAR_ROM", far_rom); PROVIDE (__info_segment_size = 0x80); PROVIDE (__infod = 0x1800); PROVIDE (__infoc = 0x1880); PROVIDE (__infob = 0x1900); PROVIDE (__infoa = 0x1980); What we're interested in here is the "ram (wx)" and "rom (rx)" definitions in the MEMORY { } declaration. The default setup puts RAM where it should be; at the Wolverine's 2KB SRAM segment starting at 0x1C00.  The "rom" is actually FRAM, but called "rom" since the main linker scripts are common to all the msp430 targets supported and expect to see the main program memory called "rom".   So for fun, let's move our 2KB RAM segment into FRAM.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 2048 /* END=0x4C00, size 2K */ rom (rx) : ORIGIN = 0x4C00, LENGTH = 45952 /* END=0xff80, size 48000-2048 = 45952 */ Note I used decimal for the LENGTH part so it's easier to think through.  We're putting our "ram" segment at the start of FRAM, and moving the start of the "rom" segment 2KB higher to compensate, but also telling the linker that its segment is now 2048 bytes (2K) smaller.  This last piece is very important; you'll see errors in compiling if you get it wrong.   Now one of TI's big marketing push is you can partition your FRAM to give more space to RAM vs. code.  Let's say you have a sketch that runs beautifully on the MSP430F5529 LaunchPad with its 8KB available SRAM, but bombs on the Wolverine.  You want to give the Wolverine 8KB RAM too so it'll work right.   It'll look like this:   ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */ We put "ram" at the start of FRAM, gave it 8192 bytes (8KB), moved the "rom" segment up by 8KB and shrunk its total length by 8KB.   Note that unfortunately you can't just combine your existing SRAM and FRAM together since they are not contiguous in address space.  SRAM starts at 0x1C00 and ends at 0x2400, where FRAM starts at 0x4400; there is a 0x2000 (8KB) gap between those two.   It's always a good idea to keep the original ram & rom specifiers in that memory.x file but commented out so you can quickly go back to the original configuration.  Here's what it looks like: /* ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 */ /* END=0x2400, size 2K */ /* rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 */ /* END=0xff80, size 48000 */ ram (wx) : ORIGIN = 0x4400, LENGTH = 8192 /* END=0x6400, size 8K */ rom (rx) : ORIGIN = 0x6400, LENGTH = 39808 /* END=0xff80, size 48000-8192 = 39808 */   You can then comment out the 2nd ram/rom definitions and uncomment the first one (notice the "*/" after "LENGTH = " in the first 2 lines) to revert back to the default memory setup.   That said, unless you are just trying to run a sketch that works beautifully on the MSP430F5529 or Tiva-C due to its expansive RAM and won't on the Wolverine, there's probably no reason to hack your linker script when you can just declare big buffers as part of the ".text" section per #1 explained above.

Hi,
 
I had a similar problem with CC1120. It didn't want to go on Power Down mode when I strobe with "PWD" commannd.
 
Try to strobe with "IDLE" command before "POWERDOWN" strobe command. 

what @@abecedarian said... The power consumption of the LCD entirely depends on how fancy an LCD you use.
 
The other consideration is that, since you only need the LCD for occasional "configuration" purposes, the board housing that LCD can provide power for itself and/or power (or recharge) the WSN board.  Using level shifters in the bus interface the former option, i.e. the LCD board power itself, is easily doable.

G2452 is a pretty small chip.  Much smaller than the typical Atmel ATmega328 used in Arduino.
 
Try G2553 at the minimum... (which is still smaller than an ATmega328, but not as bad)
 
For even larger, hit up an F5529 launchpad or FR5969.

On @@abecedarian 's note about LCDs, one interesting option would be to have the LCD interface a pluggable module that you attach only when you need it... and have the board designed to accept such "hot plugged" hardware.  I'm not 100% certain how the hot plug interface should work but I do know there are special "bus transceiver" ICs that can make this seamless/less prone to screw with the board's operation.

The "byte maximum" in Energia is BS and driven by the values inside boards.txt IIRC.  I haven't looked at Energia's FR6989 support internals yet though.

I'll take your word for it
 
I like the FR5969 better overall anyway.  F5529 has plenty of cool stuff to talk about but FRAM is neat.  I have a lightning sensor project that uses the FRAM as its data storage device (and that whole concept should work well for WSN nodes when reliable communication links aren't guaranteed but the data should be reported).
 
The thing I hate about the FR6989 is that since its 128KB FRAM lives mostly in the upper address space (requiring 20-bit addressing mode), the old msp430-gcc that ships with Energia doesn't support it, whereas the new msp430-elf-gcc that ships with CCS has had lots of issues to work out (though I haven't tried the very latest version, maybe it's stable now).  Great that it's there, just sucks that the software support requires finagling with linker scripts 'n stuff.  Give me a FRAM MSP432 already.

I'll take your word for it
 
I like the FR5969 better overall anyway.  F5529 has plenty of cool stuff to talk about but FRAM is neat.  I have a lightning sensor project that uses the FRAM as its data storage device (and that whole concept should work well for WSN nodes when reliable communication links aren't guaranteed but the data should be reported).
 
The thing I hate about the FR6989 is that since its 128KB FRAM lives mostly in the upper address space (requiring 20-bit addressing mode), the old msp430-gcc that ships with Energia doesn't support it, whereas the new msp430-elf-gcc that ships with CCS has had lots of issues to work out (though I haven't tried the very latest version, maybe it's stable now).  Great that it's there, just sucks that the software support requires finagling with linker scripts 'n stuff.  Give me a FRAM MSP432 already.

I have been working on a project lately where I need to fit a design into an enclosure and was fumbling through my drawer looking for a measuring scale when I came across an old flow charting template.  I acquired it almost 40 years ago when I was working on a hydrocarbon process simulator that we were programing in FORTRAN.  That project was the last time I wrote code until fairly recently, but anyway, here is the template:

Pretty funny...  On the left side is a "card scale" that you could put next to a stack of IBM punched cards to estimate how many you had.  Over at top right are the main ways of getting something into the computer - punched card, magnetic tape, and punched tape.  I actually remember using punched paper tape on a computer once.  Down below is online storage, offline storage, and "drum".  Followed by document, display, terminal, and manual operation.
 
I don't actually remember using it as we weren't required to document with flow charts.  But we did have extensive user documentation in the form of paper manuals and the code itself was heavily documented.
 
 
 

I did order two, hesitated at the unknown shipping charges but proceeded thinking domestic ground shipping on less than a pound shouldn't be much. Bad assumption. The shipping weight was actually 2 pounds due to the marketing material included (at my expense) in each board's box. Long story short...the $5 boards ended up costing just under $14 each. I won't be using RichardsonRFPD again.
 
You were wise to abort.

Hackaday today featured a sensor node which runs on harvested RF energy.
http://hackaday.com/2016/05/01/wisp-needs-no-battery-or-cable/
 
As the article mentions a 16bit CPU, I wondered if someone put an MSP430 to good low-power use. And yes, digging into the WISP5 project finds that it uses an MSP430FR5969.
 
Project wiki with links to source code and schematics here:
http://wisp5.wikispaces.com/WISP+Home

Adafruit ILI9341 is an Arduino library for ILI9341 TFT display. This is a cheap controller and display module that can be bought on ebay/aliexpress fror as low as 6$.
 
Recently I experimented with porting this library to Energia. Not surprisingly, it was almost trivial since most of the low level stuff is abstracted by SPI library functions.
 
The port itself: https://github.com/alkhimey/Adafruit_ILI9341/tree/msp430-support
Wiring instructions: http://www.nihamkin.com/2016/04/30/connecting-msp430-with-ili9341-tft-display/
 
This might be a little redundant as I see now that there is a dedicated msp430 graphics library that supports this display, still I want to believe it has some value for the community.
 

 
 

My setup is still very simple. A small vacuum pump from ebay, a pack of glue dispensing syringe tips, and some PVC tubing.
 
It's not perfect by any means, but the whole thing only cost $20 or so. I'm planning to improve on it when I find some time.

The solution to detecting pin count can be found on Stack Exchange at the following location:
 
http://electronics.stackexchange.com/questions/228082/how-do-you-programmatically-detect-pin-count-on-an-msp430g2553

Good question. For hobby projects it's probably a non-issue. But if you want to be aggressive with power savings it is an issue. Typically i'd always attach a DMA channel to any I2C RX, and any UART RX/TX, as well as SPI RX/TX (for sensor reading up to 4MHz). For my hobby use (Autonomous Rovers), that would be 5 to 7. So, still within 8 channels, but not a lot of spares for software triggered DMA. Perhaps it's just that 16 feels like a more appropriate number (32 definitively too much).
 
Couple of use cases to illustrate:
 
(1) UART, GPS input. I'd use a ping-pong buffer scheme on RX with a receive timeout. Each of the buffers 16 bytes. This way I get an interrupt only every 16 bytes, or when a sequence of reports is done. At 115200 baud this brings the interrupt rate from about 10000 down to less than 800.
 
(2) I2C sensor reading. DMA on RX (with TI also on TX). That means I take 2 interrupts for a typical "send an index, and then read n bytes of data from a sensor". If this is 16 bytes of sensor data, then without DMA you take 19 interrupts.
 
(3) TFT on SPI. Here a double buffer scheme is nice. In one buffer you generate data for the new scanline you are working on, while using DMA on the other buffer to send over data/commands for the previous scanline that had been already generate. One can nicely overlap CPU and SPI. Of course that is not beneficial for all operations.
 
(4) SD on SPI. If you send more than one 512 byte block and want to use CRC16, then you can let the CPU compute this CRC16 on the next block you are about to send, while DMA takes care of sending the current block without CPU interaction ...
 
 
So a lot of uses, at least for me, mainly centered around communication.

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. 
   
 

hmm, maybe I was wrong then.  I do know the F5529LP is 3.3V perhaps the others are... don't have any with me to check atm.

VCC is 3.6V measured on my sample as well. The schematic on Page 39 of the LaunchPad Development Kit User's Guide (SLAU535B) shows power coming from a TLV70036DSEwhich is a 3.6V LDO.  So the pin maps or any other documentation showing 3.3V are incorrect.

that is weird, I am pretty sure I noticed 3.3V on mine last time I checked.  Your voltmeter accurate?

Hi there
Here is my 3phase variable speed motor drive booster pack

This has been in my mind for some years, but I always thought that a 3phase variable speed inverter drive is
beyond my humble hobbyist scope. Too complicated for my old 8-bit mind ;-)

Such a inverter contains:
6 high voltage FETs or IGBTs, 6 gatedrives, at least one DSP, a protection concept,
all the software to create the 3-phase PWM, dead time control.....

Still that was for quite some time on my long-term "to do" list, with no chance to actually materialize it,
not enough time, too many other things to do.

When playing around with the PWM module of the TM4C123 I found out that creating a 3phase PWM
signal with this module is actually pretty easy.
Combined that with an integrated Power Module such as the FSB50550 (Fairchild).



So here it is: a booster pack for the Tiva Launchpad which drives big-ass 3phase motors.

The booster pack contains the following:
- the FSB50550 power module (6 FETs 500V 1.4Ohm, Gatedrivers, Bootstrap diodes, Temp sensor)
- snubber capacitor
Power supply: everything is powered from one DC source, 20V or (much) more.
- 15V switchmode power supply from the high voltage side, built around a LNK304, for the FSB50550
- 3.3V switchmode power supply from the 15V to power the Launchpad, built around a LT1376
Measurement:
- Passive voltage dividier to measure the input voltage
- Sense resistor and LM339 comparator for overcurrent detection
Display:
- Nokia 5110 display
Potentiometer for motor speed and direction


The software is based on Energia using Tiva Ware function calls for all the PWM stuff.
It is still work in progress, very basic and at the moment consists of:

- calculate the sinwave lookup table at startup
- PWM initialisation (PWM set to 15625 Hz, deadtime 1us, sync on)
- a timer interrupt run every 10uSecs, do update the 3 PWD duty cycles
- ADC measurement of temperature, voltage, current (moving average)
- fault interrupt

The main program is very short, the display is updated twice a second and the modulation factor is calculated
out of the potentiometer speed setting and the applied DC voltage.
Sudden changes in motor frequency are limited in the software, to prevent the motor to feed back energy and cause
overvoltage.

The motor on the picture is a 1/2hp, 900rpm, 6-pole motor, 12 kg of Italian steel and copper, probably 50 years old.
For playing around, I apply about 50% of rated volt/hz, so current and maximum torque is reduced.
Currently I use my dual 35V 4A lab supply, series connected, as a power source.
 
here is the code:
//simple 3phase frequency converter //27.9.2014 by maelli #define dots 192 //dots per halfhave, must be divisible with 3 #define period 5120 //80Mhz/5120 = 15625 switching frequency #define dt 80 //deadtime 80Mhz / 80 = 1uS #define PART_TM4C123GH6PM #include <stdint.h> #include <stdbool.h> #include "inc/hw_ints.h" #include "inc/hw_sysctl.h" #include "inc/hw_types.h" #include "driverlib/interrupt.h" #include "driverlib/sysctl.h" #include "driverlib/timer.h" #include "driverlib/pwm.h" #include "LCD_5110.h" #include "inc/tm4c123gh6pm.h" LCD_5110 myScreen (33,37,36,35,34,38,17); char celsius[3]={0x7f,'C',0x00}; uint16_t a,dire=0,modu,tensec; uint32_t timecount,sintable[dots]; volatile int32_t irqcount,timeset; volatile uint32_t temperature, voltage, current, poti; void setup(){ myScreen.begin(); myScreen.setBacklight(0); myScreen.text(0, 0, "3ph Converter"); for(int i=0;i<dots;i++) sintable[i]=sinf((i*3.14159)/dots)*(period/2-dt); unsigned long ulPeriod; unsigned int Hz = 10000; // interupt frequency in Hz ulPeriod = (SysCtlClockGet() / Hz); initTimer(); charge_gdu(); ROM_TimerLoadSet(TIMER0_BASE, TIMER_A,ulPeriod -1); initPWM(); } void loop(){ if (irqcount>499) { //20x per sec irqcount-=500; int32_t fsoll=732*(poti-16384); int32_t diff=fsoll-timeset; if (diff>0){ if (diff>150000) timeset+=150000; else timeset=fsoll; } else { if (diff<-150000) timeset-=150000; else timeset=fsoll; } modu=abs(timeset)/voltage/16; if (modu<(32000/voltage)) modu=32000/voltage; if (modu>256) modu=256; tensec++; if (tensec==10) { //2x per sec we display something tensec=0; myScreen.text(0, 1, mkstrg((temperature-325)/24,2)); myScreen.text(2, 1, celsius); myScreen.text(5, 1, mkstrg((voltage)/23,3)); myScreen.text(8, 1, "Volt"); myScreen.text(0, 2, mkstrg(abs(timeset)/322122,2)); myScreen.text(2, 2, "."); myScreen.text(3, 2, mkstrg(abs((timeset/32212)%10),1)); myScreen.text(4, 2, "Hz"); myScreen.text(7, 2, mkstrg(current,4)); myScreen.text(11, 2, "mA"); if (timeset<0) myScreen.text(0, 3, "links "); else myScreen.text(0, 3, "rechts"); } } } String mkstrg(int d,uint8_t l){ char display[l+1]; int q=1; display[l]=0; for (uint8_t a=l;a;a--){ display[a-1]=0x30+(d%(q*10))/q; q*=10; } return display; } void initTimer(){ ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0); ROM_TimerConfigure(TIMER0_BASE, TIMER_CFG_PERIODIC); // 32 bits Timer TimerIntRegister(TIMER0_BASE, TIMER_A, Timer0Isr); // Registering isr ROM_TimerEnable(TIMER0_BASE, TIMER_A); ROM_IntEnable(INT_TIMER0A); ROM_TimerIntEnable(TIMER0_BASE, TIMER_TIMA_TIMEOUT); } void charge_gdu(){ ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_0 ); ROM_GPIOPadConfigSet(GPIO_PORTF_BASE,GPIO_PIN_0,GPIO_STRENGTH_4MA,GPIO_PIN_TYPE_STD); GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_7); //alle 3 oberen ausschalten HWREG(GPIO_PORTA_BASE + (GPIO_PIN_7 << 2)) = 0; GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_1); HWREG(GPIO_PORTD_BASE + (GPIO_PIN_1 << 2)) = 0; GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_3); HWREG(GPIO_PORTF_BASE + (GPIO_PIN_3 << 2)) = 0; GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_0); //auch die 2 letzten aus HWREG(GPIO_PORTD_BASE + (GPIO_PIN_0 << 2)) = 0; GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2); HWREG(GPIO_PORTF_BASE + (GPIO_PIN_2 << 2)) = 0; GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_6); //den ersten unteren ein HWREG(GPIO_PORTA_BASE + (GPIO_PIN_6 << 2)) = GPIO_PIN_6; delay(1); HWREG(GPIO_PORTD_BASE + (GPIO_PIN_0 << 2)) = GPIO_PIN_0; delay(1); HWREG(GPIO_PORTF_BASE + (GPIO_PIN_2 << 2)) = GPIO_PIN_2; delay(1); } void initPWM(){ ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1); //The Tiva Launchpad has two PWM modules (0 and 1). We are using 1 ROM_GPIOPinConfigure(GPIO_PD0_M1PWM0); ROM_GPIOPinConfigure(GPIO_PD1_M1PWM1); ROM_GPIOPinConfigure(GPIO_PA6_M1PWM2); ROM_GPIOPinConfigure(GPIO_PA7_M1PWM3); ROM_GPIOPinConfigure(GPIO_PF2_M1PWM6); ROM_GPIOPinConfigure(GPIO_PF3_M1PWM7); ROM_GPIOPinConfigure(GPIO_PF4_M1FAULT0); ROM_GPIOPinTypePWM(GPIO_PORTD_BASE, GPIO_PIN_0 | GPIO_PIN_1 ); ROM_GPIOPinTypePWM(GPIO_PORTA_BASE, GPIO_PIN_6 | GPIO_PIN_7 ); ROM_GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_2 | GPIO_PIN_3 | GPIO_PIN_4); PWM1_0_FLTSEN_R =3; //PWM fault inverted see page 1169 GPIO_PORTF_PUR_R=0x10; //weak pullup for Pin 4 ROM_PWMGenConfigure(PWM1_BASE, PWM_GEN_0, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_SYNC | PWM_GEN_MODE_FAULT_LEGACY); ROM_PWMGenConfigure(PWM1_BASE, PWM_GEN_1, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_SYNC | PWM_GEN_MODE_FAULT_LEGACY); ROM_PWMGenConfigure(PWM1_BASE, PWM_GEN_3, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_SYNC | PWM_GEN_MODE_FAULT_LEGACY); ROM_PWMGenPeriodSet(PWM1_BASE, PWM_GEN_0, period); ROM_PWMGenPeriodSet(PWM1_BASE, PWM_GEN_1, period); ROM_PWMGenPeriodSet(PWM1_BASE, PWM_GEN_3, period); ROM_PWMDeadBandEnable(PWM1_BASE, PWM_GEN_0, dt,dt); ROM_PWMDeadBandEnable(PWM1_BASE, PWM_GEN_1, dt,dt); ROM_PWMDeadBandEnable(PWM1_BASE, PWM_GEN_3, dt,dt); ROM_PWMSyncTimeBase(PWM1_BASE,PWM_GEN_0_BIT |PWM_GEN_1_BIT|PWM_GEN_3_BIT); ROM_PWMGenEnable(PWM1_BASE, PWM_GEN_0); ROM_PWMGenEnable(PWM1_BASE, PWM_GEN_1); ROM_PWMGenEnable(PWM1_BASE, PWM_GEN_3); delay(1); PWMFaultIntRegister(PWM1_BASE, oh_shit); ROM_PWMIntEnable(PWM1_BASE,PWM_INT_FAULT0); ROM_PWMOutputState(PWM1_BASE, PWM_OUT_0_BIT | PWM_OUT_1_BIT | PWM1_BASE | PWM_OUT_2_BIT | PWM_OUT_3_BIT |PWM_OUT_6_BIT | PWM_OUT_7_BIT, true); } void Timer0Isr(void) { //10000x per second ROM_TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT); // Clear the timer interrupt irqcount++; timecount+=timeset; // 1 Hz is 192x256*256*256/10000=322122.5 if (timecount> 0xEFFFFFFF) timecount+=0xC0000000; if (timecount> 0xBFFFFFFF) timecount-=0xC0000000;; a=timecount>>16; a=a/(16384/(dots/3*2)); //a immer kleiner 2*dots: C000 *dots/3*2/ 4000= 12 *dots/3*2/4= 2*dots if (a<dots)ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_0,period/2+sintable[a]*modu/256); else ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_0,period/2-sintable[a-dots]*modu/256); a=a+dots*2/3; if (a>=2*dots) a-=2*dots; if (a<dots)ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_2,period/2+sintable[a]*modu/256); else ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_2,period/2-sintable[a-dots]*modu/256); a=a+dots*2/3; if (a>=2*dots) a-=2*dots; if (a<dots)ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_6,period/2+sintable[a]*modu/256); else ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_6,period/2-sintable[a-dots]*modu/256); ROM_PWMSyncUpdate(PWM1_BASE,PWM_GEN_0_BIT |PWM_GEN_1_BIT|PWM_GEN_3_BIT); switch(irqcount%10){ case 0: temperature=(temperature*127+analogRead(26))/128; break; case 1: voltage=(voltage*31+analogRead(27)*3)/32; break; case 2: current=(current*127+analogRead(25)*8)/128; break; case 3: poti=(poti*127+analogRead(28)*8)/128; break; } } void oh_shit(void) { //in case of severe overcurrent we shut down! ROM_PWMFaultIntClearExt(PWM1_BASE,PWM_INT_FAULT0); ROM_PWMOutputState(PWM1_BASE, PWM_OUT_0_BIT | PWM_OUT_1_BIT | PWM1_BASE | PWM_OUT_2_BIT | PWM_OUT_3_BIT |PWM_OUT_6_BIT | PWM_OUT_7_BIT, false); }  

I've just started looking at a web server project myself. I can't help with this exact problem (yet).
 
However, are you sure this is the right approach? Web stuff works best if you don't try to retain knowledge of clients. A cookie handed to the content on first request and detected afterwards might be a better way. Something added to the URL (e.g. query) is another way if you're not worried about one client easily impersonating another.

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.

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

It does sound like TI could use a European distributor to lower the cost of shipping.