Messages

31

utFAT / Re: SD Card questions

« on: February 23, 2011, 04:22:36 PM »

Hi Dave,

I too hit your point1 here is the text from an email I sent to Mark about this, it also gives a possible solution to detecting a changed card by using its serial number.

Point 2, I would think would be easy to add, not sure about point 3

Thanks Mark,

I understand about the switches, it would be good not to have to use them. But it would be useful to detect card changes, I can’t guarantee what the user will do.

Do SD cards have unique serial numbers that could be checked? A quick google seemed to talk about the SD cards serial number stored in the CID register, could this be polled periodically to check if it exits / has changed, which would indicate a change?
Page 60 of this document http://www.sdcard.org/developers/tech/sdcard/pls/Simplified_Physical_Layer_Spec.pdf  talks about CMD10 being used to read the CID of a card.

With your demo is there any command to re-mount the card?
Maybe the info command could read the CID and remount the card if a different CID is found

FAT16 support would be nice, as I can see that some user devices would be preformatted this way. I agree with you about FAT12. I presume you would support read and write under FAT16.

Just compiled V1.8 and confirmed it works as before

Would it be helpful to transfer this conversation to the forum, for the benefit of other users or just post a summary at the end?

Cheers

Martin

From: Mark Butcher [mailto:Mark@uTasker.com]
Sent: 05 January 2011 13:45
To: Martin Honeywill
Subject: AW: Testing utFAT - more stuff

Hi Martin

I attached a V1.8 (it doesn’t have anything that will change things – just NAND FLASH interface and a couple of minor features as in the thread).

The problem is the following: SD card insertion and removal is detected by switches on the SD card sockets. The Luminary board has these switches connected to GND so they can’t be used (also the write protect switch cannot be detected). Some of the sockets also don’t have these switches physically. 90% of boards don’t connect them and so I didn’t put any generic support for them in the code for this reason.

Detection is achieved the first time due to the fact that the interface is regularly trying to mount the card. When a card is inserted it can be mounted and subsequently used.

If the card is removed the SW doesn’t know this. It will be detected only the next time that accesses are attempted, which fail. Then it would be possible to restart the mounting/detection process if required. If the mounted card is removed and a different one inserted this will not be seen. It can result in strange effects if files are open and especially if the card is different.

That means that it is essentially designed for a fixed inserted card – mainly since there is often no switch available (as on the LM boards).

Only FAT 32 is supported – in fact I will add FAT 16 soon since I don’t think that Windows likes working with FAT32 when the file system is small (eg. When a small NAND Flash is used). It should only be a few lines of code. I don’t think that FAT12 is of any use though (it is more complicated and FAT16 seems small enough anyway for typical FLASH chips).

Regards

Mark

32

LCD Graphics Library and Simulator / Re: glcd 240*128

« on: February 21, 2011, 12:08:56 PM »

The first question is What is your Display module and what Chip does it use? There are many different modules and interface chips.

33

NXP^TM M522XX, KINETIS and i.MX RT / Re: M52259 TOWER - TFT display and Temperature/humidity sensor

« on: February 02, 2011, 12:06:44 PM »

Hi Jez,

I use a full version of VC, and to clarify it seems like a change to a header file triggers dependant C files to be recompiled, but sometimes not C++ files (i.e. the simulator files). As an example if I have a GLCD emulated and then change its size and just try to run again, this change has not occurred in the simulator. A full compile fixes it.

Martin

34

NXP^TM M522XX, KINETIS and i.MX RT / Re: M52259 TOWER - TFT display and Temperature/humidity sensor

« on: February 02, 2011, 09:22:34 AM »

Hi Jez,

I use the Luminary Micro Version of uTasker, and its my experience that VC does sometimes to recognise that a change in a header file means that it needs to recompile a cpp file. So if your change effects something in the simulator best to do a full build. Never have gotten to the bottom of this "feature".

Cheers

Martin

35

LCD Graphics Library and Simulator / Re: Do you have a list of the Graphics chips uTasker gurrently supports

« on: January 16, 2011, 10:25:37 AM »

