GrumpyOldPizza

I use this here (recalculates the real speed after rouding/truncating as well): /* * speed = SystemCoreClock / (20 * (1 + TPR)) * TPR = (SystemCoreClock / (20 * speed)) - 1; */ speed = 400000; tpr = (SystemCoreClock / (20 * speed)) - 1; speed = SystemCoreClock / (20 * (1 + tpr));

Perhaps this is usable for somebody else. It's a simple interrupt driven scheme to talk to 2 HC-SR04s. The trigger pulses are connected to PE2/PE3, while the echo pulses are connected to PD2/PD3. The echo pulses are measured via capture compare on WTIMER3AB. TIMER2A is used to send a trigger pulse every 50ms, interleaved of course between the 2 sensors. This results effectively in a 10Hz update rate. The code does not include the interrupt enable logic in NVIC. Should be simple enough though to add that based upon the target environment. "SystemCoreClock" is 80000000 on my system (this is

Bluebash, sorry if I was not clear enough. I was not looking for FS recommendations. I have a FAT filesystem whereby I was asking for other folks whether they could review/help making it more portable/usable. I am programming bare metal, so my internal interface might not be suited to perhaps integrate this into Energia, or other projects. Regarding Chan's FatFs. It's deeply rooted in the "as small as possible" philosophy. A friend of mine benched it at 80kb/sec throughput on a 10MHz SPI bus using small block (512 bytes). My requirement was in the order of 200kb/sec. The implementation I

I already got a long laundry list of things to do different, where I either ran out of time, or simple didn't see what was missing. Anyway, part of the software stack was to get a better FAT file system going (so that I could log raw sensor data at full speed). I'd like to put that out there, but would need a few individuals to perhaps look over the code and help massaging it so that it's useful outside my own little sandbox.

Kind of in a similar boat about toying with a PCB ... But directly towards this specific issue. If you know already a specific ARM chip and it's flavor of peripherals (and the tricky spots you need to be aware of), why switch to something else that is less powerful (and probably cheaper), just to having to relearn everything and potentially having to go again throu the routine of figuring out what does not work according to the data book ...

After a half way successful entry in the AVC 2014 competition I finally have the time to write a few words. The rover is build upon a rather cheap RC car, that however is a very reasonable platform for the project, the Turnigy 1/16 Monster Beetle. The core computing platform is a Stellaris Launchpad with RobG's excellent LCD booster pack, which doubles for me as LCD and microSD unit. There is a GY-87 IMU, which consists of a MPU6050 Accel/Gyro and a HMC5883L Magnetometer, plus a BMP180 Bario (which I did not use, regrettably). The SW on the LM4F120 is able to read the MPU6050

Here some quick and dirty code the the BP. Perhaps this is useful for other folks. API: extern void tft_init(uint32_t yt, uint32_t yb, const tft_font_t *font); extern void tft_terminal(const char *s); extern void tft_draw_point(uint32_t x, uint32_t y, uint16_t color); extern void tft_draw_line(uint32_t x1, uint32_t y1, uint32_t x2, uint32_t y2, uint16_t color); extern void tft_draw_rectangle(uint32_t x, uint32_t y, uint32_t w, uint32_t h, uint16_t color); extern void tft_draw_string(uint32_t x, uint32_t y, const char *string, uint32_t length, const tft_font_t *font, uint16_t color0, ui

Not sure about whether this is a typo. The other timing parameters (SCL low, SCL high) got adjusted as well ... BTW, how do you get 16MHz on SSI ? Running of PIOSC ? The readback is ULTRA tricky. The data sheet for the ILI9341 states that the SCL cycle time needs to be 150ns (not 100ns) for read operations. So you need to switch SSI setup between read and write. That ontop of having to switch between TFT (10MHz) and SDCARD (20MHz) anyway. I'm not sure whether the complexity is worth it. Thanx for pointing out the booster pack standard. A great help for my own project GPIO assignment (

Quick review of the V2 board I got this weekend. Porting an existing TFT driver from a similar board (say google for TFT01-2.2SP) was trivial. Only 2 sticky points were that the RESET signal was not hooked up (no idea whether this is a problem, but it's easy enough to do with a solder bridge), and that the LEDA input that was available to be driven via GPIO on the other TFT was tied to VCC all the time (although rereading the specs, I am also not that sure whether it's wise to tie LEDA to a GPIO ;-)). Otherwise it just came up with only the necessary changes for the GPIO pins in use. The

I am very easily distracted ;-) - Thomas

I am implementing a MMC/SPI driver for the LM4F120XL Launchpad. As per SD spec, there is a pullup resistor on the CS line on the SD card side. So on a LM3S811, I set a pulldown on the GPIO (Port A, SSI0 to be precise), I can read the presence of a SD card properly (1 if present, 0 if not). Tried about 6 different SD cards. Works fine. On the LM4F120XL, no matter what I do, I always get a 0 back. I crosschecked my code/setup by wiring the pin to 3.3v, and got the right reading. So it does not seem to be a trivial GPIO setup issue. Funny enough, after a SDcard is powered up, it driv

Wanted to say hi to everybody. Mainly to be polite before I nerve you folks with endless questions. Why ? I signed up to do an autonomous rover, and my choice of platform ended up being a EK-LM4F120XL ... I got 3 items in the pipe that I'd like to share in case anybody is interested in (well, some of them are not really finished ;-)) (1) A RTOS based upon the uITRON spec. Reason for going this route was to have something that is configured statically and would allow me to support the MPU properly. The thing is working quite neatly on a LM3S811 (which was my primary developement