De μC programmers Kroeg

[Infant]

Pizza_Boom schreef op dinsdag 31 maart 2015 @ 20:51:
Ik had eigenlijk verwacht dat het codevak een lengtelimiet had en scrollbaar zou worden.

Zou mooi zijn, nu is gewoon de verwachte levensduur van mijn scrollwiel met 1 promille gereduceerd.

Zou jij niet jouw code kunnen opsnorren en e.e.a. eens kunnen vergelijken?

Ik meen me te herinneren dat ik ooit de demo code van itead studio gejat heb:

*snor snor*

Dit. http://store.iteadstudio....39qbg1j0uf3738hl7701n5ch7

De link naar dat rar file doet echter niks meer, er staat me bij dat basically alleen de defines werkte en de rest volledig verbouwd moest worden.

Het verhaal gaat over de IRQ pin toch? Ik lees die nergens uit. Ik heb ze in 5 naar 1 modus gebruikt, en poll elke keer het STATUS register helemaal dood.

*scroll scroll..... scroll*

Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

[Pizza_Boom]

Infant schreef op woensdag 01 april 2015 @ 00:50:
Zou mooi zijn, nu is gewoon de verwachte levensduur van mijn scrollwiel met 1 promille gereduceerd.

Sorry, het spijt me zeer.

Ik meen me te herinneren dat ik ooit de demo code van itead studio gejat heb:

*snor snor*

Dit. http://store.iteadstudio....39qbg1j0uf3738hl7701n5ch7

De link naar dat rar file doet echter niks meer, er staat me bij dat basically alleen de defines werkte en de rest volledig verbouwd moest worden.

Als die interwebz weer gefixed is, ga ik die maar eens bekijken. Thanks.

Het verhaal gaat over de IRQ pin toch? Ik lees die nergens uit. Ik heb ze in 5 naar 1 modus gebruikt, en poll elke keer het STATUS register helemaal dood.

Statusregister zit op 0x27, maar ik vis zo 1, 2, 3 de mogelijkheid om het status register te pollen. Maar eens googlen of in de datasheet opzoeken, FF snel zoeken leert al dat de eerste dataout na een CSN toggle altijd status op MISO is.

Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

In regel 146 komt ie nog een keer, maar dan met 0x0B, 2 hoger dus. Waarom? Had ergens gelezen dat dit bij RX op deze manier moest.

[Ploink]

Infant schreef op woensdag 01 april 2015 @ 00:50:
Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

(0000 1010) = 10 (dec) = 0x0a (hex), dus niet 0x09, 1 er bij dus.
Om dit soort foutjes te voorkomen kun je denk ik beter direct "spi_send(0b00001010)" schrijven.

Pizza_Boom schreef op dinsdag 31 maart 2015 @ 20:51:
[...]
Ik heb ook 0 ervaring met uart en 4/5 maanden terug wist ik niets van communicatie tussen chips, inmiddels draait I2C en nu wil ik draadloos met spi. Echte libs gebruik ik niet echt, enkel 2 headers, waarvan xc8 voor de compilers is. Maar ook met pulldown erbij verandert er niets. Trek ik echter de nrf lijn eruit, dan valt ie wel naar 0 (en zonder pulldown zweeft ie soms richting 1 en weer terug).
[...]

Als ik dat goed begrijp van je omschrijving dan is het dus correct, de mcu pin is input en de nrf pin output. Je hebt dus niet twee outputs die armpje drukken tegen elkaar of twee inputs.

Ik heb ook pcb antenne, maar momenteel staan ze nog geen 10 cm uit elkaar. Ik heb op 3 bytes address geprobeerd, op 5 bytes, geen verschil. Ik las dat je ze op dezelfde payload moet hebben, ze staan samen hetzelfde ingesteld en ik stuur hetzelfde.

Misschien is 10cm zo dichtbij dat ze doof worden van de herrie (preamp is overstuurd). Zet ze verder uit elkaar of reduceer het zendvermogen.

[RobV]

Tip: Om lekker snel µ te typen op OS X, typ je option+M. De M van 'm'. Ik zat elke keer in de 'Special Characters' map te zoeken. 'U'-toets ingedrukt houden werkte ook niet. Nu ik het weet lijkt het zooooo logisch...

Edit: ook handig als je wilt opschrijven dat je capacitor 0.1µF is.

[ Voor 13% gewijzigd door RobV op 01-04-2015 11:43 ]

[lordprimoz]

RobV schreef op woensdag 01 april 2015 @ 11:42:
Tip: Om lekker snel µ te typen op OS X, typ je option+M. De M van 'm'. Ik zat elke keer in de 'Special Characters' map te zoeken. 'U'-toets ingedrukt houden werkte ook niet. Nu ik het weet lijkt het zooooo logisch...

Edit: ook handig als je wilt opschrijven dat je capacitor 0.1µF is.

1uF werkt meestal ook prima =P

[Ploink]

Ik tiep gewoon µ en Ω voor µF en kΩ

[RobV]

Werkt in html of forums heel goed idd maar niet in tekstdocumenten. En dan staat het wel zo mooi om µ te gebruiken

[Sissors]

Ik doe zelf op fora, powerpoint, etc niet de moeite normaal gesproken. In Word 2007 en later kan je math autocorrect aanzetten ook voor buiten formules, en dat heb ik dus altijd ingeschakeld. Dan schrijf je de mu met \mu, en de Ohm met \Omega.

Die met '&' kende ik nog niet, wel handig . Even proberen: Ω

[Ploink]

"option" toets Ik heb nog nooit OSX van dichtbij gezien, als ordinaire Windows gebruiker doe ik in text documenten hetzelfde als lordprimoz:P

Maar ik heb het even opgezocht voor windows:
Ω = alt-234 (alt indrukken en 234 typen op numerieke toetsenbord)
µ = alt-230

[RobV]

Via google, voor O
S X:

16 ∂ Option-D (Delta) )
17 ∆ Option-J (Delta)
18 µ Option-M (Mu)
19 π Option-P (phi)
20 ß Option-S (beta)
21 Ω Option-Z (Omega)
22 ∏ Option-Shift-P (pi)

Nu nogvoor iOS lol. Kunnen we daarna weer lekker back ontopic

[Pizza_Boom]

Ploink schreef op woensdag 01 april 2015 @ 08:43:
(0000 1010) = 10 (dec) = 0x0a (hex), dus niet 0x09, 1 er bij dus.
Om dit soort foutjes te voorkomen kun je denk ik beter direct "spi_send(0b00001010)" schrijven.

