Duggle

Yup, perl not in path. Project makes all the files. I'll have to edit the relative paths in the makefiles because I've copied the bootloader source directory to another location. I'll end up putting the modified bootloader in all my STM32 cores so that apps get compiled with the right (the same) *bsl*.inc which is for the modified bootloader. Next task is to flash and test the bootloader.

That's a great offer, thanks Thorsten, HOWEVER, the install of perl on this machine is BROKEN (perl not found).The invocation within the makefile leads to a terse error message. (Funny because I used the perl scripts to compile banks for my old Midibox64 just early last year....) Firstly I'll reinstall and report back!!!

Thanks for the advise! It sounds like a big investment of time because I've hardly used Linux. I don't imagine that I will be compiling many bootloaders. Is there a way I can hack a cludge into the perl script to get me going? (even if it only works for this one project!)

I'm making a modified Bootloader to (hopefully) enable upload of apps from all UARTs (i.e UART0,UART1,UART2). Anyhow, I've hit a problem with make of the (unmodified) Bootloader: First of all these compiler warnings: Creating object file for mios32_midi.c /MIOS32prj/mios32/trunk/mios32/common/mios32_midi.c: In function 'MIOS32_MIDI_SYSEX_Cmd': /MIOS32prj/mios32/trunk/mios32/common/mios32_midi.c:1494:3: warning: implicit declaration of function 'BSL_SYSEX_Cmd' /MIOS32prj/mios32/trunk/mios32/common/mios32_midi.c: In function 'MIOS32_MIDI_SYSEX_Cmd_Query': /MIOS32prj/mios32/trunk/mios32/common/mios32_midi.c:1577:4: warning: implicit declaration of function 'BSL_SYSEX_ReleaseHaltState' Then an error with the perl generator part: ------------------------------------------------------------------------------- Application successfully built for: Processor: STM32F103RB Family: STM32F10x Board: MBHP_CORE_STM32 LCD: dummy ------------------------------------------------------------------------------- arm-none-eabi-size project_build/project.elf text data bss dec hex filename 16088 80 5784 21952 55c0 project_build/project.elf make[2]: Leaving directory `H:/MIOS32prj/sw/Controller/Bootloader' mv project_build/project.bin project_MBHP_CORE_STM32.bin perl gen_inc_file.pl project_MBHP_CORE_STM32.bin mios32_bsl_MBHP_CORE_STM32.inc mios32_bsl_image mios32_bsl process_begin: CreateProcess(NULL, perl gen_inc_file.pl project_MBHP_CORE_STM32.bin mios32_bsl_MBHP_CORE_STM32.inc mios32_bsl_image mios32_bsl, ...) failed. make[1]: Leaving directory `H:/MIOS32prj/sw/Controller/Bootloader' make (e=2): The system cannot find the file specified. make[1]: *** [MBHP_CORE_STM32] Error 2 make: *** [MBHP_CORE_STM32] Error 2 **** Build Finished **** Are the compiler warnings a problem? I'm not sure whats going on with the perl part. I'm assuming the generated *.inc file is necessary for apps to be built with, so that they are able to be loaded by the new bootloader? Thanks

In the current situation I want to debug and monitor an application that is at the other end of my property and has to go through walls (<50m total distance). I'm having success with a pair of these: BTserialAdaptor The main hassle with these is the requirement to use standard (not MIDI) baud rates. I'm communicating through UART2 which works fine with MIOS Studio (using a COM driver), but the bootloader only works with USB0 and UART0. The BT adaptor is rated at 100m with standard antenna. A cable would be painful but its good to know 50' works fine.

I think the answer for me at least is to implement a "msd on nn" where nn is number of minutes after which the core reverts back to USB midi. This way I can edit a config or transfer a file etc, but then regain control over the core via USB midi!

Ive implemented this in my program from your code,TK. The problem I've found with this, is when I type "msd on", I can't then type "msd off" (or anything) because the USB midi is off. If I use MIOS Studio through GM5 on the PC ( and init with MIOS32_MIDI_DebugPortSet(UART0);) I have control as expected. This is a pity because the faster uploading of code using USB is nice as well as the possibility of using the core with wireless usb link: I think I heard that this is not a limitation with Mac (MIDI + COM +MSD at the same time)?

