Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPI support? #50

Closed
roger- opened this Issue Dec 25, 2014 · 50 comments

Comments

Projects
None yet
@roger-
Copy link

roger- commented Dec 25, 2014

I see lots of references to this in the C headers, but is SPI support exposed in Lua?

@ghost

This comment has been minimized.

Copy link
Collaborator

ghost commented Dec 26, 2014

not yet. plan to support spi.

@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Jan 10, 2015

I'm working on an SPI module, managed to hack all the files needed to add the module, will send a PR when it's done.

@ghost

This comment has been minimized.

Copy link
Collaborator

ghost commented Jan 10, 2015

hi,
a little busy recently.
add a module for nodemcu, only need to add something in modules/auxmods.h, modules/modules.h
and add a LUA_USE_MODULES_SPI to user_config.h.

and, before you start, please check this out:
https://github.com/elua/elua/blob/master/src/modules/spi.c
better to make api call same. thanks very much

@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Jan 10, 2015

Will do, thanks!

@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Jan 11, 2015

Okay I got it working, initially, master mode only and I can't read yet (no master read function), but writing data looks good.. The pinout is wrong btw (or maybe it's the IO mux ?) anyway this is the current pinout:
CS -> IO15
MOSI -> IO13
MISO -> IO12
CK -> IO14

screenshot-1

iabdalkader added a commit to iabdalkader/nodemcu-firmware that referenced this issue Jan 16, 2015

Add SPI Module
* Add SPI support (master mode only)
* Issue nodemcu#50
@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Jan 16, 2015

The API is not exactly the same, but I can change it if you like, also CS could be controlled with GPIO does it need spi_select ?

@pipi61

This comment has been minimized.

Copy link

pipi61 commented Jan 22, 2015

Hi!
Spi example code available?
In wiki not found the spi and other new function documentation also

@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Jan 22, 2015

spi.setup(1, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, spi.DATABITS_8, 0);
spi.send(1, ...)
spi.recv(1, bytes)

Only master mode is supported, cpol/cpha low and 8 bits, clock doesn't change either.

@joaodh92

This comment has been minimized.

Copy link

joaodh92 commented Jan 28, 2015

Whats is the Gpio for HSPI? i dont know what gpio use to MOSI when the esp is the master.

@vowstar

This comment has been minimized.

Copy link
Member

vowstar commented Jan 30, 2015

@nodemcu nodemcu closed this Feb 11, 2015

@BobStevens

This comment has been minimized.

Copy link

BobStevens commented Feb 17, 2015

Controlling the SPI clock polarity would be useful. Where did you find documentation describing SPI_CK_OUT_HIGH_MODE and SPI_CK_OUT_LOW_MODE registers?

@iabdalkader

This comment has been minimized.

Copy link
Contributor

iabdalkader commented Feb 17, 2015

I didn't, I'm just guessing that those change the polarity, but they don't work, the phase regs work though.

@squix78

This comment has been minimized.

Copy link

squix78 commented Feb 24, 2015

I tried to port this code here to NodeMCU LUA: http://www.gammon.com.au/forum/?id=11516
to address a MAX7219 with a 8x8 LED Matrix:

MAX7219_REG_NOOP        = 0x00;
MAX7219_REG_DIGIT0      = 0x01;
MAX7219_REG_DIGIT1      = 0x02;
MAX7219_REG_DIGIT2      = 0x03;
MAX7219_REG_DIGIT3      = 0x04;
MAX7219_REG_DIGIT4      = 0x05;
MAX7219_REG_DIGIT5      = 0x06;
MAX7219_REG_DIGIT6      = 0x07;
MAX7219_REG_DIGIT7      = 0x08;
MAX7219_REG_DECODEMODE  = 0x09;
MAX7219_REG_INTENSITY   = 0x0A;
MAX7219_REG_SCANLIMIT   = 0x0B;
MAX7219_REG_SHUTDOWN    = 0x0C;
MAX7219_REG_DISPLAYTEST = 0x0F;


function sendByte (reg, data)    
  spi.send(1,reg, data)
  tmr.delay(50)
end