Ik verwacht dat dit eerder een slordigheidje met kopiëren ofzo is geweest, want in regel 146 zet ik hem naar 0x0B.

Als ik dat goed begrijp van je omschrijving dan is het dus correct, de mcu pin is input en de nrf pin output. Je hebt dus niet twee outputs die armpje drukken tegen elkaar of twee inputs.

Ik kan me ook niet voorstellen dat ik 2 outputs tegen elkaar op laat drukken, maargoed. Foutje is zo gemaakt.

Misschien is 10cm zo dichtbij dat ze doof worden van de herrie (preamp is overstuurd). Zet ze verder uit elkaar of reduceer het zendvermogen.

Ik heb het zendvermogen op 0dBm of -6dBm staan. Maar inmiddels extra draadjes ertussen gezet en nu staan ze een cm of 25-30 uit elkaar

Ik ga eerst eens kijken of ik die IRQ eruit krijg en gewoon de status kan gaan pollen.

EDIT: Ik krijg als data terug bij het lezen 0x00, behalve bij de 1e read command (0x61). Daar krijg ik niet 0x00, 0xFF en 0x12 (wat ik transmit) terug. Wat wel, ik zou het niet weten.

[ Voor 7% gewijzigd door Pizza_Boom op 01-04-2015 16:27 ]

[Pizza_Boom]

*schop* Momenteel de Logic Analyzer tool (ben opeens toch blij met die PICkit 2 en 3, 1 programmeren, ander de logic tool) eraan hangen:

Transmitter:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Begint met 0xA0 om TX FIFO te schrijven, daarna 4x 0x12. Wat ik terug zou moeten krijgen op MiSo weet ik niet, baart me nu ook geen zorgen.

Dan de receiver:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Stuur eerst de leesopdracht (0x61) en daarna 4x een dummybyte (0x01) om 4 bytes te ontvangen, gevolgd door een RX flush (0xE2), en een status register call (0x27) met opdracht de interrupt te legen (0x40). Echter, zoals te zien is, MiSo blijft een strakke lijn...

[ Voor 5% gewijzigd door Pizza_Boom op 14-04-2015 16:29 ]

[Springuin]

https://www.sparkfun.com/...ct_Specification_v1_0.pdf pagina 49. Je klok hoort laag te zijn in rust en de data dient stabiel te zijn op een opgaande flank, dat is bij jou precies andersom.

[Pizza_Boom]

Hmmm. Ik heb inderdaad in SSPSTAT gezegd dat ik in de falling edge stuur en in de SSPCON1 dat de clock hoog is in rust... Gaan we eens even aanpassen.

[Pizza_Boom]

Nogmaals, geen reactie van de NRF...

Transmitter:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Receiver:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Code staat nog steeds hier

[ Voor 3% gewijzigd door Pizza_Boom op 14-04-2015 18:01 ]

[Stoney3K]

Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

[Pizza_Boom]

Stoney3K schreef op dinsdag 14 april 2015 @ 22:27:
Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

Ik durf het niet te zeggen. Ik maak gebruik van de hardwarematige MSSP die in de PIC16F1459 zit en het stukje waar daadwerkelijk verzonden wordt is als volgt:

C:

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

Dit wordt aangeroepen door een stukje NRF send code waarin 5x deze routine wordt aangeroepen tussen de CSN low's. Het is dus niet dat ik het zelf loop te vertragen ofzo.

C:

unsigned char nrf_send(unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4)
    {
        CSN = laag;
        spi_send(0xA0);         // command to write TX FIFO
        spi_send(data1);        // send data1 to TX FIFO
        spi_send(data2);        // send data2 to TX FIFO
        spi_send(data3);        // send data3 to TX FIFO
        spi_send(data4);        // send data4 to TX FIFO
        CSN = hoog;
        __delay_us(1);


        CE = hoog;                  // make CE high to initiate data transmitting
        __delay_us(100);            // keep CE high for at least 10 uS to transmit data
        CE = laag;                  // make CE low again to stop transmitting
        __delay_us(1);
        
        return 0;
    }

[Stoney3K]

Dat lijkt er eerder op dat er bij dat 'aanroepen' van die functie dus nog wat meer gebeurt, wat een aantal klokcycli kost en waardoor dus dat gat in je kloksignaal ontstaat. Bijvoorbeeld het omzetten van een stack pointer.

Het lezen van dat SPI register en het verplaatsen van die data naar een variabele kost bijvoorbeeld ook tijd. Je doet niets met die data, dus die kun je prima ignoren, dan hoef je ook niet op de interrupt te wachten.

Als je het wil fixen kun je het beste die spi_send ombouwen zodat je er een blok bytes (een char * dus) in kan stoppen samen met een lengte, en de hele rataplan in een for() loopje gooien. Dan weet je zeker dat er niets tussenin gebeurt.

[Pizza_Boom]

Maar het zou toch eigenlijk niet mogen uitmaken dat er een hikje in de klok zit, dat ding telt niet zelf en zo lang CSN low is, moet het toch gewoon werken? Of geldt dat weer alleen voor i2c?

De data wil ik trouwens wel gebruiken bij de uitgave van data in geval van de receiverzijde.

Heb je een voorbeeldje van hoe je dat forloopje en char gebeuren bedoelt? In het schrijven van die dingen ben ik nooit heel goed geweest.

[Stoney3K]

Sim-pel: Je doet gewoon dit in plaats van een opvolgend aantal spi_send()'s te doen.

code:

void spi_send(unsigned char * data_tx, int length)
{
    int i;
    for(i=0; i < length; i++) 
    {
            SSP1IF  = 0;        // clear interrupt flag
            SSP1BUF = data_tx[i];    // send data
            while (!SSP1IF);        // wait till SSP interrupt flag is set and register is ready to accept new data
    }
}

In dit blok gebruik je de return-waarde van spi_send() toch niet, dus ik zou eens proberen of ie zo wel de juiste gegevens wegstuurt.

Vooral de instructie 'return' (ofwel: kopieer teruggegeven waarde naar callee en spring terug vanaf de stack) kost nogal wat tijd.

Als je dan ook nog data in wil lezen, zul je ook een array mee moeten sturen waar die data in terug moet. Daar help ik je wel mee.

[ Voor 4% gewijzigd door Stoney3K op 14-04-2015 22:57 . Reden: indent ]

[Pizza_Boom]

Hmm, dat accepteert ie niet. Deze code invoeren levert een berg errors op. Een aantal kan ik verklaren, dat komt omdat alles in de code nog gewoon met enkele SPI sends staat (to few function arguments), maar de illigal conversions of pointers to integers kan ik niet verklaren. DataS had ik al data_tx van gemaakt.