I'm using MBHP in a project where it is a little away from the computer I'm coding on. It would be really cool to be able to use MIOS Studio with the core wirelessly! Using MIDI i/O I will be trying a bluetooth serial adaptor at each end (which I have on hand). This involves Max232 level shifters at the host PC Midi Port. I'll use a GM5 module TTL midi connection to the max232. Another max232 at the core end to attach the bluetooth dongle. I'm not sure whether the adaptor will support the midi baudrate.....will find out. Pros of this approach is the excellent range of Bluetooth. Using USB I/O This would/should have the benefit of being able to access the USB port on the core as COM and MIDI and MassStorage. Using a product such as this: Dlink Or this:CablesUnlimited Question is would such wireless links work with all classes of USB device? (The CableUnlimited product does not support isosynchronous transfers, so perhaps not MIDI.) The Dlink product being a hub looks more promising (although it states that it does not support USB webcams, I wonder if this is due to throughput?) Anyhow does anyone have experience using a product such as this with MIOS32 cores?

Thanks TK, I'll use a pushbutton toggle with LED to switch between MSD (when USB is connected to a host) and internal sd card usage.

Hi, I'm using the mass storage driver similar to the example msd example, so that files on the sd card may be accessed at any time simply by plugging in a computer host via usb. Is it possible to (I assume a semiphore is required) simultaneously access files by my mios32 application? I'm about to experiment using FILE_ functions <file.h> for file i/o. I thought I'd ask the question. I'm kind of thinking that the app will need a switch to control which part has sd card file access enabled external_host<->app. It would be nice if they could both have access to files any time. thx.

Great, I'll do this.

Thanks Thorsten, it works fine. The only thing I had to do was put in #ifdef __cplusplus extern "C" { #endif .. #ifdef __cplusplus } #endif around the function declarations in ff.h for c++ compilation. It would be good (for c++ coders) if headers get committed this way. Cheers

well, duh. change the default: #define MIOS32_MIDI_DEBUG_PORT USB0 to #define MIOS32_MIDI_DEBUG_PORT UART0 in mios32_config.h does the trick!

I'm doing stuff with SD Card and mass storage driver. Unfortunately this means losing the midi usb driver with the PC (when ever mass storage gets activated). When mass storage functionality is activated on the core32, MIOS Studio loses its connection (and needs to be restarted). My solution? Use MIOS Studio with a dedicated USB to midi interface and use uart midi for flashing the program and console debug. Problem is MIOS Studio finds the core and flashes it, but debug i/o console is not connected. Where do I define which midi port gets used for console i/o? thanks

The declarations and definitions in the repo need to be appropriately modified for this weak override business to work. The only way I can seem to get it to work is to comment out TK's implementation of get_fattime(). Anyhow it's working fine! This is in my app.cpp extern "C" DWORD get_fattime(void) { return RTC_GetFatTime(); } and this is added to the RTCC driver routines listed earlier: DWORD RTC_GetFatTime() { DWORD FatTime=0; char secs,mins,hrs,date,mth,yr; secs=RTC_RdReg(reg_seconds); secs&=msk_seconds; mins=RTC_RdReg(reg_minutes); hrs=RTC_RdReg(reg_hours); hrs&=msk_hours; date=RTC_RdReg(reg_date); mth=RTC_RdReg(reg_month); mth&=msk_month; yr=RTC_RdReg(reg_year); FatTime|=BCD2Int(secs)>>1; FatTime|=BCD2Int(mins)<<5; FatTime|=BCD2Int(hrs)<<11; FatTime|=BCD2Int(date)<<16; FatTime|=BCD2Int(mth)<<21; FatTime|=(BCD2Int(yr)+20)<<25; return FatTime; } /* 31-25: Year(0-127 org.1980), 24-21: Month(1-12), 20-16: Day(1-31) */ /* 15-11: Hour(0-23), 10-5: Minute(0-59), 4-0: Second(0-29 *2) */

