Jump to content
43oh

PTB

Members
  • Content Count

    113
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by PTB

  1. Thanks for reply. I will give it a go. Cheers PTB
  2. I suspect (through use of fixed arrays) I have blown the available memory in an Energia Sketch. I have been using const... but I suspect they are still going into SRAM and causing corruption by filling memory. Eg. const char* keylabel [16] = {"7","4","1","0","8","5","2",".","9","6","3","","Exit","Clear","<-","Enter"}; In this link (which may or may not be correct) http://packetsofknowledge.se/Problems_with_using_large_constant_arrays_with_AVR/Arduino It talks of the need to use progmem, I thought I read somewhere that it doesn't work with arm? Sooooo.......
  3. @@jkabat Ok, I'm not sure what the intention of the "number_values" is but your post has given me more experimentation ideas. I tried a multitude of setups all reading or writing 1000 samples. Here are the results and the code portions used to generate them. My favourites are the Fast digital read/write separated routines which give results of 451 and 401 microseconds for 1000 samples and are still flexible codewise. That's 2 operations every microsecond. This one is just a learning exercise as the standard digital read and write commands are fast enough for what I want. C
  4. Ok I thought I would see if I had learned something.... it appears not. I tried to make a fast digital read and write.... they are terrible. Slower than the standard command. ///************************************************************************** /// /// Fast Digital Read Routine /// ///************************************************************************** uint16_t fast_digitalRead(uint8_t pin) { uint8_t ulPort = digitalPinToPort(pin); uint32_t ucPins = digitalPinToBitMask(pin); uint32_t value; GPIODirModeSet(ulPort, ucPins, GPIO_DIR_MOD
  5. @@RobG Hi Rob, I got one of your original screens...loving it. After seeing this above.. It got me thinking... Its not possible to turn off backlight on original screens is it ? Would explain why I cant turn backlight off.... BTW. The new one sounds great. +1 for including touch on it. Cheers PTB
  6. @JKabat @Rei Vilo @reaper7 I dunno John... Its still 3 microseconds too slow. Sensational ! You definitely appear to know your stuff. Number of Samples : 255 Sample Starttime : 11000011 Sample Endtime : 11000269 Sample Array Set Duration time in microseconds : 258 I also tried your "Late Edit" (Complete with disclaimer) but that slowed it down so I took it back out. Number of Samples : 255 Sample Starttime : 27725011 Sample Endtime : 27727786 Sample Array Set Duration time in microseconds : 2775 I did a little more housekeeping taking out some comments and unused defines and f
  7. @@jkabat @@Rei Vilo @@reaper7 This speed is getting very close to what i was hoping. Way cool. Unfortunately I think its going to be a day or 2 before I can have a further play with this. A library for this would be great. I was kind of hoping that would come about. Great job guys. My head is still spinning from this badboy. I've learnt a lot in this thread but my comprehension of it is still pretty hazy. Cheers PTB
  8. And Here's the Code // // LM4F_ADC // // Description of the project // Developed with [embedXcode](http://embedXcode.weebly.com) // // Author Rei VILO // Rei Vilo // // Date 21/07/13 09:42 // Version <#version#> // // Copyright (c) Rei VILO, 2013 // Licence CC = BY NC SA // // See ReadMe.txt for references // // Core library for code-sense #if defined(WIRING) // Wiring specific #include "Wiring.h" #elif defined(MAPLE_IDE) // Maple specific #include "WProgram.h" #elif defined(MPIDE) // chipKIT specific #include "WProgram.h" #elif defined(DIGISPARK) // Digispark spec
  9. @JKabat @Rei Vilo John, That has done the trick.!!! Good Job. Not quite the speed I was hoping for but it compiles, runs and has added a slight further speed boost. I will clean up all the detritus through the code before I post latest. Hopefully later tonight. I used "uint32_t value[8];" instead of "uint16_t value[8];" as it wouldn't compile otherwise. Also there was one instance of "ulcount" instead of "ulCount". The expected readings appear to be correct and here's the results........ Number of Samples : 255 Sample Starttime : 12000006 Sample Endtime : 12002462 Sample Array
  10. @JKabat @Rei Vilo No worries . Very hard to test code without a platform. Still no worky. I am wondering whether pulBuffer needs to be fed into value[0] somehow. I don't think value[0] was translated over. I think that might be it. If not pulBuffer.... I suspect some other variable needs to feed it. Cheers PTB p.s. adding these lines to the end printed the following Serial.println(ulCount);Serial.println(ulBase);Serial.println(*pulBuffer); 810738894400
  11. @JKabat @Rei Vilo Hi John, That appears to have fixed that line. Small typo... just had to add the R to SEQUENCE. It is still hanging... but further down the code. I sprinkled a heap of "Serial.println"s through the code as a temporary tracing measure. It appears to run the whole code but wont exit the subroutine. Edit: Ignore this bit..... works ok with the equivalent "brisk" version posted earlier Is that because the function declaration is a void and it is trying to return a value. => uint16_t fast_analogRead(void) { ?? Here is the output from the Serial Mon
  12. @JKabat @Rei Vilo Hi John and Rei, All that HWREG and Bit Shifting is beyond my current experience level. I'm getting seriously confused whenever I try to understand the syntax of it all. I'm Sure one day it will make sense. One thing I did get a handle on was John's Logic of splitting the command in to 2 separate routines. So in the spirit of "fast_analogInit" and "fast_analogRead" I split the original "analogRead" command into a not so fast version set. "brisk_analogInit" and "brisk_analogRead" ///**************************************************************************
  13. @JKabat @Rei Vilo Ok folks, Now it (LM4F_ADC.ino) compiles ok, but execution hangs. It appears to get stuck on this line within "fast_analogRead" routine. while (!(HWREG(ADC0_BASE + ADC_O_ISC) & (0x10001 << SEQUENCER))) {} I'm having a bit of a play to see if I can figure what is going on. This is quite the learning experience Cheers PTB
  14. @@jkabat @@Rei Vilo Ok, I have had a plough through this and I appear to be stuck. I had a look in wiring_analog.c and I can see the overall structure of what you have done with the 2 routines "fast_analogRead" and "fast_analogInit" being born from the standard "analogRead". As far as what each new equivalent line means exactly is a struggle for me to fully comprehend at the moment. I have spliced your code into my basic sketch. Posted in complete form below. I currently can't get the routine to compile at the moment and I think the root cause is I am missing some kind of
  15. JKabat, Thanks for the seriously value added answers. Awesome. I will have a play with this as soon as I can. Hopefully tonight. In my earlier haste I didnt realise I was looking at the digital pin read command GPIOPinRead instead of an analog. So another rookie mistake there on my part. Appreciate the feedback. Cheers PTB
  16. Ok, Have read through (and watched) a lot of that stuff and my head is spinning, but I think I am getting close. I added these lines..... #define SENSOR_INT_BASE GPIO_PORTE_BASE #define SENSOR_INT_PIN GPIO_PIN_3 then in main program added for (uint16_t i=0;i<SampleQty;i++) { // Sample[i]=analogRead(PE_3); Sample[i] = GPIOPinRead(SENSOR_INT_BASE, SENSOR_INT_PIN); } This compiles and runs ok. I am using SampleQty = 255 and this is giving me 3673 microseconds to get 255 samples => Or 1 sample every 14.4 microseconds for the old analogread. When using th
  17. Hi Rei, I had seen that post but wasnt quite sure if it applied to analog. Its all a bit unfamiliar to me at the moment, but I will give it a go. Thanks to you and Jkabat for pointing the right direction. Cheers PTB @@jkabat @@Rei Vilo
  18. Hi folks, I would like to do some pretty fast analog reads with the stellaris board. Preferably just from one pin. I loaded a snippet of code using 100 sequential reads .... Sample[0]=analogRead(PE_3); Sample[1]=analogRead(PE_3); Sample[2]=analogRead(PE_3); Sample[3]=analogRead(PE_3); Sample[4]=analogRead(PE_3); Sample[5]=analogRead(PE_3); Sample[6]=analogRead(PE_3); .... etc. And measured the time in microseconds at the beginning and end => and got 1434 microseconds to reel in 100 samples Assuming my maths is right, that's ~69,400 samples per second or one sample every 14.4 mic
  19. No worries, that other post helped me as well. Thats why i remembered it.
  20. Does this help? http://forum.43oh.com/topic/2993-new-energia-release-0101e0009-12062012/?p=25622 Cheers PTB
  21. Wow, That is really impressive. Nice work man. Cheers PTB
  22. Just a quick little update to my previous "NoobReview". Finally got the headers and time to solder them on. Plugged it in and.... Look Ma... No wires. This is a Stellaris => Bluehash Booster Booster => RobG touchscreen stack. On a full charge, I just let it sit there and it ran for about 2:30 hours before it started getting dim. At 2:50 hours it was very dim and I tried the touchscreen, but it was by then unresponsive but you could still read the display. So that's a pretty decent run with the backlight on the whole time. I may get a bigger battery and see how
  23. Hi Bluehash, Received the board today. It looks great. Thanks Heaps. Here are my comments/observations in addition to what cubeberg and Jwoodrell have already said. Even though I have been playing with electronics for a little while now, please remember I do have noob like tendencies. ;-) Anyway...... Here we go.... 1. Happy to pay a little more to get stackable header pins included as there were none with it. 2. As others have said it would be good to have a standard lipo connector on the board instead of the 0.1" header pins. Even better would be to have the connector as a 90 d
  24. Bluehash, RobG and other sellers. Your cheap boards and very reasonable postage rates are GREATLY appreciated. I'm in Australia and most of the time things show up eventually. I think sometimes there can be customs delay. On occasion i have had stuff show up 2 months after purchase and sometimes within a few days. There seems to be no logic to it. I have VERY rarely had stuff go missing. If it gets to 6 weeks I normally let the seller know and they usually send another item. If the first item arrives within that time and i end up with 2 of the same thing, i send the seller the money.
×
×
  • Create New...