Dit was van voor je edit.
EDIT2: Ik krijg nog steeds 21 errors met to few function arguments en evenzoveel warnings met illegal conversions of integer to pointer...

[ Voor 21% gewijzigd door Pizza_Boom op 14-04-2015 23:19 ]

[DuDePrOdUcTiOnS]

Die 'too few arguments' is omdat je waarschijnlijk niet de lengte meestuurt bij het aanroepen van de functie (length variabele). De 'illegal conversions' is omdat de data_tx variabele een pointer is (staat een *sterretje voor) en je zelf bij het aanroepen van de functie waarschijnlijk gewoon een char of int meestuurt.

[Pizza_Boom]

Momenteel stuur ik volgens mij niets mee. Ik roep gewoon spi_send aan, dat staat in een grote config void. Als ik inderdaad een spi_send(0x00) verander naar spi_send(0x00, 1) dan verdwijnt de error. Echter, (0x00, 0x01, 2) accepteert ie weer niet, terwijl ik juist begrijp uit de reacties dat met deze forloop meerdere waardes achter elkaar doorgestuurd moeten kunnen worden. Doe ik 0x00[1], 0x01[2] dan krijg ik de error dat er een pointer required is.

[RobV]

De functie verwacht een pointer naar je data en de lengte van die data. Ipv de pointer geef je nu de data mee als argument, niet het adres.

[Pizza_Boom]

Hmmm, okee. En hoe maak ik die pointer naar mijn data dan?

[DuDePrOdUcTiOnS]

*data_tx moet je zien als een array van unsigned chars. Deze kun je vullen met data en met data_tx[i] kun je door de data heen stappen.

[Pizza_Boom]

Heb je daar een codevoorbeeldje van, hoe je dat precies bedoelt? Ik heb bij de I2C slave code wel gewerkt met een soort 1D array, maar ik heb geen idee hoe ik wat hier staat, moet gaan implementeren.

[Radiant]

Stoney3K schreef op dinsdag 14 april 2015 @ 22:27:
Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

Maakt niet uit. Het hele idee van die klok is juist dat je als master kan bepalen wanneer je bits verstuurt.
Sneller is altijd leuker maar die vertraging zal niet het probleem zijn.

Als je code gaat schrijven met interrupts in je master zal je helemaal zien dat je klok nooit helemaal mooi is.

[Stoney3K]

Pizza_Boom schreef op woensdag 15 april 2015 @ 16:00:
Heb je daar een codevoorbeeldje van, hoe je dat precies bedoelt? Ik heb bij de I2C slave code wel gewerkt met een soort 1D array, maar ik heb geen idee hoe ik wat hier staat, moet gaan implementeren.

Dan kun je het beste beginnen met te leren hoe arrays en pointers precies werken in C.

Die data_tx is een 'char *', dat betekent dat het geen byte (char) aan data is, maar het geheugenadres van die byte(s) aan data. En als je meer bytes wil sturen, dan zijn de geheugenadressen daarvan opeenvolgend.

Staat er bijvoorbeeld ergens een byte met gegevens '0xAA' op adres 252, dan werkt dat dus zo:

Waarde op adres 252 = data_tx[0] = 0xAA

De eerstvolgende waarde in zo'n 1-dimensionale array, data_tx[1], staat dan op adres 253, enzovoorts.

Dat maakt C heel krachtig maar (soms) ook heel smerig, omdat je met dat soort trucs gewoon buiten de grenzen van een array kan lezen schrijven waar zinnige data in zit. Dat is precies wat er bij de bekende Heartbleed-bug aan de hand was.

Wil je dus het stukje aan bytes sturen wat je in je originele programma gebruikt, dan kun je dat zo doen:

code:

char data[5];  /* Geeft aan dat er 5 bytes in deze array passen */

data[0] = 0xA0;
data[1] = data1;
data[2] = data2;
data[3] = data3;
data[4] = data4;

spi_send(data, 5);

Om 5 bytes aan data in één keer te versturen.

Radiant schreef op woensdag 15 april 2015 @ 16:27:
[...]


Maakt niet uit. Het hele idee van die klok is juist dat je als master kan bepalen wanneer je bits verstuurt.
Sneller is altijd leuker maar die vertraging zal niet het probleem zijn.

Als je code gaat schrijven met interrupts in je master zal je helemaal zien dat je klok nooit helemaal mooi is.

Het kan heel goed zijn dat sommige slave-devices kieskeurig zijn over het wel of niet hebben van een nette klok. Ik heb hier bijvoorbeeld een paar DAC's van Microchip en die houden het op een gegeven moment voor gezien als je klok te veel afwijkt tussen de bitjes.

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 15:41:
Hmmm, okee. En hoe maak ik die pointer naar mijn data dan?

Ik zal het even voor je googlen. Understanding pointers

Vooruit, ik heb een goede bui:

C:

//the
unsigned char *data_to_transmit = { 0xAA, 0xBB, 0xCC, 0xDD };
//je kunt het ook zo opschrijven (verschil is voor puristen)
unsigned char data_to_transmit[] = { 0xAA, 0xBB, 0xCC, 0xDD };

//functie aanroepen met array en de lengte
spi_send(data_to_transmit, 4);

//heb je geen buffer en hoef je echt maar 1 byte versturen:
unsigned char byte_to_transmit = 0xAA;
spi_send(&byte_to_transmit, 1);
//ofwel zonder tijdelijke variabele.
spi_send(&0xAA, 1);

//aangenomen dat je de functie gebruikt die er zó uit ziet:

C:

void spi_send(unsigned char * data_tx, int length)
{
   ...
}

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 16:35:
[...]


Ik zal het even voor je googlen. Understanding pointers

Doe het dan ook gelijk op de kortst mogelijke manier

C:

spi_send( {0xAA, data1, data2, data3, data4}, 5);

[Pizza_Boom]

Stoney3K schreef op woensdag 15 april 2015 @ 16:37:
[...]


Doe het dan ook gelijk op de kortst mogelijke manier

C:

spi_send( {0xAA, data1, data2, data3, data4}, 5);

Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Stoney3K schreef op woensdag 15 april 2015 @ 16:34:
[...]


Dan kun je het beste beginnen met te leren hoe arrays en pointers precies werken in C.

Die data_tx is een 'char *', dat betekent dat het geen byte (char) aan data is, maar het geheugenadres van die byte(s) aan data. En als je meer bytes wil sturen, dan zijn de geheugenadressen daarvan opeenvolgend.