function setup ()
  spi.setup(1, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, spi.DATABITS_16, 0);
  sendByte (MAX7219_REG_SCANLIMIT, 7);      --show all 7 digits
  sendByte (MAX7219_REG_DECODEMODE, 0x00);  --use bit patterns
  sendByte (MAX7219_REG_DISPLAYTEST, 0);    --no display test
  sendByte (MAX7219_REG_INTENSITY, 15);      --character intensity: range: 0 to 15
  sendByte (MAX7219_REG_SHUTDOWN, 1);       --not in shutdown mode (ie. start it up)
end 

setup()

for i=1,8 do
     sendByte(i,0);
end

sendByte(MAX7219_REG_DIGIT0,1);
sendByte(MAX7219_REG_DIGIT1,2);
sendByte(MAX7219_REG_DIGIT2,4);
sendByte(MAX7219_REG_DIGIT3,8);
sendByte(MAX7219_REG_DIGIT4,16);
sendByte(MAX7219_REG_DIGIT5,32);
sendByte(MAX7219_REG_DIGIT6,64);
sendByte(MAX7219_REG_DIGIT6,128);

which should give me a straight line on the 8x8 matrix from one corner to the other. While it works for some registers it doesn't for others. I tried with delay if timing issues were the cause but no luck.
Any idea what I'm doing wrong?

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Feb 24, 2015

How do you control the SS pin of the MAX7219? The code on the web site pulls SS low in sendByte(), but I can't see similar in the Lua code you posted.

@squix78

This comment has been minimized.

Copy link

squix78 commented Feb 24, 2015

I assumed (wrongly?) that the firmware would "play" clock behind the scenes. I connected the 8x8 board like this. I connected
8x8 <---> ESP8266
CLK<---> GPIO14
DIN<----> GPIO13
CS <----> GPIO15<-5k Ohm-> GND
2015-02-24 21 47 55
You can recognise the straight line, but something goes wrong...

And here is the datasheet for the MAX7219:
https://www.sparkfun.com/datasheets/Components/General/COM-09622-MAX7219-MAX7221.pdf

@BobStevens

This comment has been minimized.

Copy link

BobStevens commented Feb 25, 2015

If you are keeping CS pulled low, then maybe you won't need to toggle it in your software.
Is the same pattern always displayed after sending your 8 bytes?
The datasheet for the MAX7219 states SPI data is loaded on the CLK rising edge, maybe try changing the phase in your spi.setup() ?

@morganrallen

This comment has been minimized.

Copy link

morganrallen commented Mar 24, 2015

I get the identical pattern with the same board and same setup.

@squix78

This comment has been minimized.

Copy link

squix78 commented Mar 24, 2015

@BobStevens: it is consistently the same pattern. Does somebody know if my assumption about the SS pin is correct? Or should I toggle it manually?
Guessing from the pattern it might have something to do with 1 byte vs 2 bytes write to the SPI bus, but I'm just guessing.
Testing the matrix with an Arduino works just as expected, so it must be either my Lua code or the firmware (or theoretically the hardware)...

@morganrallen

This comment has been minimized.

Copy link

morganrallen commented Mar 24, 2015

I don't think it is hardware, as I am getting consistently the same results as you.

@morganrallen

This comment has been minimized.

Copy link

morganrallen commented Mar 24, 2015

This method from the LedControl library might be of help.

https://github.com/wayoda/LedControl/blob/master/LedControl/LedControl.cpp#L192

@morganrallen

This comment has been minimized.

Copy link

morganrallen commented Mar 26, 2015

I've managed to port LedControl to ESP8266 and have 4 displays functioning correctly. I think neither the NodeMCU nor the ESP8266 SPI interfaces can handle the MAX7219. I'm not sure if it's a non-standard SPI or what, but the chip select appears to be different and it uses two bytes rather than one.

https://github.com/morganrallen/ESP8266-MAX7219_demo

@spotrevoc

This comment has been minimized.

Copy link

spotrevoc commented May 15, 2015

Has anyone figured out how to change the spi clock speed? I need to set it to 8mhz to work with an atmega328.

@rotopenguin

This comment has been minimized.

Copy link

rotopenguin commented Jun 4, 2015

@spotrevoc here's the best I've seen written up on SPI. No nice C function that you shove Mhz in one end and everything comes out just right, just raw registers to poke at and pray. Hope you have a good logic analyzer ¯_(ツ)_/¯

http://www.esp8266.com/viewtopic.php?p=13958
https://github.com/MetalPhreak/ESP8266_SPI_Driver

@spotrevoc

