Duggle

My advice, (if you're really serious), is to somehow find a way, even over time, to obtain the $40 extra and go with the 32bit core. The difference between the old (8 bit PIC)and new (cortex m3) is like night and day. No comparison. *Much* more fun to develop on (and play with) and, as is said, "in a different league"....

Presumably, mutexs are required when ever two or more tasks are accessing the same data structures (with the possibility of incomplete changes being seen by the other task(s)). I think I've been using the SD Card mutex to prevent mutliple processes from simultaneous access to file structures. I have a settings save/restore mechanism that is called from different tasks as well as a data logging facility. I suppose that I should have separate mutexs to remove the potential for bottlenecks. (Although I dont see performance being an issue).

It seems that FILE_SDCardAvailable() returns the value of a flag, so calling this function from different tasks should not require the use of a semaphore.

The module documentation at uCApps clearly states that a mutex must be used to ensure mutual exclusion between tasks that may be attempting to access the sd card. But can calls to FILE_SDCardAvailable() be made without taking/giving the mutex?

An even simpler to implement method is to use command line parameters: mios_studio.exe -mi "MIOS32" -mo "MIOS32" in this example -mi denotes midi in port, -mo midi out port etc,etc. These would be the minimum settings, I've suggested window size and position, divider position, etc, would be handy. The user provides only those arguments they want, the rest of the properties are set to the current defaults. In this way the user makes a shortcut icon containing the command line for instances they want. MIOS studio works very well in multiple instances, this would make working with them a little smoother.

Industrial strength sounds like a good idea in any case! I suppose if FILE_WriteClose() results in a change to the FAT table then the caching which I've written and somewhat tested would result in a x100 reduction in "wear" in the scenario I described. So whilst the application can afford 10k of RAM I guess I'll keep it in. Here's the code: #define db MIOS32_MIDI_SendDebugMessage /* * DataLog.c * * Created on: 21/06/2012 * Author: Dug */ #include <mios32.h> #include <FreeRTOS.h> #include <task.h> #include <semphr.h> #include "file.h" #include <string.h> #include "debug.h" #define CACHE_SIZE 10000 u32 DataLog_Index; u8 DataLog_Cache[CACHE_SIZE]; xSemaphoreHandle DataLog_Mutex; u8 DataLog_Held; void CacheCommit(); void DataLog_Init(){ if(DataLog_Mutex==NULL) DataLog_Mutex=xSemaphoreCreateMutex(); xSemaphoreTake(DataLog_Mutex,portMAX_DELAY); DataLog_Index=0; //start of cache xSemaphoreGive(DataLog_Mutex); } void DataLog_AddLine(char* s){ //cache null terminated string char eol[3]="\r\n"; //Windows compatable EOL xSemaphoreTake(DataLog_Mutex,portMAX_DELAY); db("AddLine:%s",s); if ((strlen(s)+3+DataLog_Index)>CACHE_SIZE){ CacheCommit(); //cache now empty db("cache comitted."); } strcpy((char*)&DataLog_Cache[DataLog_Index],s); strcat((char*)&DataLog_Cache[DataLog_Index],eol); db("line cached:%s",&DataLog_Cache[DataLog_Index]); DataLog_Index+=strlen(s)+2; //include eol but not null xSemaphoreGive(DataLog_Mutex); } void CacheCommit(){ //only called from these functions s32 r=FILE_FileExists("DataLog.txt"); switch(r){ case 0: FILE_WriteOpen("DataLog.txt",1); //create new db("DataLog Create"); break;//create case 1: FILE_WriteOpen("DataLog.txt",0); //re-open existing db("DataLog Append"); break; default:db("Datalog.txt problem");return; } FILE_WriteSeek(FILE_WriteGetCurrentSize()); FILE_WriteBuffer(DataLog_Cache,DataLog_Index); DataLog_Index=0; FILE_WriteClose(); } void DataLog_Commit(){ //write cache physical sd card xSemaphoreTake(DataLog_Mutex,portMAX_DELAY); CacheCommit(); xSemaphoreGive(DataLog_Mutex); } void DataLog_HoldSafe(){ //commit to disk but don't release mutex (we've lost power) if (DataLog_Mutex&&(DataLog_Held==0)){ //only if DataLog has been initializied xSemaphoreTake(DataLog_Mutex,portMAX_DELAY); //take but don't release DataLog_Held=1; CacheCommit(); } } void DataLog_UnHold(){ //power back up so release logging for use by tasks if (DataLog_Held){ xSemaphoreGive(DataLog_Mutex); //release mutex now DataLog_Held=0; } } void DataLog_PrintFile(){ file_t F; char s[120]=""; u8 b[2]={0,0}; xSemaphoreTake(DataLog_Mutex,portMAX_DELAY); if (FILE_ReadOpen(&F,"DataLog.txt")<0){ db("DataLog_Printfile problem"); xSemaphoreGive(DataLog_Mutex); return; } while(FILE_ReadByte(&b[0])>=0){ //read until EOF if(b[0]=='\r')continue; if(b[0]=='\n'){ b[0]=0; strcat(s,(char*)b); //null terminate db("->%s<-",(char*)s); //print line strcpy(s,""); //reset }else strcat(s,(char*)b); //add char } FILE_ReadClose(&F); xSemaphoreGive(DataLog_Mutex); }

I'm using a core32 to log data from environmental sensors. I'm concerned that writing 100bytes to a file every few seconds would result in the modification to the SD card's file allocation table (FAT) that over time may cause it to fail. As a result I've made my logging code so that it caches the log records and writes them in one pass 10kbytes at a time. I have the core hooked up with an analog input monitoring a signal derived from the 12V pre-regulated supply. If the power fails (or is switched off) the falling voltage is detected and the cache is written to disk followed by a call to FILE_WriteClose() . My assumption is that the FAT is only modified when the FILE_WriteClose() is called. I havn't looked at the filesystem code underlying the midibox FILE module, so my questions are: Does the SD card have inbuilt wear leveling? Does my strategy of write caching help the situation? Assuming I'm writing lots of data over time what is the best strategy for getting maximum life fro m the SD Card?

Yes, what I've suggested would result in being able to have separate icon's to startup the separate instances (each with their own stored saved properties as I described). To set up an instance, the user would create an icon/shortcut then edit the command line with an instance name as argument. I imagine behind the scenes a folder with the settings files for each instance which could be copied/deleted/edited if required.

The idea is to handle multiple instances smoothly. If a user starts MIOS Studio as they do now, it will be the same as now: it remembers midi in/out devices and path to hex file. If a user starts MIOS Studio with an argument say "project1" then the following settings are saved somewhere to be loaded next time MIOS is invoked with "project1": screen position and size of windowsize of all horizontal dividersmidi in/out devicespath to hex fileany other settings to remember?perhaps the argument e.g. "project1" appears in the window titleThe idea is the user saves shortcut(s) to various instances for simultaneous or consecutive uses: e.g I am working with a project that makes big use of the terminal on a particular virtual midi port, at the same time as controlling another midibox that uses the virtual keyboard but not much terminal,etc,etc.

Well, great news the (free) StateViewer plugin for Eclipse works! In the picture I have only one queue (registered as "Console"). In the right window it shows that this queue is blocking "ConsoleT" as it waits for commands that are enqueued by the debug callback (comand line parser). The "Min Free Stack" field shows only a maximum of 255 in bytes. This is in contrast with the vTaskList() output which shows in min stack in 32bit words: The instructions on how to download and install the free plugin is here: http://www.highinteg...WER_Plug-in.pdf

Some kind of diagnostic output, followed by a controlled reset (or vice versa) in the case of hard faults is a great idea! With regard to my bug, the funny thing is, I didn't do anything wrong with array bounds, I haven't changed the code that writes to the array, it works. It does make sense to what I was seeing that important system memory was getting clobbered: the manifestations where not always identical.

Well happily, Ive made progress with both debugger and debuggee! I can confirm that Eclipse/OpenOCD 0.5.0 works fine with windows 7 x64. There is some very minor tweak to .cfg file using the interface and target files that come in the OpenOCD directories. If anyone is interested in the details of this esoterica please write to this thread or PM me. Firstly the hard faults seem to have been caused by an array definition outside of the function that modifies it: by defining the array static has fixed the problem. This is funny because I've not had this problem on other platforms. The debugger stack display showed an execution address of 0xfffffffc followed by Hard fault handler followed by a series of hierarchical midi functions ending in a nonblocking midi tx function that was where it seemed to be stuck. Hence no midi error messages to MIOS Studio, and no LCD hard fault message. Anyhow I thank debugging in Eclipse as a big help. I will persist in figuring out how to flash program through OpenOCD to improve the user experience even more.

Thanks for the tips, Thorsten. By increasing the heap, I've been able to increase the stack in the (de)bugged task. It does not appear to be an out of stack situation. Its a little frustrating the core becomes unresponsive after running a function I'm sure was working ok before... Anyhow I'll work through it. Unfortunately the Eclipse OpenOCD setup does not work now that I am using Windows 7 64bit. It seems to be usb driver related. I have some options to use XP for debugging purposes.

The code below basically reformats the text so that the columns align nicely regardless if tabs are not supported.This is working for me again, now. I'm still getting failures (freezes) with other parts of the App, so I'll resort to the debugger with Eclipse. I also received instructions on how to enable the Stateviewer kernel aware debugger plugin. It will be great if it works. It has 2 windows that get updated upon break or pause: Tasks: a more detailed data similar to vTaskList() Queues: list details to do with the state of queues for which vQueueAddToRegistry() has been called. Like I said: great if it works. I'll post back with results. #define db MIOS32_MIDI_SendDebugMessage void Display_TaskList(){ int gap,x; char *r,*s,*context1,*context2,*t,line[60]; t=malloc(1000); vTaskList((signed char*)t); r=strtok_r((char*)t, "\n", &context1); while (r){ // db(r); s=strtok_r((char*)r, " \t", &context2); strcpy(line,s); //name gap=12-strlen(s); for (x=0;x<gap;x++) strcat(line," "); //pad to max 12 chars s=strtok_r(NULL, " \t", &context2); strcat(line,s); //state s=strtok_r(NULL, " \t", &context2); gap=4-strlen(s); for (x=0;x<gap;x++) strcat(line," "); //right justify 12chars strcat(line,s); //priority s=strtok_r(NULL, " \t", &context2); gap=6-strlen(s); for (x=0;x<gap;x++) strcat(line," "); //right justify 12chars strcat(line,s); //free stack s=strtok_r(NULL, " \t", &context2); gap=4-strlen(s); for (x=0;x<gap;x++) strcat(line," "); //right justify 12chars strcat(line,s); //task id db(line); r=strtok_r(NULL,"\n",&context1); }; free(t); }

I'm having hard fault crashes in a routine that formally worked o.k I suspect the problem may be insufficient stack. In the task creation I specify configMinimalStack+1000 as the stack size parameter. If I go any bigger than this I get "could not allocate block" etc (several times) on the Mios Studio console followed by an application crash. Is there a way to make the stack bigger? I set up a call to vTaskList() which prints out "high water mark" free stack space for each running task plus some other useful diagnostics, (used to work, and handy, too) but this crashes also, (maybe related?) More generally, any advice for debugging when "hard faults" occur? thanks

Thanks, I think I'll change to using this second port for the sensor network. Im using an extra GPIO port pin to switch bus power on and off, in order to reset the sensors and put them in the address assignment state (part of their bootloader). This means just one connector for both IIC and power switch (J19 as it happens). The normal fixed address IIC devices can be attached to first IIC port. I've got the address assignment part working well using the Transferwait code as a template. Your hint has saved me LOTs of time, so thanks again! (I'll post some code soon in case anyone is interested).

I recall not having luck to change the baudrate with MIOS32_UART_BaudrateSet(..) However using a #define MIOS32_UART2_BAUDRATE 115200 definitely works. (I was using UART2.) Take the time to study all of the tutorial code as well as having a good look at the apps in the repository. It is very likely every different step you need is demonstrated somewhere. Its a great way to learn how to code really well as the quality of the stuff in the repo is almost always top notch IMHO. A midi controlled valve amp is not so difficult sw project to implement. However, the hardware aspect, due to the high signal gain you'll want, noise crossing over from the digital side is a real challenge! One approach is to completely optically isolate the digital control from the analog signal path. A way of doing this is to drive an LED with analog brightness using PWM which is optically coupled to a light dependent resistor. DC voltages used for example to set up bias voltages around the valve stage for example, you can use a standard optoisolator again driven with PWM from the digital side, and the analog DC reconstructed (lpf) on the valve side. In other words I believe if you just control the signals with I2C digi pots connected to the valve circuitry, you'll have disappointing results, noise wise.

Thank you so much! I'll study this carefully, but a quick question I haven't been able to sort out: On what pins/port of core STM32 is the second IIC port?

I've got some micro controllers in a sensor network attached to the I2C bus. The bus master is a STM32 core at the moment. Prior to talking with the sensors over the I2C (which is working great btw) I want to go into an "address assignment" mode. This involves placing a series of clock pulses on the SCL line. The sensors listen to the clock pulses and output (Open Drain) on the SDA line at the rising edge of the clock. They actually output a unique serial number over 32 clock pulses. On the falling edge they read the state of the SDA line. If the bit of the serial number is high, but the sensor reads low, then the sensor "drops out" until the next 32bits are clocked. If a sensor has not dropped out by the end of the 32nd bit, it's I2C address is the count. It then drops out. The core finishes enumerating when it reads 0xffffffff. This means that all of the devices on the bus has a unique I2C address. Ive searched the mios files and found a confusing array of GPIO functions and structures. I want to make SCL of I2C port 1 an open drain (or pushpull) output.make it go high and lowmake the SDA pin an inputread the state of the SDA pinInitialise the I2C port and use it in the usual wayAny hints greatfully accepted!

The compiler (or assembler) organises instructions that go into Flash memory according to the Hex file that it generates. The details of what, and where are hidden from the programmer so that they can concentrate on the logic and design of the code. Of course you can always inspect asm listings of compiled code if you are curious or otherwise need to. Ram addresses are derived by the compiler according to the variables declared in your program, again the details of exactly what goes where is usually preferred to be hidden from sight. It is the instructions in Flash which reference and use the RAM space for varaibles. Variables to be stored in an external eeprom are under the control of the programmer/coder. (In general) If you want to modify a program to store data to external eeprom: -identify the data -copy it to eeprom using a library routine -load it from eeprom to the data space -have a way of controlling when and what is read from/written to eeprom hope this helps

Works well, thanks TK! Oh, and if negative numbers are possible use: MIOS32_MIDI_SendDebugMessage("%d.%03d\n", (int)value, abs((int)(1000*value)%1000)); otherwise you get a negative symbol appearing in the fraction part.

I need to display floating point variables as I am experimenting with sensors of different kinds. I find sprintf() is not formatting float types. Is there a switch somewhere that controls the compile of stdio.h functions to include a full featured string formatter library? Also is floating point math fully supported by default? thanks