Staat er bijvoorbeeld ergens een byte met gegevens '0xAA' op adres 252, dan werkt dat dus zo:

Waarde op adres 252 = data_tx\[0] = 0xAA

De eerstvolgende waarde in zo'n 1-dimensionale array, data_tx\[1], staat dan op adres 253, enzovoorts.

Dat maakt C heel krachtig maar (soms) ook heel smerig, omdat je met dat soort trucs gewoon buiten de grenzen van een array kan lezen schrijven waar zinnige data in zit. Dat is precies wat er bij de bekende Heartbleed-bug aan de hand was.

Op zo'n soort manier, maar dan precies tegengesteld, heb ik het ook al eens gebruikt bij het binnenhalen van informatie in een slave op een I2C bus. Zodat dus iedere binnenkomende byte op een apart adresje werd weggeschreven.

Wil je dus het stukje aan bytes sturen wat je in je originele programma gebruikt, dan kun je dat zo doen:

code:

char data[5];  /* Geeft aan dat er 5 bytes in deze array passen */

data[0] = 0xA0;
data[1] = data1;
data[2] = data2;
data[3] = data3;
data[4] = data4;

spi_send(data, 5);

Om 5 bytes aan data in één keer te versturen.

Die gaan we nog eens proberen. Maar bij de configs moet ik dat dus bij iedere configuratie die ik doorstuur doen, lijkt mij?

Het kan heel goed zijn dat sommige slave-devices kieskeurig zijn over het wel of niet hebben van een nette klok. Ik heb hier bijvoorbeeld een paar DAC's van Microchip en die houden het op een gegeven moment voor gezien als je klok te veel afwijkt tussen de bitjes.

Zou dat met NRF24L01's ook zo zijn?

[ Voor 8% gewijzigd door Pizza_Boom op 15-04-2015 17:39 ]

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Als je er '//' voor zet, zijn ook de warning weg ... Zodra je begrijpt hoe het werkt, mag je van mij de bocht afsnijden. Tot die tijd gewoon eventjes een buffertje gebruiken kijkt me handiger nu. En zoals gezegd: lees even een basic C tutorial over arrays en pointers. Het is al zo vaak uitgelegd...

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 18:10:
[...]

Als je er '//' voor zet, zijn ook de warning weg ... Zodra je begrijpt hoe het werkt, mag je van mij de bocht afsnijden. Tot die tijd gewoon eventjes een buffertje gebruiken kijkt me handiger nu. En zoals gezegd: lees even een basic C tutorial over arrays en pointers. Het is al zo vaak uitgelegd...

"0xAA, data1, data2, data3, data4" is trouwens iets heel anders dan de array die bestaat uit 0xAA (hexadecimaal) en de inhoud van data 1 t/m 4.

Wat je er dan wel in stopt laat ik aan jou als huiswerk.

[RobV]

Stoney3K schreef op woensdag 15 april 2015 @ 18:43:
[...]


"0xAA, data1, data2, data3, data4" is trouwens iets heel anders dan de array die bestaat uit 0xAA (hexadecimaal) en de inhoud van data 1 t/m 4.

Wat je er dan wel in stopt laat ik aan jou als huiswerk.

Ik ben even de weg kwijt waarom je je eigen code quote als reactie op mijn bericht.. Laten we het niet ingewikkelder maken dan dat het is en verder gaan. We wachten af waar Pizza_Boom mee terugkomt als hij zich even ingelezen heeft in de materie.

[ Voor 4% gewijzigd door RobV op 15-04-2015 18:53 ]

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 18:51:
[...]

Ik ben even de weg kwijt waarom je je eigen code quote als reactie op mijn bericht.. Laten we het niet ingewikkelder maken dan dat het is en verder gaan. We wachten af waar Pizza_Boom mee terugkomt als hij zich even ingelezen heeft in de materie.

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Opdracht aan Pizza_Boom dan: Leg eens uit waarom

code:

char * data_send = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE }

iets anders is dan

code:

char * data_send = "0xAA, 0xBB, 0xCC, 0xDD, 0xEE"

Hint: één van de twee is 5 bytes lang, de ander niet.

[RobV]

mooi klusje huiswerk inderdaad.

edit: je vergeet in beide gevallen een ;

[ Voor 37% gewijzigd door RobV op 15-04-2015 21:39 ]

[Ploink]

Ik denk dat die syntax highlighting op zich al een duidelijke hint is, of verklap ik nou teveel?

[Stoney3K]

Ploink schreef op woensdag 15 april 2015 @ 20:54:
Ik denk dat die syntax highlighting op zich al een duidelijke hint is, of verklap ik nou teveel?

sst, straks heeft ie het nog te snel door...

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.
[...]

ik vroeg me af, of je inmiddels het verschil weet tussen char, char *, char [], en het verschil tussen 'x' en "x".

[Pizza_Boom]

Eigenlijk helemaal niet meer mee bezig geweest.

[Anthor]

Ik ben atm weer bezig met wat programmeren in AtmelStudio 6 (sp2),
en ik zit me weer onwijs te ergeren aan de vertraging/lag die ik soms in de editor heb.

Hebben jullie dat ook, of is er gewoon iets mis met mijn pc?
(proc uit 2009 en 12 GB ram moet genoeg zijn toch )

[mad_max234]

Anthor schreef op dinsdag 05 mei 2015 @ 16:41:
Ik ben atm weer bezig met wat programmeren in AtmelStudio 6 (sp2),
en ik zit me weer onwijs te ergeren aan de vertraging/lag die ik soms in de editor heb.

Hebben jullie dat ook, of is er gewoon iets mis met mijn pc?
(proc uit 2009 en 12 GB ram moet genoeg zijn toch )

Ja dat heb/had ik ook, vanaf Studio 5 is dat ontstaan toen ze er MS studio bij hebben gehaald, zeer traag met opstarten, had 4GB en ahtlon M320 (2.1GHz athlon II zeg maar). Heb vorige maand nieuwe pc gekocht met broadwell i5-5200 en is stukje minder geworden. Maar zag verder nooit dat cpu, HDD of ram zwaar werd belast in de opstarttijd. Studio 4 was reten snel, de starten snel op, sneller reactie van alle onderdelen.

[joelluijmes]

Je kunt op de avr (althans de ATmega328P) een truukje gebruiken waardoor je snel een output pin kunt toggelen (zelfde als output xor). Weet iemand nog meer van dit soort kleine dingetjes voor de avr?