Thanks Mark, From initial looking at the data sheets it looks like the SSD132x chips all seem to have a similar register set so should be pretty compatible from a driver point of view.

I'll also look at the Samsung code to see how multiple chips are handled. I guess multiple initialisations are required. Also does the simulator handle multiple chips/displays? I'll find out.

36

LCD Graphics Library and Simulator / Do you have a list of the Graphics chips uTasker currently supports

« on: January 14, 2011, 05:22:37 PM »

Hi Mark,

I'm currently looking at two OLED displays for a new project one uses a SSD1322 controller and the other uses a SSD1326 controller. I would probably interface either via SPI.

I am trying to build a definitive list of what is currently supported. Looking at the uTaskerLCD manual it covers

1. Text based displays using the HD44780 type chip

2. T6963C - Toshiba

2. KS0108B - Samsung

3. SSD1329 - used on Luminary OLED displays

4. NXP LPC2478 built in TFT controller

5. - used on Atmel AVR32 EVK1105 board

6. - Used on Nokia 6100 displays is this an Epson S1D15G00 or NXP PCF8833 (Leadis LDS176 is compatible with PCF8833) info about the Nokia6100 display was found here http://www.sparkfun.com/tutorial/Nokia%206100%20LCD%20Display%20Driver.pdf

Have I covered all the options above? I've created this list because I thought it would be helpful to see which chips were supported, as these are used on may different types of display. The underlying Chip type is the common factor.

I'm hoping the SSD1322 and SSD1326 are not too different from the SSD1329 that you already support. But its early days, not even sure if we are using OLED displays yet.

The displays we are looking at are wide and not very high 256 x 32 pixels, what I would like to do is put 2 displays side by side (512 x 32). To do this I would need 2 controller chips, would the logic of the uTasker display support a display made up of two controllers? To the main application it would look like one display space.

Cheers

Martin

37

Luminary Micro ^TM LM3SXXXX / What are the recommended pull-up resistors when using an SD card

« on: December 20, 2010, 11:34:32 AM »

Hi Mark,

I'm looking at incorporating a micro SD card into a board revision. I've looked at the schematics for the Luminary Eval boards and

1. The LM3S6965 board has pullups on pins 1 and 8 (which are DAT2 and DAT1) this makes sense as they are unused in SPI mode
2. Also the Micro SD card on the IDM_L35_RDK kit has a pull-up on the /CS line
3. You say in this post http://www.utasker.com/forum/index.php?topic=786.msg3486#msg3486 that you also needed to ad a pull up to the MISO line.

So in all I need 4 pull ups does that make sense to you?

Cheers

Martin

38

MODBUS / Re: Modbus Timeout Error

« on: December 10, 2010, 04:49:30 PM »

Hi Peter,

Thanks for your comments, Both the Slaves and Masters are my design so I have control over the inter frame delay. Indeed the uTasker module has a define to control this specific point.

My questions are related to the specific way the uTasker Modbus module works, from my tests it looks like the Timeout you specify in the modbus parameters, starts from the point the first character is transmitted, rather from when the last character is transmitted. The problem with this is that I may have a very short message where a short time-out would work, but I may also have a large message which also has a large reply which would need a longer time-out.

You can see from the attached trace where the time-out is set at 10ms the time-out seems to be based on the start of transmission, the inter message gap is only 7ms.

My other worry was again with a short inter message time-out and receiving a large packet of data, would the time-out kickin in the middle of the packet being received?

I'm fixed with using RTU comms for other reasons.

Cheers

Martin

39

MODBUS / Re: Modbus Timeout Error

« on: December 09, 2010, 12:18:18 AM »

Hi Mark,

I'm replying to this document as my point is a follow on from the comments made earlier. I'm using modbus RTU at 115200 baud.

I currently have a TICK_RESOLUTION of 10ms and want to really get this down to a small value to allow for fast modbus responses. I've tried setting TICK_RESOLUTION to 1ms and this seems to have the desired effect for me. I have a few questions though

1. What are the implications of setting a small Tick resolution like this, I presume it is only the overhead of the Tick interrupt service routine and the associated timer handling code.