This comment has been minimized.

Copy link

spotrevoc commented Jun 4, 2015

Thanks, that helps. I managed to work out that the values written to the
registers are changed not by the #defines in spi_register.h, but rather the
decimal value being shifted within the register write function inside the
spi master init function.
On Jun 4, 2015 3:17 PM, "rotopenguin" notifications@github.com wrote:

@spotrevoc https://github.com/spotrevoc here's the best I've seen
written up on SPI. No nice C function that you shove Mhz in one end and
everything comes out just right, just raw registers to poke at and pray.
Hope you have a good logic analyzer ¯*(ツ)*/¯

http://www.esp8266.com/viewtopic.php?p=13958
https://github.com/MetalPhreak/ESP8266_SPI_Driver


Reply to this email directly or view it on GitHub
#50 (comment)
.

@nickgammon

This comment has been minimized.

Copy link

nickgammon commented Jul 12, 2015

I would be bringing SS low and then HIGH again as a starting point for debugging this.

@TheSkorm

This comment has been minimized.

Copy link

TheSkorm commented Sep 25, 2015

Having the same issue. I think it might be a clocking issue since the MAX7219 can only do 10MHz but I don't know much about this. Anyway I was able to implement a working system using Arduino for the ESP8266 so the hardware supports it (using the adafruit gfx lib and max7219 lib).

My code below.

local moduleName = ...
local M = {}
_G[moduleName] = M

local MAX7219_REG_NOOP        = 0x00;
local MAX7219_REG_DECODEMODE  = 0x09;
local MAX7219_REG_INTENSITY   = 0x0A;
local MAX7219_REG_SCANLIMIT   = 0x0B;
local MAX7219_REG_SHUTDOWN    = 0x0C;
local MAX7219_REG_DISPLAYTEST = 0x0F;

M.d = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00} ;

function M.updateDisplay()
  for i = 1, 8 do
    spi.send(1,i, M.d[i]);
  end
end

function M.drawPixel(x,y,z)
  z = z or 1;
  y = y + 1;
  mask = bit.bit(x);
  if z == 0 then
    mask = bit.bnot(mask);
    M.d[y] = bit.band(M.d[y],mask);
  else
    M.d[y] = bit.bor(M.d[y],mask);
  end
  M.updateDisplay()
end

function M.intensity(x) -- where 0x00 = low and 0x0F = high
  spi.send(1,MAX7219_REG_INTENSITY, x);
end

function M.setup()
  M.d = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
  spi.setup(1,spi.MASTER, spi.CPOL_HIGH, spi.CPHA_LOW,spi.DATABITS_8, 0);

  -- decode mode
  spi.send(1,MAX7219_REG_DECODEMODE, 0x00);

  -- scan limit
  spi.send(1,MAX7219_REG_SCANLIMIT, 0x07);

  -- disable test mode
  spi.send(1,MAX7219_REG_DISPLAYTEST, 0x00);

  M.intensity(0x02);
  M.updateDisplay()
  -- normal operation mode
  spi.send(1,MAX7219_REG_SHUTDOWN, 0x01);
end

return M
@TerryE

This comment has been minimized.

Copy link
Collaborator

TerryE commented Sep 25, 2015

@TheSkor, Michael, out of interest you could write your Lua to be a lot more runtime efficient. For example in the case of drawPixel() using locals as upvalues and exploiting the fact that tables are passed by reference and only cascading changed updates, you'd end up with something like

function M.drawPixel(x,y,z)
  y = y + 1;
  local Mdy = (z == 0 and bitclr or bitset) (Md[y],x)
  Md[y] = Mdy
  spisend(1,y,Mdy)
end

where bitclr, bitset, spisend, Md are top-scoped local caches of bit.clr, etc. Run both sets of source through luac to see what I mean.

@TheSkorm

This comment has been minimized.

Copy link

TheSkorm commented Sep 25, 2015

@TerryE cheers I'll play around with that. First time programming lua so still learning the syntax

@TerryE

This comment has been minimized.

Copy link
Collaborator

TerryE commented Sep 26, 2015

The Lua compiler does no optimisation to speak of, but using locals instead of repeated globals or expressions, especially if commonly used code, can save both instructions and time.

@TheSkorm

This comment has been minimized.

Copy link

TheSkorm commented Sep 26, 2015