Voor wie er niet mee bekent is:

Writing a logic one to PINxn toggles the value of PORTxn, independent on the value of DDRxn. Note that the
SBI instruction can be used to toggle one single bit in a port.

code:

PINB = 0x20;    //ldi r24, 0x20
                //out 0x03, r24

//--------------------------------

PORTB ^= 0x20;  //in r24, 0x05
                //ld r25, 0x20
                //eor r24, 25
                //out 0x05, r24

[Ploink]

joelluijmes schreef op zondag 31 mei 2015 @ 00:20:
Weet iemand nog meer van dit soort kleine dingetjes voor de avr?

Dat is idd een handig truukje.
Voor wat betreft programmeren kwam ik dit tegen:

Creating ELF Files with other memory types
Hiermee kan je oa fuses en eeprom data in je sourcecode zetten.

6.53 Built-in Functions to Perform Arithmetic with Overflow Checking
Eindelijk een methode om snel een integer overflow te detecteren! Helaas zit dit pas in GCC 5 en die zit nog niet in atmel studio. Nog even wachten dus tot dit beschikbaar komt.

[DaWaN]

Even dit oude topic eens een schop geven.

Ik was vandaag bezig met een Cambridge Consultants XAP5 en daar zag ik enigzins onverwacht gedrag met shifts. Ik vraag mij af of dit klopt of dat het een compiler quirk was.

Ik had de volgende code waarin ik twee Uint8's bitwise in een Int32 wilde zetten:

code:

Int32 OutputLong = 0;
Uint8 InputChar1 = 0xAA;
Uint8 InputChar2 = 0xBB;
OutputLong |= ((InputChar1<<8)|(inputChar2));

Nu gaf deze code als output OutputLong 0xFFFFAABB terwijl ik 0x0000AABB had verwacht.

code:

Int32 OutputLong = 0;
Uint8 InputChar1 = 0xAA;
Uint8 InputChar2 = 0xBB;
OutputLong |= ((InputChar1<<8)|(inputChar2)) & 0x0000FFFF;

Deze code gaf wel wat ik verwacht had (namelijk 0x0000AABB), maar het ontgaat mij even waarom ik die extra bitwise AND operatie moest toevoegen. Iemand een idee?

[RobV]

Ik ben benieuwd wat eruit zou komen als je van de Int32 een UInt32 maakt?

[Hans1990]

Als ik jouw code in GCC 4.8.4 (x86 ubuntu 14.04) stop met stdint.h types krijg ik 0x0000AABB.
Architectuur afhankelijk? Compiler bug? XAP5 platform zegt me weinig, wikipedia zegt dat aangepaste GCC veel gebruikt wordt.

Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit. Maar ik weet niet of dat het probleem is.
Misschien idd unsigned/signed probleem, maar dat blijft vreemd voor een OR operatie.

edit:
OT: Mag wel eens wat doen aan zinopbouw als ik moe ben

[ Voor 9% gewijzigd door Hans1990 op 31-05-2016 20:50 ]

[RobV]

Hans1990 schreef op dinsdag 31 mei 2016 @ 20:33:


Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit.

Ja, daar ben ik het mee eens.

[mux]

Vrijwel gegarandeerd wordt op de achtergrond die InputChar1 ergens in geheugen voorbereid (kun je dit in je disassembly/map file zien?). Wellicht een compilerbug dat die niet wordt geïnitialiseerd op 0, want flash is doorgaans inderdaad ongeprogrammeerd 0xFF.

(edit: de enige keer dat ik een vergelijkbaar probleem ben tegengekomen was met een brakke UC3-lib voor EEPROM)

[ Voor 18% gewijzigd door mux op 31-05-2016 21:03 ]

[Sissors]

Het zit natuurlijk wel in SRAM. Granted wordt vanuit flash gekopieerd, maar dan nog steeds lijkt me dat onwaarschijnlijk. Mijn gok is dat er een foutieve unsigned -> signed conversie plaatsvindt van de uint8's, wat vervolgens naar 32-bit wordt geconverteerd.

[jeroen3]

Ik denk dat het gehele voorbeeld in de registers past.
Wat zegt de disassembler?

[DaWaN]

Hans1990 schreef op dinsdag 31 mei 2016 @ 20:33:
Als ik jouw code in GCC 4.8.4 (x86 ubuntu 14.04) stop met stdint.h types krijg ik 0x0000AABB.
Architectuur afhankelijk? Compiler bug? XAP5 platform zegt me weinig, wikipedia zegt dat aangepaste GCC veel gebruikt wordt.

Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit. Maar ik weet niet of dat het probleem is.
Misschien idd unsigned/signed probleem, maar dat blijft vreemd voor een OR operatie.

edit:
OT: Mag wel eens wat doen aan zinopbouw als ik moe ben

Ja mijn vermoeden is dat het ook iets met signed/unsigned te maken heeft. Ik heb ook even de code gereduceerd tot waar de 'fout' zat. Code zit in een device driver die 24 bits signed getallen uitspuugt. Om het mijzelf wat makkelijker te maken stop ik die maar in Int32's zodat ik de compiler alle berekeningen kan laten afhandelen. Grappig genoeg lost het casten van de UInt8's naar Int32's niets op en vreemd genoeg ook geen warning over de shift m.b.t. het promoten van het type.

Ik ben de laatste tijd niet zo extreem bedreven in het schrijven van C en de omgeving waarin ik werk helpt ook niet echt. Is een enorme batterij aan Python scripts waar uiteindelijk een binary uit komt rollen. Heb nu even geen zin om uit te zoeken hoe ik die build kan exporteren naar de IDE om wat beter te kunnen debuggen. Ik zal na de SW release wel even kijken of ik ook leesbare assembly eruit kan krijgen om te begrijpen wat de compiler nu precies doet, ik kom er op terug! Ben i.i.g. blij dat het geen obvious fout was en dat het uurtje dat het mij kostte om het te vinden dus niet heel dom was

Chip is overigens een GreenPeak GP691, met een vrij exotische XAP5 MCU. Is dezelfde MCU core die je in chips van CSR vind en hij heeft inderdaad een GCC gebaseerde compiler.

[Hans1990]

Als het GCC is kan je objdump op de elf of out toepassen samen met flags -D en -S. Dat disassembled alle sections en zal (indien het de source kan vinden) source code er tussen plaatsen.
Je zou dan eens kunnen redeneren wat de assembler code doet. Echter een debugger kan hier ook bij helpen, met name als je IDE kan single steppen op assembler (ipv C) niveau.