I think this article demonstrates how the attribute works: Article I'll have another try.

Hi TK, I've experimented by modifying the header declaration to: DWORD get_fattime (void) __attribute__((weak)); I'm confused however, as the declaration appears in ff.h (not diskio.h) and your implementation is defined in diskio.c Anyhow, I'm finding that your implementation is getting executed, not mine, which is implemented in my app.cpp I'm sure what I need to do here? Did I get the declaration syntax right? thanks.

Here's some code to access this device: (at least the RTCC features) MCP79410.h #ifdef __cplusplus extern "C" { #endif extern void RTC_init(); extern char* RTC_GetTimeString(); //read time "hh:mm,dd-mm-yyyy" extern char IsTimeStrFormat(char * ts); //validate TimeString format extern void RTC_SetFromTimeString(char* ts); //set time "hh:mm,dd-mm-yyyy" extern void RTC_PutForward1Hour(); //put time forward an hour (i.e -> Daylight Savings) extern void RTC_PutBack1Hour(); //put time back an hour (i.e-> NON Daylight Savings) extern char RTC_IsSet(); //has the RTCC been set? #ifdef __cplusplus } #endif MCP79410.c #include <mios32.h> #include <string.h> #include <time.h> #include "MCP79410.h" #define I2CADDR 0x6F #define VbatEnableReg 3 #define VBATEN 3 #define ST 7 #define reg_seconds 0 #define msk_seconds 0x7F #define reg_minutes 1 #define reg_hours 2 #define msk_hours 0x3F #define reg_day 3 #define msk_day 0x07 #define reg_date 4 #define reg_month 5 #define msk_month 0x1F #define reg_year 6 #define reg_control 0x07 #define SQWE 6 #define OUT 7 #define SRAM_START 0x20 void RTC_WrReg(u8 r,u8 d){ u8 sub[2]; sub[0]=r; sub[1]=d; s32 x=MIOS32_IIC_Transfer(0,IIC_Write,I2CADDR<<1,sub,2); x=MIOS32_IIC_TransferWait(0); } u8 RTC_RdReg(u8 r){ u8 d; d=r; s32 x=MIOS32_IIC_Transfer(0,IIC_Write,I2CADDR<<1,&d,1); x=MIOS32_IIC_TransferWait(0); x=MIOS32_IIC_Transfer(0,IIC_Read,I2CADDR<<1,&d,1); x= MIOS32_IIC_TransferWait(0); return d; } u8 Int2BCD(int x){ //return integer as two decimal digits char low=x%10; char hi=(x/10)<<4; return hi|low; } int BCD2Int(u8 bcd){ //Convert two BCD digits to Integer int h=10*(bcd>>4); return h+(bcd&0x0f); } void RTC_init(){ char regval; regval=RTC_RdReg(VbatEnableReg); //read dont change other bitfields regval|=(1<<VBATEN); //enable backup supply RTC_WrReg(VbatEnableReg,regval); regval=RTC_RdReg(reg_seconds); //read dont change other bitfields regval|=(1<<ST); //start the osc RTC_WrReg(reg_seconds,regval); RTC_WrReg(reg_control,((1<<SQWE)|(1<<OUT))); //enable squarewave 1Hz on MF Pin. Requires pullup on MFP } char* RTC_GetTimeString(){ //return timestr static char s[24]; char secs,mins,hrs,date,mth,yr; secs=RTC_RdReg(reg_seconds); secs&=msk_seconds; mins=RTC_RdReg(reg_minutes); hrs=RTC_RdReg(reg_hours); hrs&=msk_hours; date=RTC_RdReg(reg_date); mth=RTC_RdReg(reg_month); mth&=msk_month; yr=RTC_RdReg(reg_year); sprintf(s,"%02X:%02X,%02X-%02X-20%02X",hrs,mins,date,mth,yr); //TimeStr return s; } char IsTimeStrFormat(char * ts){ //"hh:mm,dd-mm-yyyy" char result=0; if (strlen(ts)==16) result=1; else{ MIOS32_MIDI_SendDebugMessage("TimeStr format:\"hh:mm,dd-mm-yyyy\" bad length-%d-",strlen(ts)); return 0; } if ((ts[2]==':')&&(ts[5]==',')&&(ts[8]=='-')&&(ts[11]=='-')) result=1; else{ MIOS32_MIDI_SendDebugMessage("TimeStr format:\"hh:mm,dd-mm-yyyy\" bad format"); return 0; } return result; } void TimeStr2tm(struct tm* T, char* t){ //fill in struct tm with an input timestr T->tm_hour=(t[0]-0x30)*10+(t[1]-0x30); T->tm_min= (t[3]-0x30)*10+(t[4]-0x30); T->tm_sec=0; T->tm_mday= (t[6]-0x30)*10+(t[7]-0x30); T->tm_mon= (t[9]-0x30)*10+(t[10]-0x30)-1; //from 0 T->tm_year= 100+(t[14]-0x30)*10+(t[15]-0x30); T->tm_wday=0; T->tm_isdst=0; } char RTC_IsSet(){ char yr; yr=RTC_RdReg(reg_year); return (yr>0x10); //unset RTC has year==01 } void RTC_PutForward1Hour(){ //put time forward an hour (i.e -> Daylight Savings) char hrs=RTC_RdReg(reg_hours); char x=hrs; x&=~msk_hours; //clear hours field hrs&=msk_hours; //clear non hours field(s) hrs=BCD2Int(hrs); ++hrs; //inc hours as integer if (hrs==24) hrs=0; hrs=Int2BCD(hrs);//store as BCD hrs|=x; //set control bits RTC_WrReg(reg_hours,hrs); }; void RTC_PutBack1Hour(){ //put time back an hour (i.e-> NON Daylight Savings) u8 hrs=RTC_RdReg(reg_hours); u8 x=hrs; x&=~msk_hours; //clear hours field hrs&=msk_hours; //clear non hours field(s) hrs=BCD2Int(hrs); if (hrs==0) hrs=23; else --hrs; //dec hours hrs=Int2BCD(hrs);//store as BCD hrs|=x; //set control bits RTC_WrReg(reg_hours,hrs); }; void RTC_SetTime(struct tm* T){ char x,mins,hrs,date,mth,yr; mins=Int2BCD(T->tm_min); //load and convert to BCD hrs=Int2BCD(T->tm_hour); date=Int2BCD(T->tm_mday); mth=Int2BCD(T->tm_mon+1); //months start from 0 yr=Int2BCD(T->tm_year-100); //year counted from 1900 //dont worry about seconds RTC_WrReg(reg_minutes,mins); x=RTC_RdReg(reg_hours); //read all x&=~msk_hours; //clear data bitfields hrs|=x; //set control bits RTC_WrReg(reg_hours,hrs); RTC_WrReg(reg_date,date); x=RTC_RdReg(reg_month); x&=~msk_month; mth|=x; RTC_WrReg(reg_month,mth); RTC_WrReg(reg_year,yr); } void RTC_SetFromTimeString(char* ts){ //"hh:mm,dd-mm-yyyy" struct tm T; TimeStr2tm(&T,ts); RTC_SetTime(&T); }

I'm using the device without unique ID feature MPC79410. The data sheet says 700nA to power in standby (Vbat=1.8V) so I think a Lithium coin cell is the best for most use cases. I calculate the 0.9F supercap will keep the clock running for only 36days. A coin cell may easily have 100mAhrs that's >100,000 hrs, well over 10 years.

Here's the interconnects I'm using:

Yes, the set_timestamp(..) example works. Just have to make sure this gets called when data in the file is changed. Thanks!

Hi All, I've connected a RTCC (real time clock calendar) chip MCP79410 to IIC bus STM core32. I'm able to set it and read it o.k It keeps time when the core is not powered (by way of supercap). Question is: Is there a way to use this time with SDcard so that files created have the correct timestamp? Ive been playing with the SD card Tool application to see how file accesses are done. thanks

Yes, and you can initiate SRIO scans more frequently than the MIOS32 tick rate. IIRC there is discussion and examples of this on these forums.