2. Are there any implications for the Simulator of setting a small Tick resolution?, I know it will not simulate a tick rate this fast but I presume it should still work as before.

3. Am I correct that the modbus Time-out is triggered from the start of the modbus send rather than the point the last byte of the transmitted message is sent? It would seem to be more logical to start the timer from the point the last byte of the transmitted message is sent but this might be more complicated to achieve. This also means that very long messages might easily take longer to transmit than the time-out time.

4. Related to point 3. above when does the time-out stop? if I start receiving a message that is large I might get a time-out in the middle of the received message unless, the no reply time-out has been stopped.

Basically what I want to do is just run the Modbus comms as fast as possible and minimise the inter message gaps. I will also be polling for new devices that may or may not be online hence me wanting to reduce the no reply time-out to a minimum.

Cheers

Martin

40

Luminary Micro ^TM LM3SXXXX / Re: stellaris bootloader in application

« on: November 11, 2010, 09:16:45 AM »

Hi

I presume you are using uTasker?
Have you looked at the bootloader options available in uTasker?
How do you intend downloading the new boot image, via a serial port?
Why do you want to use the Stallaris bootloader, and not the uTasker one?

Just a few questions that might make helping you easier.

Cheers

Martin

41

µTasker general / Changing the schedule time of a task under program control

« on: November 08, 2010, 05:42:52 PM »

Hi Mark,

I want to change the "period" of a task depending on particular conditions. This period is defined in ctTaskTable and as its defined as a Const it can't be changed. Is there a simple way to achieve this.

I could remove the "const" definition of ctTaskTable which would mean it would then reside in RAM, entries could then be modified. Would this be your suggested way of doing this.

I suppose the Task state could also start a monstable timer for my new period and change the task state to UTASKER_SUSPENDED. But this does seem a bit clumsy.

Cheers

Martin

42

Luminary Micro ^TM LM3SXXXX / Using the SPI interface with the LM3Sxxxx Chips

« on: November 02, 2010, 03:01:06 PM »

Hi Mark,

Due to my ongoing problems with the I2C interface in these chips http://www.utasker.com/forum/index.php?topic=990.0 I have decided to use the SSI interface on my next board, I'm stuck with the luminary chips at the moment as I've no time to change.

I notice that you don't use a driver interface as such to the SSI port in uTasker, would you suggest that I just modify the functions in the spi_sc16IS7xx.h file you sent me to provide SPI access to the second SSI port on this chip.

Cheers

Martin

43

Luminary Micro ^TM LM3SXXXX / Re: Fixing an IIC lockup with SDA held low

« on: October 28, 2010, 06:54:44 PM »

I've been having more problems with the IIC hardware on the Luminary Micro Chips see my post here

http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/p/71089/257873.aspx#257873

I'll keep this forum updated with any updates.

Martin

44

Luminary Micro ^TM LM3SXXXX / Re: Code hitting irq_hard_fault(void)

« on: October 27, 2010, 01:15:50 PM »

Hi Mark,

Yes I have this code, but I still get the problem. I'm using Rowley 1.7b22 and the Luminary Micro ICDI as my Jtag.

What I was trying to do by moving

fnEnterInterrupt(irq_ADC_Sequence_0_ID, ptrADC_settings->int_priority, _ADC_sequence_0_complete); // enter the interrupt

was to ensure that the interupt handler was setup first, before the ADC was enabled.

Regards

Martin

45

Luminary Micro ^TM LM3SXXXX / Re: Code hitting irq_hard_fault(void)

« on: October 27, 2010, 10:34:14 AM »

Hi Mark,

I've done a bit of investigation on another board that exhibits the same symptons, in debug mode it hits irq_hard_fault. But runs if the debugger is not connected. Like you I've found it to be ADC related.

If I don't initialise the ADC then it works fine.

I noticed that fnEnterInterrupt was being called quite late in the routine and wondered if this needed to be setup earlier, I tried moving it up but still had the same problem :-(

Have you managed to make any progress with this?

Cheers

Martin
               

fnEnterInterrupt(irq_ADC_Sequence_0_ID, ptrADC_settings->int_priority, _ADC_sequence_0_complete); // enter the interrupt