[Anthor]

Ik ben een speelgoed zwaardje aan het repareren voor het zoontje van vrienden. Er zaten wat ledjes in maar die kon ik niet redden. Nu heb ik er wat eigen electronica met een paar rgb-ledjes in gestopt en daarvoor heb ik heb een soort pseudo random getal nodig.

Op de uC (attiny44) draait snel gehackte software die ik origineel voor een ander project heb geschreven, en die nu nog maar gedeeltelijk werkt .

De uC krijgt pas stroom als er op een knopje gedrukt wordt, dan moet er één van de lichteffecten gespeeld worden die ik kan voorprogrammeren, maar dan heb ik een soort random nummer nodig (3 á 4 bits zal wel genoeg zijn), of iig iets wat wisselt als de spanning er even af is geweest. In het zwaardje zit ook nog een audio chip die iets speelt als het knopje wordt ingedrukt.
Er zit een condensatortje bij de uC, maar de batterij spanning is weg zodra de knop losgelaten wordt

De uC hangt met alle IO pinnen (ook reset als ik die uiteindelijk disable ipv gebruik voor dW ) aan ULN 2803 ingangen, dus alle ingangen worden omlaag getrokken. Dus ik kan daar niet zomaar iets uitlezen. of een adc doen

Ik kan misschien iets in de eeprom zetten, uitlezen en gewijzigd terugschrijven als de uC spanning krijgt, maar dan kan de spanning ook wegvallen tijdens een write. Wat gebeurt er met het eeprom geheugen wat dan beschreven wordt? Is de data dan gewoon weg of kan het geheugen op een of andere manier beschadigen zodat daarna altijd dezelfde byte terug komt?
Of is er een andere makkelijke manier om een random waarde ergens uit te halen?

[RobV]

Lees een niet verbonden analoge pin uit, en pak alleen de onderste 6 bits of zo, dat is redelijk random. Wellicht kun je die als seed gebruiken. Maar ik denk dat je met je attiny geef vrije pinnen meer hebt?

[ Voor 23% gewijzigd door RobV op 03-06-2016 19:28 ]

[Anthor]

Nee, alles is bezet. Ik moet om alle leds aan te kunnen sturen ook de reset pin en dus de mogelijkheid om dat ding later makkelijk te programmeren opofferen. Het is een smd ic op een gebeund stukje stripboard waar al te veel aan gesoldeerd is.

[RobV]

Met juist gebruik van diodes kun je een output pin ook als input pin gebruiken tijdens het opstarten. Ik denk ook maar hardop ik weet het antwoord zo niet uit het hoofd

[Anthor]

Hier is een foto van het bordje (geen schoonheidsprijs):


Helaas zitten alle analoge ingangen tussen de twee linker ic's op hetzelfde pad, zo'n draadje tussen de twee delen had ik wat makkelijker kunnen vervangen.

nee, dat rode draadje hoort niet los te zitten en die grijze linksboven ook niet

[mux]

Het antwoord is: gebruik de ADC, maar dan met een interne input ipv een externe pin

Op de tinyx4(A) zit een interne temperatuursensor, die je aan de ADC kunt gooien. pagina 144.

Alternatief kun je intgnd, 1V reference of een 20x gain op een externe input die altijd laag is gebruiken.

[Hans1990]

Anthor schreef op vrijdag 03 juni 2016 @ 19:24:
Ik kan misschien iets in de eeprom zetten, uitlezen en gewijzigd terugschrijven als de uC spanning krijgt, maar dan kan de spanning ook wegvallen tijdens een write. Wat gebeurt er met het eeprom geheugen wat dan beschreven wordt? Is de data dan gewoon weg of kan het geheugen op een of andere manier beschadigen zodat daarna altijd dezelfde byte terug komt?
Of is er een andere makkelijke manier om een random waarde ergens uit te halen?

Zelfs als de knop kort wordt ingedrukt zal dat toch wel een tiende van een seconde zijn?

Je zou dan je random number kunnen berekenen met EEPROM als seed, en vervolgens de nieuwe seed naar EEPROM wegschrijven.
Volgens de datasheet kost "erase and write" (atomic operation) circa 3.4ms. Dat zou kort genoeg moeten zijn lijkt me.
Zo niet verwacht ik dat het EEPROM ge-erased is en je dus met een nieuwe reeks begint. Wil je dat afvangen is lastig, zou je dan met brown-out detect moeten gebruiken (heeft die ATTINY al wel zie ik) en voldoende capaciteit op uC voeding om exact 1 write te kunnen voltooien. Maar ik zou eerlijk gezegd niet weten waarom je dat zou willen voor een stukje speelgoed
Je hebt dan enkel een psuedo-random number generator nodig, een paar bits (of als we toch bezig zijn 8-bit) brede linear feedback shift register ofzo.

[ Voor 21% gewijzigd door Hans1990 op 03-06-2016 21:01 ]

[Digital-DNA]

Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

[DuDePrOdUcTiOnS]

Voor het random nummer genereren kun je ook de tijdsduur van het indrukken van de knop gebruiken. Gewoon ticks tellen tot de knop losgelaten wordt.

[Springuin]

Digital-dna: ik zie op de foto die pic18f niet zitten, het lijkt puur een breakout board voor die module.

Als je iets eenvoudigs wilt voor bluetooth low energy kan ik je de modules/chips van cypress aanraden: fijne ontwikkelomgeving, goede voorbeelden en goede support. Daarnaast hebben die een cortex-m0 core en, mits je ze goed programmeert, laag energieverbruik.

[Damic]

Digital-DNA schreef op vrijdag 03 juni 2016 @ 23:35:
Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

Zoals Springuin al zei, het is een breakout bord ook in de RN4020 PICtail Plus Daughter Board Quick Start Guide staat dat:

The RN4020 PICtail Plus Daughter Board has PICtail Plus and PICtail connectors to interface with a PIC® microcontroller (MCU) on the development boards that
support PICtail Plus or PICtail interface with the required pin mapping.

[Digital-DNA]

Dat ding heeft twee opties geloof ik. Ik lees ook dat er een usb-kabel meegeleverd wordt en je 'm direct aan je pc kan hangen en 'ie als com-poort wordt herkend als je de USB-to-UART bridge mode gebruikt. Begrijp ik hieruit dat je 'm dan wel los kan gebruiken of hoe moet ik dit zien?

[Springuin]