So looking on a scope it seems that the Arduino version of my code runs a 1MHz for the SPI clock and the NodeMCU version runs at 10MHz. While the MAX7219 can apparently do up to 10MHz the clock signal that the ESP8266 is putting out looks really noisy so I think this might be why it sort of works.

I've tried compiling my own version with clock adjusted but I'm having issues with SPI stopping all together (even when following the advice from http://www.esp8266.com/viewtopic.php?p=13958 )

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 17, 2015

I agree on the clock issue ...
I'm using 7219 on a 8-digit 7-segment display, and even sending a straight 8 bytes spi.send

spi.send(1,MAX7219_REG_DIGIT0,121,MAX7219_REG_DIGIT1,121,MAX7219_REG_DIGIT2,121,MAX7219_REG_DIGIT3,121,MAX7219_REG_DIGIT4,121,MAX7219_REG_DIGIT5,121,MAX7219_REG_DIGIT6,121,MAX7219_REG_DIGIT7,121)

the result is "33339333" (instead of all "3").

each digit has a different binary data (from the 7219 data sheet pg 8) and probably depending on the number of "1" and "0" the high speed clock is causing false readings.

Infact if I do the above with 126 (i.e. digit 0) or 48 (digit 1) or 109 (digit 2) everything works fine.

same issue on BCD decoding btw... definetely we need a mode for a slower/cleaner SPI signaling

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 17, 2015

@gfilippi if you're concerned about signal integrity and frequency of the SPI clock then have a look at dev branch. The SPI driver was recently extended to accept clock dividing. See #678 and #674.

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 17, 2015

thanks devsaurus, I just flashed a prebuilt from github/dev branch but I see no difference even if I set a divider of 40 when calling the spi.setup

but .. looking in the repo I see that under master/app/driver/spi.c we have already the support for SPI/HSPI for SPI LCDs ... see spi_lcd_mode_init() code.

so probably all we need is a SPI/HSPI flag mode? it seems that the correct combination for pre/post dividers for a common 2MHz SPI have been used already

thanks!

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 17, 2015

I take it back ... using spi.setup() with id==0 (SPI) instead of id==1 (HSPI) does not work ... I get a hw reset :-(

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 17, 2015

Prebuilds in dev are never in sync with the code. You'd need to compile yourself or take the bin I linked in the second issue.
Regarding 9 bit data, I'm currently working on another improvement of the SPI driver for flexible bit lengths. It's WIP but soon ready for a PR.

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 17, 2015

thanks a lot devsaurus. I did a custom build thanks to the awesome http://frightanic.com/nodemcu-custom-build/

If I set a divider==0 I get an error ... so I suppose the feature is there.

but unfortunately even setting a divider eual to 8, 16, 32 I still have the same issue .. there must be more than signal integrity ... I will have to attach a logic analyzer and see if the SPI bus is pushing the correct clock/data

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

Hi all, I did a capture with the above spi.send of 8 digits and I believe the issue is actually not the clock itself (10Mhz HSPI seems fine) but the fact that we don't seem to send data correclty.

the 7129 is expecting 16bit bus, but even if I set correctly 16bit into the spi setup call ... I still see 8 bit bus on the LA.

the values we send are just fine, from this picture you can see we send the address first (incremental from 1 to 8, good) and the digit values (i.e. the correct binary representation of digit 0,1,2,3,4,5,6,7 as per datasheet, for example a digit==0 means value 126=0x7E from page 8 of the datasheet)

unfortunately from the datasheet the 7129 is expecting CS to stay LOW all time when working in 16 bit mode, while instead we have a moment (3us) in between where it goes high ...

this is the only reason I can think of .... other than that the bus seems fine, logic values are fine, signal is good, and this setup is using one of the many 7129/8digit display on ebay (100% working on arduino, tested)

8266

to be crystal clear: imho in the above picture CS should stay low between the send of 0x01 and 0x7E (2 bytes==16bit) as per 7129 specs pg.6

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 18, 2015

Excellent analysis @gfilippi! We should be able to track that down quite quickly now.
Your use case suffers from a restriction in the SPI driver that enforces transactions to be exactly 8 bit long (the term "transaction" refers to the activity between assertion and de-assertion of /CS).

There's a workaround which you could try right away: Override /CS control with your Lua script.
Note: Untested code, just a sketch...

spi.setup(1 , ...)
-- now revoke control of /CS from HSPI hardware
gpio.write(8, gpio.HIGH)
gpio.mode(8 , gpio.OUTPUT)

-- software controlled generation of a 16 bit transaction
gpio.write(8, gpio.LOW)
spi.send(1, 0x12)
spi.send(1, 0x34)
gpio.write(8, gpio.HIGH)

I'd expect that the waveforms will change with this approach. Not nice, but feasible as far as I can tell.

In parallel, I'm currently busy extending the SPI module in just this aspect - got a bit distracted by the SDK 1.4.0 update. But I should be able to provide a preview of the driver/module combo soon which brings much better support for crafting transactions.

A very good report on HSPI hardware can be found here:
http://d.av.id.au/blog/hardware-spi-hspi-command-data-registers/

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

hi devsaurus,
I've tried the "manual CS" hack but unfortunately the final output is not correct for a different reason.

CS stays low as we want, but the preamble/postamble of the CS going low and going high are too long, and the final SPI signal is invalid.

like the diagram on page 6 of the 7219 datasheet .. CS must respect a specific timing for going low (beginning of transaction) and going high (end of transaction)

using the gpio trick in a script (not from command line of course) this timing is too long (from the logic analyzer output)

thanks a lot

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 18, 2015

CS stays low as we want, but the preamble/postamble of the CS going low and going high are too long, and the final SPI signal is invalid.

like the diagram on page 6 of the 7219 datasheet .. CS must respect a specific timing for going low (beginning of transaction) and going high (end of transaction)

Don't think that this is really an issue with the "manual CS" hack. Timing parameters tCSS and tCSH are only specified for MIN, so any longer delay between /CS transitions and CLK should fit.
I'm more concerned about the (implicit) statement that MAX7219 is not fully SPI compliant. If there's any activity on CLK outside of the active periods then this will confuse a MAX7219. A MAX7221 is robust since its CLK input is qualified by /CS (as required by SPI).

However, if you like then have a try with https://github.com/devsaurus/nodemcu-firmware/releases/tag/1.4.0-dev-hspi_apiext_20151018. It's a preview of the upcoming improvements of the SPI module with #693. You can now specify any bit length in spi.setup() and it will be used during spi.send(). In your case that would be 16. /CS-to-CLK timing will be very short this way (just a few CLK periods) since all is generated by hardware. Let me know if it improves anything.

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

mmm ... could be ... but the logic analyzer does not recognize the SPI transaction (16 bit) as a valid one ... while if I do the same on arduino ... it is valid (same register, same number). BTW: I tried also a divider of 32 (slower clock) same value .. still not valid under the LA validation.

let my take your image and test

thanks!

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 18, 2015

Strange result from the LA. Can you post a screenshot eventually?

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

hey devsaurus ... one improvement but still another issue...

I can clearly see the 16 bit transaction being valid, but now for a spi.send(register, value) we have TWO separate 16 bit transactions and this is not how the 16bit bus works for 7219 ... since CS goes up in the middle like for 8bit transaction.
(in the picture I captured a shutdown=1 command, register is 0x0C, value is 1)

pbly this is the "non spi compliant" part of 7219 ... and pbly the only reason why it works on the arduino library it is because they toggle the line manually in the LedControl library...

still ... 7219 is really common in DIY prjs ... would be nice to find a hack to use 16bit transaction, manually "OR" the two 8 bit input values and shoot them on the bus ... I sure this would work with this display driver.
8266-2

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

actually the best (imho) would be to expose a "raw" api like spi.write(uint8_t spi_id, uint16_t val).

After the spi.setup call (8 or 16 bit transaction, clock, triggering) you let the user do the math on the value (for 7219 case I would have to merge address and command into one value) and the spi.write() call would take only the lower 8 or 16 bit of the value provided (based on the bus bit value that was set during the spi.setup() call)

this would solve all these borderline devices where they joined register+value into one single 16bit transaction to allow more data speed (needed when you have more 7219 in serial chain so the refresh is faster on a long digit display...)

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 18, 2015

I can clearly see the 16 bit transaction being valid, but now for a spi.send(register, value) we have TWO separate 16 bit transactions and this is not how the 16bit bus works for 7219 ... since CS goes up in the middle like for 8bit transaction.
(in the picture I captured a shutdown=1 command, register is 0x0C, value is 1)

I assume you did spi.send(1, 0x0C, 0x01). Why not spi.send(1, 0x0C01) instead?
The databits parameter for spi.setup() tells the driver how many bits of a data item in spi.send() have to be considered for a single transaction. Regardless of how you format the actual value.

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 18, 2015

devsaurus, you are totally right!

this is a perfectly working example for the 8digit display using 7219 on nodemcu HSPI (10Mhz, using your dev build)

the code will display "76543210"

MAX7219_REG_NOOP        = 0x00;
MAX7219_REG_DIGIT0      = 0x01;
MAX7219_REG_DIGIT1      = 0x02;
MAX7219_REG_DIGIT2      = 0x03;
MAX7219_REG_DIGIT3      = 0x04;
MAX7219_REG_DIGIT4      = 0x05;
MAX7219_REG_DIGIT5      = 0x06;
MAX7219_REG_DIGIT6      = 0x07;
MAX7219_REG_DIGIT7      = 0x08;
MAX7219_REG_DECODEMODE  = 0x09;
MAX7219_REG_INTENSITY   = 0x0A;
MAX7219_REG_SCANLIMIT   = 0x0B;
MAX7219_REG_SHUTDOWN    = 0x0C;
MAX7219_REG_DISPLAYTEST = 0x0F;


function sendByte (reg, data)
  spi.send(1,reg*256+data)
  tmr.delay(50)
end

function setup ()
  spi.setup(1, spi.MASTER, spi.CPOL_LOW, spi.CPHA_LOW, 16, 8);

  sendByte (MAX7219_REG_SHUTDOWN, 1);
  sendByte (MAX7219_REG_SCANLIMIT, 7);
  sendByte (MAX7219_REG_DECODEMODE, 0x00);
  sendByte (MAX7219_REG_DISPLAYTEST, 0);
  sendByte (MAX7219_REG_INTENSITY, 15);
  sendByte (MAX7219_REG_SHUTDOWN, 1);
end

function displayTest ()
  sendByte (MAX7219_REG_DISPLAYTEST, 1);
  tmr.delay(400000);
  sendByte (MAX7219_REG_DISPLAYTEST, 0);
end

function displayClear ()
 for i=1,8 do
     sendByte(i,0);
 end
end


setup();
displayTest();
displayClear();


sendByte(MAX7219_REG_DIGIT0,126);
sendByte(MAX7219_REG_DIGIT1,48);
sendByte(MAX7219_REG_DIGIT2,109);
sendByte(MAX7219_REG_DIGIT3,121);
sendByte(MAX7219_REG_DIGIT4,51);
sendByte(MAX7219_REG_DIGIT5,91);
sendByte(MAX7219_REG_DIGIT6,95);
sendByte(MAX7219_REG_DIGIT7,112);

thanks a lot for all your help an please close this issue once you PR to the dev branch!

@devsaurus

This comment has been minimized.

Copy link
Member

devsaurus commented Oct 19, 2015

Great news! And thanks for your patience, this session helped a lot in validating the upcoming changes.
If you ever feel like chaining up several MAX7219 chips, take a look at the new commands like spi.set_mosi(). They'll allow to have 512 bits in a single transaction.

@gfilippi

This comment has been minimized.

Copy link

gfilippi commented Oct 21, 2015

thansk devsaurus. I only have one module but I did order 4 of them ... shipping from china will take 1month unfortunately. But ... I think (from the datasheet) that even if I chain up multiple 7219 I still need to make multiple 16bit transactions, raising CS to HIGH in the middle.

I'll send an update once I can do a simple test.

@LeonidZakh

This comment has been minimized.

Copy link

LeonidZakh commented Oct 26, 2015

Hi devsaurus! I downloaded https://github.com/devsaurus/nodemcu-firmware/releases/tag/1.4.0-dev-hspi_apiext_20151018 and SPI work very good. But data not send to server in my old program.

   sk=net.createConnection(net.TCP, 0)
    sk:on("receive", function(sk, c) print(c)  end )
    sk:connect(33333,"192.168.43.1") 
    sk:send("ADC=OK\r\n\r\n") <-???

What do you think about it?

@TerryE

This comment has been minimized.

Copy link
Collaborator

TerryE commented Oct 26, 2015

Put the send in a sk:on("connection", do_the_send_here())

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.