Je hebt gelijk, er zit meer op dan ik dacht te zien, dat zal wel aan de achterkant zitten. Ik denk dat die pic18f in principe als usb uart bridge geprogrammeerd is zodat je direct met de module kunt praten. Dat betekent dat je genoeg hebt om van start te kunnen.

[Verwijderd]

mogguh,

iemand al is een NINA-B1 is zijn handen gehad ?

Ik zoek eigenlijk iets met een paar gpio, i2c, ble functionaliteit en min 2 uarts, rekenpower/mem is niet echt super belangrijk.
ik dacht aan een featherbordje omdat ik dan gelijk aan de slag kan.

Maar ik zie hier allerlei andere chips voorbij komen, die ontwikkelomgevingen die er dan bijbehoren, zijn die dan ook gratis, zoals arduino IDE zeg maar ?

[ Voor 9% gewijzigd door Verwijderd op 04-06-2016 11:02 ]

[Radiant]

Al eens naar de Nordic nRF-serie gekeken? Zijn leuke bordjes voor beschikbaar, is een rappe Cortex M0-processor die een softstack draait voor de BLE. Verder allerlei peripherals beschikbaar.

Goeie ervaringen mee

[Verwijderd]

ah ok tnx, ja toevallig was ik de 51822 tegengekomen

[1337aldi]

Digital-DNA schreef op zaterdag 04 juni 2016 @ 09:05:
Dat ding heeft twee opties geloof ik. Ik lees ook dat er een usb-kabel meegeleverd wordt en je 'm direct aan je pc kan hangen en 'ie als com-poort wordt herkend als je de USB-to-UART bridge mode gebruikt. Begrijp ik hieruit dat je 'm dan wel los kan gebruiken of hoe moet ik dit zien?

Je kan direct met de module praten met de standaard firmware. Als je echter die PIC18 wilt herprogrammeren/debuggen heb je een PICKIT3 of ICD3 nodig. Van de pickit3 zijn ook chinese kloons beschikbaar die het prima doen.

[Verwijderd]

1337aldi schreef op zaterdag 04 juni 2016 @ 13:50:
[...]

Van de pickit3 zijn ook chinese kloons beschikbaar die het prima doen.

klopt, ik heb zelf deze chinees

[itcouldbeanyone]

Digital-DNA schreef op vrijdag 03 juni 2016 @ 23:35:
Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

Ben er nu ook mee bezig. Heb de rn4020 als smd moddule in gebruik in MLDP modus.
Heb zeer goede commenucatie doormiddel van mldp browser app. Ben nu nog bezig om dit in mijn eigen app te implementeren

[Sissors]

Radiant schreef op zaterdag 04 juni 2016 @ 11:05:
Al eens naar de Nordic nRF-serie gekeken? Zijn leuke bordjes voor beschikbaar, is een rappe Cortex M0-processor die een softstack draait voor de BLE. Verder allerlei peripherals beschikbaar.

Goeie ervaringen mee

De NRF51822 is een goede optie zoals hij het beschrijft wat hij nodig heeft, maar hem rap noemen gaat me wel een beetje ver . Hij is veruit de traagste ARM MCU die ik ken met zijn M0 op 16MHz, eerstvolgende is 30MHz (die ik dus ken uit mijn hoofd).

Er is ook geloof ik een M4 versie van beschikbaar, al is die iig een stuk minder beschikbaar op allerlei dev bordjes.

Edit: Oh al weer wat dagen geleden, ach ja.

[ Voor 3% gewijzigd door Sissors op 09-06-2016 22:17 ]

[DuDePrOdUcTiOnS]

Sissors schreef op donderdag 09 juni 2016 @ 22:17:
[...]

De NRF51822 is een goede optie zoals hij het beschrijft wat hij nodig heeft, maar hem rap noemen gaat me wel een beetje ver . Hij is veruit de traagste ARM MCU die ik ken met zijn M0 op 16MHz, eerstvolgende is 30MHz (die ik dus ken uit mijn hoofd).

Er is ook geloof ik een M4 versie van beschikbaar, al is die iig een stuk minder beschikbaar op allerlei dev bordjes.

Edit: Oh al weer wat dagen geleden, ach ja.

De nRF52832 heeft een M4 core op 64MHz.

[Digital-DNA]

itcouldbeanyone schreef op donderdag 09 juni 2016 @ 19:32:
[...]


Ben er nu ook mee bezig. Heb de rn4020 als smd moddule in gebruik in MLDP modus.
Heb zeer goede commenucatie doormiddel van mldp browser app. Ben nu nog bezig om dit in mijn eigen app te implementeren

Ik wil eigenlijk een custom GATT profiel gaan draaien en mijn app daar gebruik van laten maken. Eigenlijk een soort aangepaste hartslagmeter maar dan net anders. MLDP is voor mijn toepassing niet geschikt denk ik.

Ik zie dat je via een soort command line commando's kan sturen. Ik vraag me meer af hoe je echt een programmaatje kunt maken die je bijvoorbeeld direct laat zien als een apparaat verbinding maakt bijvoorbeeld, en via waar je het sturen van notificaties kunt regelen enzo. Ik lees iets over MLAP Code Configurator, is dat een tool die je hiervoor kunt gebruiken?

Ik heb nog niet echt ervaring met dit soort dingen.

[Verwijderd]

DuDePrOdUcTiOnS schreef op vrijdag 10 juni 2016 @ 09:25:
[...]

De nRF52832 heeft een M4 core op 64MHz.

kwam vandaag een nieuwe Arduino (primo) tegen waar die chip op zit
- http://www.pcworld.com/ar...ngs-with-primo-board.html

[itcouldbeanyone]

Digital-DNA schreef op zondag 12 juni 2016 @ 22:54:
[...]


Ik wil eigenlijk een custom GATT profiel gaan draaien en mijn app daar gebruik van laten maken. Eigenlijk een soort aangepaste hartslagmeter maar dan net anders. MLDP is voor mijn toepassing niet geschikt denk ik.

Ik zie dat je via een soort command line commando's kan sturen. Ik vraag me meer af hoe je echt een programmaatje kunt maken die je bijvoorbeeld direct laat zien als een apparaat verbinding maakt bijvoorbeeld, en via waar je het sturen van notificaties kunt regelen enzo. Ik lees iets over MLAP Code Configurator, is dat een tool die je hiervoor kunt gebruiken?

Ik heb nog niet echt ervaring met dit soort dingen.

Ik ben het ook nog allemaal aan het uitzoeken.
Heb standaard de mldp pun op hoog staan. Net als hw en sw boot pin.

Zodra de moddule aan gaat kun je dan in je command simpel via uart commandos opgeven, zo stel je de naam in. Private serivices enz.
Ik stel zelf enkel de naam in. Fabrieks naam. En serie nummer. Waarna ik het commando geef om in mldp modus te gaan.

Zodra die modus geactiveert is wordt alle data over de uart verstuurt. En dat is aan de microcontrollet kant ideaal om te programeren. Zeker waneer je toegang moet hebbe. Tot groote hoeveelheid data op je microcontroller.

Nu werkt bij mij dit via de mldp app browser app van microchip.
Nu ben ik bezig om de source code van die app te intregeren in een app die ik zelf geschreven heb in processing.org.
Dit valt me best tegen omdat ik geen kanjer ben in android en java.


Bedoel je kwa notificaties advertising?

Je command line is het uart sigaal

[Pizza_Boom]

*schopje*

Meer dan een jaar geleden dat ik hier voor het laatst gepost heb en buiten een schopje in de kroeg überhaupt lang geleden dat ik hier ben geweest. Afijn, back to basic, PICkit2 met een 16f690. Waarom? Omdat ik er nog zat heb liggen en niet echt heel ingewikkeld hoef te doen. Ik wil een servotje laten draaien, maar de PWM generator is te klein daarvoor, die kan de puls niet lang genoeg maken. De SG-90 heeft een puls van 500 tot 2400 uS nodig.

An sich lukt het programma redelijk, ik krijg de puls, de Servo vibreert niet na en wordt niet warm, dus de uitgang float niet. Echter, de puls laat zich niet mooi sturen. Normaal kan je de servo in 170-180 stappen laten draaien, ik kom tot 9 stappen van ca. 15-20 graden. Beetje te weinig dus voor een mooie werking. Ik moet dus ergens iets fout doen, maar wat?

Iemand die zin heeft om even te kijken?

C:

/*

             ________  _______
        VDD |        \/       | VSS
        RA5 |       16F690    | RA0 POT-meter
        RA4 |                 | RA1 POT-meter (ext)
Button  RA3 |                 | RA2 POT-meter (ext)
LED5e   RC5 |                 | RC0 LED0
LED4e   RC4 |                 | RC1 LED1
LED3    RC3 |                 | RC2 LED2
        RC6 |                 | RB4
        RC7 |                 | RB5
        RB7 |_________________| RB6

*/

 #include   <htc.h>

__CONFIG(FCMEN_OFF & IESO_OFF & BOREN_OFF & CP_OFF &  PWRTE_OFF & WDTE_OFF & MCLRE_OFF & FOSC_INTRCIO);

#define FOSC 8000000L

int potmeter, led;
int signaal = 125;
int stand = 10;
int i;



void delay(long i)                      // declareert de delay functie
{
    while (i--);
}

void interrupt
isr()
    {
        if(T0IF == 1)
            {
                i++;
                if(i == 21)
                    {
                        RC2 = 1;
                    //  i = 0;
                    }
                else if (i >= 28)
                    {
                        RC2 = 0;
                        i = 0;
                    }
                T0IF = 0;
            }
    }
            

/*
void PWM(void){                     // declareert de PWM functie
//      signal();
        servo();
        delay(5000);
        GO_nDONE = 1;
        while (GO_nDONE == 1);
        CCPR1L = signaal;               // bepaalt PWM hoogte aan de hand van potmeter
}
*/
void main(void)                         // hoofdprogramma
{ 

    PORTC   = 0;
    TRISC   = 0;
    PORTB   = 0;
    TRISB   = 0;
    PORTA   = 1;
    TRISA   = 1;
    ANSEL   = 0x01;         // RA0
//  ANSEL   = 0x02;         // RA1
//  ANSEL   = 0x04;         // RA2
//  EECON1  = 0b01;
    ANSELH  = 0;
    ADCON0  = 0x01;         // RA0 left justified
//  ADCON0  = 0x85;         // RA1 left justified: 0x05, RJ: 0x85
//  ADCON0  = 0x09;         // RA2 left justified

    OSCCON  = 0b01110101;   // kloksnelheid 8 mhz
    ADCON1  = 0b00110000;   // A/D clock = FRC (8 MHz)  
//  ADCON1  = 0b00000000;
    OPTION_REG  = 0b10000000;   // Prescaler 1:2
    TMR0    = 24;           // interrupt supposed to be 0,1 ms
    T0IE    = 1;            // enable timer0 interrupt flag
    GIE     = 1;            // general interrupt enabled
    PEIE    = 1;            // pherriperal interrupt enable

//  CCP1CON = 0x0C;         // 00001100
//  T2CON   = 0x06;         // 00000101
    
//  INTCON = 0b10

    while(1)
        {
        }       
}

[Verwijderd]

Leuk topic ! Ik kom het net tegen, heeft het nog zin om een STK500 te kopen via marktplaats voor 40 euro ? Ik wil hem via een RS232 naar USB adapter op mijn laptop gebruiken. Ik vind het heel jammer dat ik zo een ding al jaren geleden niet heb gekocht en elke keer zelf zitten prutten met pcb's of andere adapters.

[Rowwan]

Ik ken jou jouw controller niet goed genoeg om de code volledig te begrijpen, maar ik zie in het commentaar en interrupt van 0.1 ms. De meeste servos, en ook de sg-90, willen een periode van 20, en een variabele duty cycle tussen 1 en 2 ms.
Een duty cycle van 1.5 ms is daarbij de middenstand. 1 en 2 ms zijn de 90 graden hoeken.

Met jouw interrupt van 0.1 ms, kom ik hooguit uit 10 stappen, maar volgens mij klopt er meer niet aan je logica

[Sissors]

Ik ben niet bekend met PICs, maar Atmegas kunnen nog een clock divide by 8 op hun hoofdklok zetten. Oftewel is er een mogelijkheid hem een frequentie van 4MHz te geven? Dan kan je gewoon PWM gebruiken. (Verbaasd me een beetje overigens dat hun PWM geen servos aan kan bij standaard frequentie).

[Hans1990]

Voor servo's is hardware PWM bij uitstek ideaal.

Eigenlijk maar heel weinig servo's aangestuurd, maar dit zegt wikipedia er van:
https://en.wikipedia.org/...s_controle_servomotor.JPG

Heb je een scoop? Ik zou eens goed de waarden van je timer nameten, want volgens mij krijg je nu geen 0.1ms (10kHz) interrupt frequentie.
Daarnaast als je 170-180 stappen wilt hebben op een bereik van 500us, heb je een veels te hoge interrupt frequentie nodig op deze manier.